Cannot Delete Empty Directory

[Tommy_6]

I noticed I have an empty directory. As root, when I do an ls -la I receive the following:
Total 0

There is no "." or ".."
When I try to rm -rf the directory as root, it returns the following:
rm: directory not removed. Directory not empty

Anyone have an idea. Thanks in advance.

Tommy

[Steven E. Protter]

Maybe its a special file or there is a soft link to it somewhere else.

maybe lsof or fusers -cu to identify a process on the fs

SEP

[A. Clay Stephenson]

You probably have a file with a control character as the name --- or maybe even a single space.

cd to the directory and do an ls -b. That will display any non-printable characters in octal notation.

You can remove the directory d by issueing a recursive rm, rm -r dirname and that will remove all files/directories below dirname before removing dirname itself. Man rm for details.

[Tommy_6]

There are no instances of the directory when running the lsof command. When running "fuser -cu " it would return:

fuser: could not find file system mounted at

Thanks

[Tommy_6]

Clay,
There are no non-printable characters in the directory name, when trying to remove the directory recursively with "rm -rf", it complains that the directory is not empty.

Thanks

[Geoff Wild]

Try moving it first:

mv DIR NEWDIR

Does that work?

No - what happens when you do a:

fuser -cu /YOURDIR

If yes, try ftp'ing to the server using a ftp client like WSFTP - as root - then try to delete the directory from within ftp.

Rgds...Geoff

[Jeff Schussele]

Hi Tommy,

If you
rm -i /dir_name
does it respond with anything at all - even an invisible filename?
If so - reply "y" to remove it.

Rgds,
Jeff

[Tommy_6]

Geoff,
I can mv the dir, but still cannot delete it after moving it. When running "fuser -cu ", it returns:
fuser: could not find file system mounted at .
Also tried through an ftp client and it complained about the directory not being empty

When trying to mv to a differant filesystem, it would return the following:

rm: directory not removed. Directory not empty
mv: : Cannot unlink

Any ideas on the "Cannot unlink"

Thanks

[Jeff Schussele]

Hi,

Meant rm -i * inside that dir...

Jeff

[Tommy_6]

Jeff,
When running rm -i inside the dir it returns the following:
No match

What do you think about the "Cannot Unlink" error when moving the dir to another filesystem?

Thanks

[Geoff Wild]

Found this on google:

"I have seen this before. It happens when a directory has an extra hard
link. This isn't supposed to happen. If you do "ll -d" on that
directory, does it show 3 links? If so, then somewhere on the system,
there is (if fsck passes) another directory name that is the same
directory. Do "ll -ia" on the directory. This will tell you the inode
numbers of the directory and what it thinks is its parent. Then, you
can do something like "find / -inum [inodenum] -print" (where [inodenum]
is the inode number of "." from above) to discover where the two links
are. Now, do "ll -id" on both parent directories to see which one does
NOT match the inode number of ".." in the bad directory. Do an
"unlink" on the bad directory where the inode number of ".." doesn't
match the inode number of its parent. Then you should be able to
"rmdir" the other one."

Rgds...Geoff

[Tommy_6]

Geoff,
Still no luck, when I do an "ll -d "
drwxrwxrwx 2 root sys 114688 Jan 25 23:28

When I do an "ll -ia ", it returns:
total 0

Thanks

[Geoff Wild]

Tommy, - mv it back to the old dir name - then rerun the ll -d

Though I'm pretty sure you will get the same results....

[Geoff Wild]

BTW - did you fsck the filesystem this DIR is on? you may have a corrupt inode....

Rgds...Geoff

[Sridhar Bhaskarla]

Hi Tommy,

Try 'ncheck /dev/vgxx/lvolx > /tmp/.out' and search for this directory name. Note the corresponding inode and see if there is any other inode. If so, then it is a mere link. You may have to do 'unlink ' to get rid of it. Atleast you will find out what's going on with this directory. It will show the inodes corresponding to each path.

-Sri

[Elmar P. Kolkman]

Could it be that the directory in question is a mountpoint? Perhaps NFS? Or is the filesystem containing the dir an NFS mounted filesystem? In that case, how does it look like on the NFS server?

If it is not, I would suggest to run an fsck on the filesystem the dir is in. Something or someone really messed it up... But that would mean you have to unmount it first.

[Tommy_6]

Well, I tried umounting the filesystem and running fsck on it. This is what is returned

fsck /dev/vgX/lvolX

fsck: /etc/default/fs is used for determining the file system type
vxfs fsck: cannot stat -
vxfs fsck: file system had I/O error(s) on meta-data.
vxfs fsck: file system had I/O error(s) on user data.
log replay in progress
full file system check required, exiting ...


Now I can't mount the filesystem. Any thoughts?

Thanks

[Geoff Wild]

try fsck -o full

Rgds...Geoff

[Robert-Jan Goossens]

Tommy,

# fsck -F vxfs -y -o full /dev/vgxx/lvolx

Regards,
Robert-Jan

[Tommy_6]

Tried the following:

fsck -F vxfs -y -o full /dev/vgX/lvolX

vxfs fsck: file system had I/O error(s) on meta-data.
vxfs fsck: file system had I/O error(s) on user data.
log replay in progress
pass0 - checking structural files
pass1 - checking inode sanity and blocks
vxfs fsck: fsck read failure bno = 89608, off = 0, len = 8192
file system check failure, aborting ...

Any thoughts?

Thanks

[Geoff Wild]

Is there anything in syslog or dmesg indicating a hardware failure for the disk that this lvol is on?

Rgds...Geoff

[Geoff Wild]

Also try:

lvdisplay -v /dev/vgX/lvolX |more

look for errors....

Try a dd:

dd if=/dev/vgX/rlvolX of=/dev/null bs=256k

and try the physical disk that your lvol belongs to:

dd if=/dev/rdsk/c?t?d? of=/dev/null bs=256k


Rgds...Geoff

[Tommy_6]

This is the first entry of the problem in the syslog:

vmunix: vxfs: mesg 055: vx_metaioerr - /dev/vgX/lvolX file system meta data read error

And this one:

Feb 26 05:25:12 SYS vmunix: DIAGNOSTIC SYSTEM WARNING:
Feb 26 05:25:12 SYS vmunix: The diagnostic logging facility has started receiving excessive
Feb 26 05:25:12 SYS vmunix: errors from the I/O subsystem. I/O error entries will be lost
Feb 26 05:25:12 SYS vmunix: until the cause of the excessive I/O logging is corrected.
Feb 26 05:25:12 SYS vmunix: If the diaglogd daemon is not active, use the Daemon Startup command
Feb 26 05:25:12 SYS vmunix: in stm to start it.
Feb 26 05:25:12 SYS vmunix: If the diaglogd daemon is active, use the logtool utility in stm
Feb 26 05:25:12 SYS vmunix: to determine which I/O subsystem is logging excessive errors.


Feb 26 05:47:11 SYS vmunix: DIAGNOSTIC SYSTEM WARNING:
Feb 26 05:47:11 SYS vmunix: The diagnostic logging facility is no longer receiving excessive
Feb 26 05:47:11 SYS vmunix: errors from the I/O subsystem. 69 I/O error entries were lost.

Any thoughts?

Thanks

[Jeff Schussele · Accepted solution]

Hi Tommy,

Well that's not pretty. metioerror is an error reading the metadata in the filesystem. The metadata is where the inode info & other important data is kept that allows the system to find the file & tell you what you want to know about it.
If the following errors are right after this error, then I'd suspect you have a disk going bad & it's going bad in the absolute worst place - where the meta data lives.
You better back it up - IF YOU CAN - and get it replaced.

Rgds,
Jeff

[Geoff Wild]

I agree with "Jeff" - try mounting read only - you might be able to back it up.....

Rgds...Geoff