[lug] Remove files not owned by anyone.

[steve at badcheese.com]

This is definitely a corrupt FS.  If this is your / partition and the 
machine is remote, I suggest marking the partition for an fsck, then 
rebooting and hoping that the initial fsck does the trick.  If there is 
major corruption, your machine probably won't come back after the reboot 
and you'll need to boot with knoppix or a suitable alternative and do a 
manual fsck on the partition.

- Steve

On Wed, 28 Feb 2007, Paul Nowosielski wrote:

> Date: Wed, 28 Feb 2007 15:44:16 -0700
> From: Paul Nowosielski <paul at celebrityaccess.com>
> Reply-To: "Boulder (Colorado) Linux Users Group -- General Mailing List"
>     <lug at lug.boulder.co.us>
> To: "Boulder (Colorado) Linux Users Group -- General Mailing List"
>     <lug at lug.boulder.co.us>
> Subject: Re: [lug] Remove files not owned by anyone.
> 
> On Wednesday 28 February 2007 15:40, bgiles at coyotesong.com wrote:
>>> # ls -n
>>> ls: cannot access courierimapuiddb: Permission denied
>>> ls: cannot access maildirfolder: Permission denied
>>> total 384
>>> drwx------ 2 1001 59 389600 2007-02-24 01:29 courierimapkeywords
>>> ?????????? ? ?    ?       ?                ? courierimapuiddb
>>> drwx------ 2 1001 59   3128 2007-02-24 01:29 cur
>>> ?????????? ? ?    ?       ?                ? maildirfolder
>>> drwx------ 2 1001 59     48 2005-06-23 09:56 new
>>> drwx------ 2 1001 59     48 2007-01-29 10:05 tmp
>>>
>>>
>>>  # lsattr
>>> lsattr: Inappropriate ioctl for device While reading flags on ./cur
>>> lsattr: Inappropriate ioctl for device While reading flags on ./new
>>> lsattr: Inappropriate ioctl for device While reading flags on ./tmp
>>> ./courierimapuiddb: Permission denied
>>> lsattr: Inappropriate ioctl for device While reading flags
>>> on ./courierimapkeywords
>>> ./maildirfolder: Permission denied
>>
>> The 'inappropriate ioctl' just means that the FS doesn't support extended
>> attributes, so we can rule out the files being marked 'immutable' or
>> anything.  I don't think this rules out ACLs, but we've eliminated one
>> common cause for files being undeletable by root.
>>
>> I agree with the advice to fsck to verify that the FS isn't corrupted.
>>
>> Is this on the original or cloned system?  If the latter, what does it
>> look like on the original system?
>>
>> It might also useful to verify the tar file, but I don't know tools for
>> doing this.
>>
>> _______________________________________________
>> Web Page:  http://lug.boulder.co.us
>> Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug
>> Join us on IRC: lug.boulder.co.us port=6667 channel=#colug
>
> Ok,
>
> On the original FS the files are fine.
>
> EX:
>
> # ll /usr/local/virtual/jdeciantis\@celebrityaccess.com/.Trash/
> total 388
> drwx------    6 1001     maildrop      224 Jan 29 10:05 .
> drwx------    9 1001     maildrop      344 Feb 27 18:12 ..
> drwx------    2 1001     maildrop   389600 Jan 29 10:03 courierimapkeywords
> -rw-r--r--    1 1001     maildrop     2460 Jan 29 10:05 courierimapuiddb
> drwx------    2 1001     maildrop     3128 Jan 29 10:05 cur
> -rwx------    1 1001     maildrop        0 Jun 23  2005 maildirfolder
> drwx------    2 1001     maildrop       48 Jun 23  2005 new
> drwx------    2 1001     maildrop       48 Jan 29 10:05 tmp
>
>
> I can't seem to remount the FS readonly for fsck, I get this:
>
> # mount -r -o remount /
> mount: / is busy
>
>
> Is there a way around this? FYI: The machine is remote.
>
> Thanks for your help!
>
>

EMAIL: (h) steve at badcheese.com  WEB: http://badcheese.com/~steve