Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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.

share|improve this question
2  
The fuse daemon seems to be active. Stop it before deleting the file. –  ott-- Feb 13 '13 at 21:42
    
I've changed my comment in the meantime. –  ott-- Feb 13 '13 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 '13 at 21:54
    
rm dir-name -rf? –  Hauke Laging Feb 14 '13 at 3:08

1 Answer 1

up vote 22 down vote accepted

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.

share|improve this answer
    
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 '13 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! –  ThanksForAllTheFish Oct 19 at 12:58

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.