Question: I can't remove this file, even as root!
=================================================
Answer:
Here is a non-exhaustive situations in which root can't (immediately)
remove files from an ext2 filesystem:
<ol>
<li> `Permission denied'. The file has the `immutable' attribute. If
the file is a regular file or directory (i.e. first character of `ls
-l' output is `-' or `d') then you can do: `chattr -i FILE; rm -f
FILE'. Otherwise, see `force removal' below.
<li> `Operation not permitted'. The directory in which the file is
kept has the `append-only' attribute. Do `chattr -a DIR; rm -f FILE'.
<li> Miscellaneous others: `Is a directory' (use `rmdir' instead of `rm');
`Read-only filesystem' (If you don't know why your filesystem has
become read-only then it has probably been forced read-only when an
error was detected; unmount the filesystem, run e2fsck on it, then
mount it read-write and try again.); `Device or resource busy' (it's a
mount point).
</ol>
Force removal
=============
If the inode is really trashed (e.g. you have an immutable bit on a
device file), then you'll need to take a low-level approach.
You may use either `debugfs' or `ext2ed'. I'll try to describe both,
but I rarely if ever use `debugfs', so my instructions may be wrong
for that. In both cases, I've assumed that the file you wish to
remove is called `/path/to/file' (relative to the mount point of the
containing filesystem; e.g. if it's /usr/doc/hello/README, and `df
/usr/doc/hello/README' says `Mounted on /usr' then the path relative
to the mount point is `/doc/hello/README').
Beforehand
---------
Unmount the filesystem first, whether you're using ext2ed or debugfs.
You may need to switch to single-user mode first (by doing
/sbin/telinit 1).
Ext2ed
-----
ext2ed
setdevice /dev/XXX
cd /path/to/file
enablewrite
set i_nlink=0
writedata
quit
Debugfs
------
debugfs -w /dev/XXX
/unlink /path/to/file
quit
Afterwards
---------
e2fsck -f /dev/XXX
mount /dev/XXX
Running e2fsck may not be necessary for debugfs. For ext2ed, it does
the rest of the work in removing a file: sets d_time, removes the
directory entry/ies, and frees the blocks.
That mount command may need some adjustment; just use whatever you
would normally do to remount it. The command shown above
assumes that the filesystem is not your root filesystem but that it is
listed in /etc/fstab. If it is your root filesystem then you'll need
to do `mount -n -w -o remount /' instead.
Question: I have a file with really strange permissions, size, type,
etc. What gives?
====================================================================
Answer:
[Robert: maybe the sparse file thing should be moved to a separate
question, but keep a reference to it from here.]
Important: If only the size seems strange (e.g. very large) then there
is probably nothing wrong. Unix filesystems have a concept of `sparse
files', which are files whose length is more than the amount of data
stored on disk. Sparse files are said to contain "holes" -- that is,
blocks that don't take up any space on disk and that are read as if
they were full of null bytes. One way of creating a sparse file is:
`:|dd of=bigfile seek=2048000 count=0'. If you do `du bigfile',
you'll see that it actually takes up no space on disk (other than
using up an inode and 16 bytes of the containing directory), yet it's
1000MB long. If you have disk quotas on that filesystem, then you'll
see that your block quota isn't affected: `quota' only looks at how
much space is taken up (as reported by du), not by the file length.
If, on the other hand, the file has strange permissions etc. (e.g.:
?-ws--Sr-x config.cache
), then the inode of that file has somehow become trashed. If you're
very lucky, then you may still be able to access the data from that
file (though you may need first to use ext2ed or something to set
i_mode to octal 0100400, i.e. regular file with perms 0400). If you
have some time on your hands and some luck then you may be able to
find the data among the free blocks of the filesystem. More
likely, though, you'll just have to remove the file and restore from
any backup you have. See question `I can't remove this file, even as
root!' if you have trouble removing the file.
HTH,
pjm.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu