Hard to get rid of two files
in [Shell]
|
Prev: Find error
Next: Drop '$' with sed
From: John W. Krahn on 23 Jun 2008 14:50 Bill Marcum wrote: > On 2008-06-23, John W. Krahn <someone(a)example.com> wrote: >> >> Old Man wrote: >>> John W. Krahn wrote: >>>> I've got a couple of files in lost+found that were left there after an >>>> fsck operation: >>>> >>>> -rwS--s-wT 1 1418 36752 92966795 1972-12-11 16:06 #48581751 >>>> --wSr--rw- 1 1418 34988 92965031 1972-12-11 15:37 #48582225 >>>> >>>> I've tried "rm -f" and chmod but I keep getting an "Operation not >>>> permitted" message. >>>> >>>> How can I remove these files? >>>> >>>> (Files are on an external USB mounted hard drive if that matters.) >>> You might try "rm -i \#*" and read the interactive messages >>> very carefully before entering a response. >>> >>> If that doesn't work, "rm -i *", and put your finger on the "q" >>> key just in case you get key happy. >> "rm -i" doesn't help, I just get the message "Operation not permitted". >> > Make sure the drive isn't mounted read-only, although if it is you > should get a "read-only filesystem" error message. > You might try fsck again. Remember to umount the drive first, and use > "fsck -f" to check the file system even if it seems to be clean. "fsck -f" is how I got the files in lost+found in the first place. John -- Perl isn't a toolbox, but a small machine shop where you can special-order certain sorts of tools at low cost and in short order. -- Larry Wall
From: John W. Krahn on 23 Jun 2008 14:51 Todd H. wrote: > "John W. Krahn" <someone(a)example.com> writes: > >> I've got a couple of files in lost+found that were left there after an >> fsck operation: >> >> -rwS--s-wT 1 1418 36752 92966795 1972-12-11 16:06 #48581751 >> --wSr--rw- 1 1418 34988 92965031 1972-12-11 15:37 #48582225 > > What the heck is the T file mode in this context? > > I assume it's something to do with a sticky bit, but its impact I'm > not sure? > > Root should be able to wack these. Otherwise, you can create userid > that have those UID's and use that user to try to delete them with > those users. But root should be able to wack anything...shouldn't it? That's what I thought. > What file system is in use by the external drive? ext3 John -- Perl isn't a toolbox, but a small machine shop where you can special-order certain sorts of tools at low cost and in short order. -- Larry Wall
From: Stephane CHAZELAS on 23 Jun 2008 14:55 2008-06-23, 17:06(+00), John W. Krahn: > I've got a couple of files in lost+found that were left there after an > fsck operation: > > -rwS--s-wT 1 1418 36752 92966795 1972-12-11 16:06 #48581751 > --wSr--rw- 1 1418 34988 92965031 1972-12-11 15:37 #48582225 > > I've tried "rm -f" and chmod but I keep getting an "Operation not > permitted" message. > > How can I remove these files? > > (Files are on an external USB mounted hard drive if that matters.) What FS? Check the mount options for anything dodgy. (cat /proc/mounts on Linux may be more reliable than the mount(1) output). If ext2/ext3, check lsattr(1) output for those files and the directory containing them. It could be that the ext2 attributes are as messed up as the permissions. ~$ sudo chattr +i a ~$ lsattr a ----i------------- a ~$ sudo rm a rm: cannot remove `a': Operation not permitted ~$ sudo chattr -i a ~$ sudo rm a ~$ If other FS, look for equivalent /extended attributes/ that would make the files unremovable -- St�phane
From: Doug Freyburger on 23 Jun 2008 15:02 comph...(a)toddh.net (Todd H.) wrote: > "John W. Krahn" <some...(a)example.com> writes: > > > I've got a couple of files in lost+found that were left there after an > > fsck operation: > > > -rwS--s-wT 1 1418 36752 92966795 1972-12-11 16:06 #48581751 > > --wSr--rw- 1 1418 34988 92965031 1972-12-11 15:37 #48582225 > > What the heck is the T file mode in this context? And note the setuid bit on both and the setgid bit on one. > I assume it's something to do with a sticky bit, but its impact I'm > not sure? So they are both compiled binary programs. It's an important hint I think. The sticky bit hasn't meant much for programs for a long time (keep the pages of PIC code in swap space then jump to it and page it in the next time it's used) but it's yet another clue that they are programs. > Root should be able to wack these. Otherwise, you can create userid > that have those UID's and use that user to try to delete them with > those users. But root should be able to wack anything...shouldn't it? The times I've gotten "operation not permitted" was when I tried to delete programs currently running in backgroup. Consider the HPUX method of moving the image to a new name and write a post-script to deelte them. > What file system is in use by the external drive? My questions is - What programs are running in background off of a USB stick? Why was fsck run on a stick with running programs? Does this add up that they are malicious programs that deleted themselves once they were in backgroud so they'd be harder to find? My suggestion - Before any more work at deleting them, copy them to another USB stick and confirm with "cmp" the copies are intact. Then use "lsof" to find their PIDs and kill them. Then clean them, unmount the stick, and start doing "strings" and such on the copies to confirm they are not malicious code.
From: John W. Krahn on 23 Jun 2008 15:13
Stephane CHAZELAS wrote: > 2008-06-23, 17:06(+00), John W. Krahn: >> I've got a couple of files in lost+found that were left there after an >> fsck operation: >> >> -rwS--s-wT 1 1418 36752 92966795 1972-12-11 16:06 #48581751 >> --wSr--rw- 1 1418 34988 92965031 1972-12-11 15:37 #48582225 >> >> I've tried "rm -f" and chmod but I keep getting an "Operation not >> permitted" message. >> >> How can I remove these files? >> >> (Files are on an external USB mounted hard drive if that matters.) > > What FS? ext3 > Check the mount options for anything dodgy. (cat /proc/mounts on > Linux may be more reliable than the mount(1) output). > > If ext2/ext3, check lsattr(1) output for those files and the > directory containing them. It could be that the ext2 attributes > are as messed up as the permissions. Thanks, that did the trick. I forgot about attributes as I am more used to using the Reiser FS. John -- Perl isn't a toolbox, but a small machine shop where you can special-order certain sorts of tools at low cost and in short order. -- Larry Wall |