I have small Linux server (Debian Squeeze) which runs a Samba server which is configured to share some folders with some windows machines. While trying to delete one of the directories from windows I received the "Cannot delete folder" error.

I tried to delete the directory from the linux's console I got a similar error:

# rm dir-name -rf
rm: cannot remove `dir-name': Directory not empty

I listed the contents of the directory and found a file named .fuse_hidden followed by a hex number (000bd8c100000185).

# ls -la dir-name
-rwxrwxrwx 1 root root 5120 Feb 13 11:46 .fuse_hidden000bd8c100000185

I tried to delete the .fuse_hidden file, but a new file was created instantly (note the hex number change).

# rm dir-name/.fuse_hidden000bd8c100000185
# ls -la dir-name
-rwxrwxrwx 1 root root 5120 Feb 13 11:46 .fuse_hidden000bd8c100000186

I also tried using Midnight Commander to delete the file with no success.

Other solutions I have found so far involve GUI and I've only got console.

Any suggestions are appreciated.

  • 3
    The fuse daemon seems to be active. Stop it before deleting the file.
    – ott--
    Feb 13, 2013 at 21:42
  • I've changed my comment in the meantime.
    – ott--
    Feb 13, 2013 at 21:46
  • That was my first thought but I couldn't find a Fuse service to stop, I restarted Samba instead, problem solved, the file is gone. Thanks.
    – Lando
    Feb 13, 2013 at 21:54
  • rm dir-name -rf? Feb 14, 2013 at 3:08

2 Answers 2


This is similar to what happens when you delete a file that another system has open on a NFS mount. The problem is that the file has been removed from the filesystem while its "link count" was >1, meaning that other processes are still holding it open.

  • Log in to the system where the file physically resides. (no network mount)
  • Execute lsof dir-name/.fuse_hidden000bd8c100000185 to find out what processes are holding the file handle open.
  • Terminate those processes if it makes sense to, or figure out what steps you can perform to "gracefully" release the open file handle without terminating the process.

Normally, when you delete a file on your local filesystem that another process has open, the OS complies with your request and removes it from the directory tree, but the inode that tree points to is still considered in use by the operating system. Every time a file is opened, its "link count" increments by one, and the space is only truly released when that link count hits zero.

When you run into a problem of this nature, it means that the OS has for whatever reason decided to not remove that file from the directory tree: usually because it has reason to believe that it still needs to be accessed by things that can't utilize the direct inode number. It might initially seem to comply, but behind the scenes the OS renames it to have a hidden dot-prefix so that is still accessible with some form of filesystem path addressing. The space will still be freed when the link count hits zero, but that object will will remain in the directory until the links are gone.

  • I guessed it had to do with some service still using the file (in this case Samba), I had forgotten about lsof.
    – Lando
    Feb 14, 2013 at 13:43
  • Lead me to the problem. lsof helped me to identify which process was still reading the file and I was by then able to remove everything! Oct 19, 2014 at 12:58
  • I have the problem, that lsof and fuser don't bring up any processes for that file, any suggestions?
    – mxmlnkn
    Jan 24, 2018 at 15:16

Thank for the suggestions, but nothing worked for me. But I found a solution: I moved the external SSD to a PC running windows. Using the File Explorer (with "Hidden items" checked) I navigated to the .Trashes directory was able to delete the .fuser_hidden file.

Hope this helps!

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .