I'm a non-root user on a shared compile server that mounts /home via NFS from some other host. I have a directory ~/a/b with lots of subdirectories c1,c2,.... I wanted to delete ~/a/b completely, and succeeded for most of the cN directories. But a few (say c1) are completely inaccessible: I can execute them (i.e. cd into them) but neither list (ls) let alone remove them. If I say rm -rf ~/a/b/c1, the process hangs in a D state.

What can I do as a non-root user to get rid of ~/a/b?

Update: I just ssh'd to the file-server (to rule out NFS) and I cannot perform the operation there either, so this doesn't seem to be an NFS problem after all. However, why does the kernel refuse to remove a directory?

  • I tagged this as sleep because the process hangs in an uninterruptable sleep but there is no hangs tag.
    – bitmask
    Dec 2 '11 at 19:24

Removing a file or directory is an atomic operation requiring one system call, so if the rm command hangs, it's because the kernel is stuck. On an NFS filesystem, this can be (and usually is) due to the server not responding. On a local filesystem, this can be (and usually is) due to a hardware failure. Your disk is probably failing; the kernel logs would confirm that.

  • I left an ls command run in the background (in a screen, to be precise) and it actually terminated after a very long time (hours!), and showed a decent amount of (small) files (but nothing that would explain such a long waiting time). If the drive is broken, why does ls return after such a long time but not rm? Does that make any sense?
    – bitmask
    Dec 3 '11 at 0:07
  • @bitmask It could be that some of the sectors where that directory is stored are damaged; the kernel retries disk accesses several times and manages to return some data about the directory, but when you try to write there the kernel never manages to accomplish anything. You really need to contact the system administrator and tell him to look at the kernel logs. Dec 3 '11 at 0:14
  • Thanks. I just wanted to be sure I couldn't fix that myself.
    – bitmask
    Dec 3 '11 at 0:25

Check if any processes are accessing the files under the hood (like their current working directory). I would use tools like lsof and fuser -v and see if there are any processes messing up with the directory and get rid of them first. Restart nfs client service, if needed and try to check if the directory exists and more so do not remove the directory when it is a current working directory of the same shell.

  • Both lsof and fuser -v do not show processes for the directories. Also, that would not explain, why I cannot even list the directory contents. It feels like the directory is on a different file-system that is not connected, but that is definitely not the case.
    – bitmask
    Dec 2 '11 at 19:38
  • you are right, I just corrected. Have you verified no process is accessing the filesystem, unmount filesystem, tried restarting the nfs client service and then remount filesystem? Dec 2 '11 at 19:44
  • As I said, I do not have root privileges.
    – bitmask
    Dec 2 '11 at 19:52
  • Contact your root guy and tell him about this issue, it might be of his interest more to debug and resolve this at the earliest. Dec 3 '11 at 7:01
  • Already done :)
    – bitmask
    Dec 3 '11 at 7:12

If it hangs during find and delete operation, you can set a timeout for the process, as following (here I'm calling it through bash on windows with cygwin):

bash -c "find . -regex ".+fileDirToDelete" -exec rm -Rf {} \; & pid=$!; sleep 100; kill $pid"

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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