Trying to delete directory with "rm -rf", but get message that it's not empty

Question

I've tried deleting a directory using "rm -rf" and I'm getting the message "Directory not empty":

Bens-MacBook-Pro:please benjaminhocking$ ls -lart empty_directory/
total 16
drwxr-xr-x  5 benjaminhocking  staff  170 Aug 27 14:46 .
drwxr-xr-x  3 benjaminhocking  staff  102 Aug 27 15:28 ..
Bens-MacBook-Pro:please benjaminhocking$ rm -rf empty_directory/
rm: empty_directory/: Directory not empty
Bens-MacBook-Pro:please benjaminhocking$ rmdir empty_directory/
rmdir: empty_directory/: Directory not empty

If I try the same thing using Finder (dragging the folder to the Trash), I get the message

The operation can’t be completed because the item “empty_directory” is in use.

I've tried doing xattr -d com.apple.quarantine, purely out of superstition, but it did no good.

A probably important piece of context is that this directory was initially in a directory that should've been deleted by a "make clean" command I issued prior to Terminal locking up on me, after which a little over half of the other programs I had running also locked up, including Skype, and eventually the OS itself. I ended up having to reboot the computer by pressing and holding the power key.

Edit to add: Another important piece of information I left off was that this was happening in an encrypted folder à la encfs. I was able to track down the corresponding folder in the encrypted side of things and delete it there. I still don't know why I couldn't do it from the decrypted side of things like I normally do. I'll leave this unanswered for now in case anyone has a good answer for that.

Answer 1

Reboot your computer and run rmdir(1) again.

$ rmdir -r empty_directory/

If that doesn't work, then try:

$ rm -rf empty_directory/

If it still doesn't work, assuming OS X has lsof(8) preinstalled, then enter:

$ lsof +D empty_directory/

This should tell if any files in this directory are being used by any programmes. I think that the HFS+ filesystem does not allow the deletion of files in use. Anyway, killall(1) any executables that might be using this directory or any hidden files inside it. It is likely that Finder is using a hidden file in the empty_directory directory to store folder view settings. Hope this helps.

P.S.: To find out if lsof(8) is installed, enter:

$ lsof

If the output looks like this, then lsof(8) is installed on your system.

lsof: /usr/bin/lsof /usr/bin/X11/lsof /usr/share/man/man8/lsof.8.gz

Check for any hidden and encrypted files or encryption key files in that directory. These could be the culprit.

Answer 2

Repairing the disk using Disk Utility fixed this problem for me.

Answer 3

The only solution that worked for me was from https://unix.stackexchange.com/questions/234876/unable-to-delete-a-file-whatever-i-do:

Move them to /tmp and restart.

The other options I tried were:

• Disk Utility - First Aid.
• lsof +D bad_file showed no output.
• sudo rm -rf
• Booting into single-user terminal and rm -rf.

Answer 4

Tried all of the answers here with no results. I was, however, able to move the directory aside using the mv command, which allowed me to continue.

Answer 5

I ran into exactly this error while also trying to remove a directory (rm -r dirname). I had already tried all of the suggestions I've read here before I searched and found this thread. I do not know if there may have been any additional points unintentionally left unstated from the original question, but in my case the root of the trouble, and the solution was:

• the directory in question was on a network-mounted disk

• any ls attempt from Finder or command line showed nothing but . and ..

• I logged into the network disk server via the ssh command and checked ls -al there. The result showed, in addition to . and .., several .__filename items with extended security information (i.e., + appended to the mode).

I believe these are, or are similar to, files which I first noted Mac OSX creating years ago when using cp -R, tar, or cpio to archive or move groups of files. I had deduced at the time that they were used to properly reset some file properties after the move - maybe uid/gid, mode, acls, mtime/utime/ctime, etc; I'm not really sure - properties which had not been getting reset correctly by those commands before that time (I remember that OSX used to include mvmac and cpmac commands to work around the problem before these .__filename types of files started appearing when using the usual forms of cp, tar, etc).

I had never encountered trouble deleting these files when they had been written onto an internal, USB, or Firewire drive; this was the first time I'd found them on a network disk; completely undetectable from the client side of the mount, but normal in every way when viewed from the server side.

rm -rf dirname from a login on the network disk server properly removed the directory along with its contents.

So, there's another answer for what it's worth; another potential solution to this problem if it should appear for anyone in conjunction with a network disk.

Answer 6

If this happens and you're sure you want to delete everything, you should try using sudo rm -rf directory/

Answer 7

For the benefit of the readers:

Beware rm -rf in such a case! It can create problems somewhere else in case it happen to be a network share! You have been warned!

In nearly all cases, if a directory seems to be empty, use rmdir directory or perhaps sudo rmdir directory. Do not use rm (or del under Windows). If this does not work, you need to find out, what blocks this request, fix that and then retry the rmdir.

