Date: Tue, 16 Apr 2002 10:23:43 -0700
From: Rick Moen rick@linuxmafia.com
To: [name omitted]
Subject: Re: Hello...
User-Agent: Mutt/1.3.27i

[My correspondent had reported "permission denied" errors when trying to
delete something using the root account.]

The immutable attribute is, of course, just one attribute that can be
set with chattr. Here's an example of how to use lsattr and chattr:

uncle-enzo:~# cd /tmp
uncle-enzo:/tmp# chattr +i wrd
uncle-enzo:/tmp# lsattr wrd
---i--------- wrd
uncle-enzo:/tmp# rm wrd
rm: remove write-protected file `wrd'? y
rm: cannot unlink `wrd': Operation not permitted
uncle-enzo:/tmp# chattr -i wrd
uncle-enzo:/tmp# rm wrd
uncle-enzo:/tmp#

There are some other valid bits that chattr can set (see "man chattr"):

a = append-only mode
c = compressed storage
d = dump-omitted (omit this file, when using the dump command)
j = journaled
s = secret (zero out all its bits, if you delete the file)
S = synchronous-written
u = undeletable

None of those, however, could account for the file being undeletable by
the root user.

I _hope_ you've tried simply doing "chmod 777" on the file, right? I
mean, any Unix system will block the root user from deleting a file
whose permissions mask doesn't give him write permission -- as with any
other user. The root user's special ability is to _change_ such rights
masks to give himself write permission, regardless of who owns the file.

If you've tried all that, and the file remains undeletable by the root
user, _and_ you've verified that the filesystem hosting it is mounted
writeable[1], then by definition the filesystem is damaged, and needs to
be repaired or replaced.

The thing to try, in that case, is the fsck utility appropriate for
whatever filesystem type it is, e.g., fsck.ext2, fsck.ext3, etc. You'll
need to unmount it first. (Thus, if it's the root filesystem, you may
have to do this from a maintenance floppy, CD-ROM, or maintenance
partition.)

If you've fscked the filesystem, remounted it (in read-write mode, not
read-only), and the file is _still_ not deletable, then you have some
type of filesystem corruption that fsck can't handle. Congratulations!
You'll need to back up the filesystem's data, blow it away, recreate it,
and then restore.

[1] For example, the fact that root cannot delete a file from /usr
in my system is not surprising:

uncle-enzo:/tmp# mount
/dev/sda5 on / type ext2 (rw,errors=remount-ro)
proc on /proc type proc (rw)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
/dev/sdb7 on /var type ext2 (rw,nosuid,nodev,noatime)
/dev/sda8 on /var/log type ext2 (rw,nosuid,nodev,noatime)
/dev/sdb8 on /usr type ext2 (ro,nodev)
/dev/sda9 on /usr/local type ext2 (rw)
/dev/sdb1 on /home type ext2 (rw,nosuid,nodev)
/dev/sdb5 on /tmp type ext2 (rw,noexec,nosuid,nodev,noatime)
uncle-enzo:/tmp#

It's easy to forget about the subtler consequences of mount options.
For example, sometimes, I forget about the "noexec" option on /tmp,
and wonder for a few seconds why shell scripts won't work, there.

(Also, on rare occasions, the "mount" output will remind you that the
directory you've been fruitlessly trying to delete is an in-service
mountpoint. D'oh!)

--
Cheers, "Azathoth need not be present to win."
Rick Moen -- Charles O. Baucum, Jr.
rick@linuxmafia.com