Fix: rm: cannot remove — Is a directory on Linux

You typed rm logs, hit enter, and got back:

rm: cannot remove 'logs': Is a directory

Nothing is broken. rm just refuses to delete folders by default, and it has for as long as I can remember. The command assumes you meant a file. If you actually wanted to nuke a directory, you have to say so explicitly.

The real fix is one flag. Everything after that is a variation on the same theme — permissions, hidden files, weird names, and that one script that keeps recreating the folder out from under you.

Cause 1: You forgot -r (this is 90% of cases)

rm won't recurse unless you tell it to. That's not a bug, it's a safety net. If rm happily deleted any directory you pointed at, nobody would have a working home folder left.

Add -r (recursive) and it'll walk into the directory and remove everything inside.

rm -r logs

If you want to skip the confirmation prompt on write-protected files, add f:

rm -rf logs

That -rf combo is the one that shows up in every Stack Overflow answer and every war story about someone wiping / because they had a space in the wrong place. Type the path, then read it again before you hit enter. I've seen a guy blow away a production Postgres data directory at 2am with rm -rf /var/lib/postgresql /data — note the space. He thought he was deleting two things. He was deleting one thing.

If the directory is empty and you just want it gone, rmdir does the same job with less risk:

rmdir logs

rmdir only works on empty dirs. That's a feature — it'll save you.

Cause 2: Permission denied on the directory or a file inside

Second most common. You run rm -r and now you're staring at:

rm: cannot remove 'logs/app.log': Permission denied

Deleting a file requires write permission on its parent directory, not on the file itself. That trips people up constantly. The file can be mode 000 and you can still delete it, as long as you own the folder it lives in.

Check who owns what:

ls -la logs
stat logs

If the directory is owned by root or another user and your account isn't, either use sudo:

sudo rm -r logs

or fix ownership first if you want to keep working in that tree:

sudo chown -R $USER:$USER logs
rm -r logs

One thing that bites people on shared hosting and NFS mounts: even with sudo, an immutable file won't budge. Look for the i flag in lsattr:

lsattr -R logs
sudo chattr -R -i logs
rm -r logs

I hit this last month on a client's CentOS 7 box. Their backup tool had set +i on a lockfile inside a log directory, and nobody could delete the folder because of one two-kilobyte file. chattr -i cleared it in seconds.

Cause 3: Directory not empty — hidden files, mounts, or a process holding it

You run rm -r, it finishes, and the folder is still there. Or you get:

rm: cannot remove 'logs': Directory not empty

Three things cause this. Work through them in order.

Hidden dotfiles

A plain ls won't show dotfiles. rm -r does remove them, but if you tried something like rm -r logs/*, the glob skipped everything starting with a dot. The folder looks empty, but .gitkeep or a stray .nfs1234 is still in there.

ls -la logs
rm -rf logs

Use the directory itself, not a wildcard, and you sidestep this entirely.

Something is mounted inside it

If a mount point lives inside the directory, rm can't remove the folder because the kernel still has it in use. Look for it:

mount | grep logs
findmnt -T /path/to/logs

Unmount first, then delete:

sudo umount /path/to/logs/mount
rm -rf /path/to/logs

A process has a file open inside it

On Linux this usually doesn't block deletion — the file gets unlinked and the process keeps its file descriptor. But on NFS, Samba shares, and some container overlays, it absolutely does. Find the culprit:

sudo lsof +D /path/to/logs
sudo fuser -v /path/to/logs

Kill or restart whatever's holding it, then delete. On containers, docker restart on the container that owns the mount is usually faster than hunting individual PIDs.

What not to do

A few things I see people try that waste time:

• rm -d logs — deletes empty dirs, works, but rmdir is clearer and it's what you'll remember next time.
• Rebooting to "release" the directory — sometimes works for NFS, usually overkill.
• Deleting the parent directory to take the child with it — occasionally the pragmatic move, but check nothing else lives in the parent first.
• Adding -f to "force" permissions — -f suppresses prompts, it does not grant permissions. That's a common misread.

Quick reference

Nine times out of ten, the whole thing is solved by rm -r. The rest is permissions and mounts. If the folder still won't go after all that, boot from a live USB and delete from there — that fixes the last stubborn 1% where a driver or service is glued to the path.