Please note that I do not know OS-X, but I think things there are very similar to the Unix/BSD behavior.

It is very likely that the directory in question was just a mount point (from the encfs) or residing on a mount point which became readonly or stuck in some improper state (which prevented the directory to be removed). If you now force removal of the directory, very bad things can happen.

In the good case the directory really was empty, so removing it (destroying the mount etc.) did no further harm. In the bad case it wasn't empty, just appeared to be, which means, you trashed something which you perhaps did not want to kill. This all depends on the mount type, which drivers are in use etc. pp.

If things are implemented reasonably well, normally nothing bad should happen. However this is not the normal case. Things are in a weird state already, which means: Something is wrong, so better do not try to mix it up even further! If something is cracked, any wrong touch might break it.

For example, if you hit a race condition on a network share, it might be that your rm -rf removes data which is just copied to the share by somebody else.

However rmdir is guaranteed to never do harm, besides removing really empty directories. This is even true on NFS, because NFS only guarantees truly atomic behavior on mkdir and rmdir, but nowhere else.

FYI:

You can detect a mountpoint using the tool mountpoint directory. Alternatively look into the output of mount and try to spot your mounts there. But beware, at least under Linux this might lie. Using the mountpoint utility more reliable but less convenient.

In that case you found the mountpoint, you can unmount it and then remove the directory, this is following sequence:

umount directory rmdir directory

If needed use sudo, as usual.

Notes:

• Network shares might deny rmdir (and anything else) due to access rights.

• Defective filesystems may deny rmdir, depending on the fail strategy. Perhaps you will see a reasonable message in that case, perhaps not.

• Under Linux (and probably any modern OS) you can also restrict access using different means (like mounting something readonly, capabilities like in SeLinux, etc.). This then means you do not see that it is a mountpoint, and you do not see anything wrong, but it just does not work. In that case you need to look for some other reason and it can be very deeply buried in the OS. It depends on the tool if you see some reasonable error message. Also perhaps have a look into the syslog/kernel-log like dmesg under Linux (sorry, I do not know the OS-X equivalent).

• Note that mandatory file locking may be a source, too. While this is normal on Windows, usually it is not the normal case Unix and I never heared it for directories. Mandatory file locks are covered by POSIX, but they are optional.

• Quite often in such cases, the directory in question resides on a different filesystem than which you thought. You can find out which, with the command df directory (I think this is the same under OS-X).

• You can inspect deeper with tools like stat or statfs on the directory. However these are a bit low level for normal people, and quite often such tools are well hidden from normal users.

• Directories can have files with funny names. Like a file which immediatelty erases the terminal output, so it looks like it isn't there. Try something like ls -al | less or use something like MidnightCommander mc.

There are trainload of other possibilites, including bugs, haxors, aliens, or perhaps more exotic things like fairies. But usually it is not wise to start looking there, instead first try to find the error at your side, because "errare humanum est".

Answer 8

This could also be a case I just solved in which a broken symlink was on the server-side and was not visible to the client over CIFS. The symlink populated a non-empty directory, but the client was unable to see or stat the symlink for the purpose of clearing out the directory before unlinking the directory. Since it was invisible, it created this paradox where from the client side it was empty but "not empty" upon challenge by rm. If you have SSH access to the server, try a shell on that end and see if the directory is truly empty or if it may have broken symlinks. I was able to do this on a Drobo5N and it saved my butt.

Answer 9

Try to open that directory from Windows, there can be something not shown in Mac OS. I had similar issue after a number of copy operations between Mac and Win PC: the directory was empty even in terminal but on Windows I found a hidden windows file, so I successfully removed the directory from there.

Answer 10

In the terminal:

1. enter sudo su (The command line prompt should switch to something like sh-3.2#.)
2. navigate to the parent folder of the one you want to delete
3. enter rm -rf TheDirectoryYouWantToDelete

Answer 11

I encountered this issue while trying to delete a folder that an Application was using. When I closed out of the Application it let me remove the folder without throwing this error, so try to quit the Applications that might be using it.

Answer 12

I had the same problem.
Solved it by booting up on another MacOS volume or disk. Then:

sudo rm -rf /Volume/volumewithproblem/directorywithproblem

Answer 13

Open terminal and type:

1. This command

   defaults write com.apple.finder AppleShowAllFiles YES
   

2. Press option key, click right on Finder and select relaunch

3. Then go to the Volume on your desktop, open .Trashes/Trash, click right on the directory and select empty trash
4. Done

5. Then in terminal type:

   defaults write com.apple.finder AppleShowAllFiles No
   

Answer 14

If the file/folder are in a mounted Volume on Mac. Unmounting and Mounting the Volume might solve the issue.