47

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.

Improve this question
4
  • 3
    The fuse daemon seems to be active. Stop it before deleting the file. Commented Feb 13, 2013 at 21:42
  • I've changed my comment in the meantime. Commented 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. Commented Feb 13, 2013 at 21:54
  • rm dir-name -rf? Commented Feb 14, 2013 at 3:08

2 Answers 2

Reset to default
72

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.

Improve this answer
3
  • I guessed it had to do with some service still using the file (in this case Samba), I had forgotten about lsof. Commented 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! Commented 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? Commented Jan 24, 2018 at 15:16
0

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!

Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.