8

I have a directory on my Debian system. The directory is:

root@debian:/3/20150626# stat 00
File: `00'
Size: 6             Blocks: 0          IO Block: 4096   directory
Device: fe00h/65024d    Inode: 4392587948  Links: 3
Access: (0755/drwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2015-06-25 20:00:00.086150791 -0400
Modify: 2015-07-07 12:39:04.174903234 -0400
Change: 2015-07-07 12:39:04.174903234 -0400
Birth: -

The directory is empty:

root@debian:/3/20150626# ls -al 00
total 0
drwxr-xr-x 3 root root  6 Jul  7 12:39 .
drwxr-xr-x 3 root root 23 Jul  7 12:56 ..

But my system doesn't think so:

root@debian:/3/20150626# rm -rf 00
rm: cannot remove `00': Directory not empty

I don't know why this would happen nor am I able to find a way to move forward. Can anyone provide assistance?

None of the previous questions that I could locate solved this specific issue. But, to address some of the questions I've seen asked on similar posts:

a.) The folder was created by a running process, which has created many folders before and these folders have been removed many times before. This specific one is stuck in limbo.

b.) There should not be anything written to this directory now. I have checked many times and the ls -al output always returns nothing.

c.) I have checked lsof and there is nothing open for this directory:

root@debian:/3/20150626# lsof 00
root@debian:/3/20150626# 

d.) rm is not aliased to anything else. It's pretty close to stock Debian...nothing special done with any of the core Bash programs such as rm, etc.

e.) Renaming is permitted but still unable to delete:

root@debian:/3/20150626# mv 00 delete_me
root@debian:/3/20150626# ls -al
total 0
drwxr-xr-x 3 root root  30 Jul  7 13:45 .
drwxr-xr-x 7 root root 105 Jul  7 12:57 ..
drwxr-xr-x 3 root root   6 Jul  7 12:39 delete_me
root@debian:/3/20150626# rm -rf delete_me
rm: cannot remove `delete_me': Directory not empty
root@debian:/3/20150626# ls -al delete_me/
total 0
drwxr-xr-x 3 root root  6 Jul  7 12:39 .
drwxr-xr-x 3 root root 30 Jul  7 13:45 ..

**Note, hereafter referring to as "delete_me" since I renamed it and I'm just going to go with the flow.

f.) This is the only directory that is returned when I run find on it.

root@debian:/3/20150626# find / -type d -name delete_me
/3/20150626/delete_me
root@debian:/3/20150626# find delete_me
delete_me

g.) lsattr shows nothing:

root@debian:/3/20150626# lsattr
---------------- ./delete_me
  • 1
    Is it possible to rename the directory? – Jenny D Jul 7 '15 at 17:28
  • 2
    The "Links: 3" part jumps out to me; it seems as though you might have a subdirectory. What does "find 00" return? – Jeff Schaller Jul 7 '15 at 17:48
  • Updated my question with an answer to yours, @JennyD – harperville Jul 7 '15 at 17:49
  • 1
    Have you checked lsattr to see if there are any special attributes assigned to it? – Caja Jul 7 '15 at 18:01
  • 2
    It's looking increasingly likely to me that this running process from item (a) is holding on to a subdirectory of "delete_me" in some fashion. Can you stop this running process, then re-check stat output (and/or retrying the rmdir)? – Jeff Schaller Jul 7 '15 at 18:17
1

Found the answer. Something was wrong with the linkage, as @JeffSchaller suggested. The solution is to run xfs_check to see that the links were incorrect, then xfs_repair to fix them.

  1. run mount to view the device name. Mine is /dev/mapper/vg3-lv3
  2. umount /3
  3. xfs_check /dev/mapper/vg3-lv3 which returned the following:

    link count mismatch for inode 4392587948 (name ?), nlink 3, counted 2

    link count mismatch for inode 12983188890 (name ?), nlink 1, counted 2

  4. xfs_repair /dev/mapper/vg3-lv3 which indicated that the links were corrected:

    resetting inode 4392587948 nlinks from 3 to 2

    resetting inode 12983188890 nlinks from 1 to 2

Turns out I had another inode that was linked incorrectly.

Thanks for all the help but using the black magic of xfs_repair, my problem is solved.

-1

You tried to verify that the attributes of the folder / directory have the attribute "i" - imutable is active! Check with the lsattr command to verify that the folder / directory has the attribute "i" activate if you turn it off with "*

chattr -i 'folder'

*" With this you can perform the task you want.

  • 1
    The -i attribute on a file / folder doesn't prevent it from showing up, however where do you see that -i is set? OP's output is stating the opposite – kos Jul 7 '15 at 18:39

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.