[linux] ls ziet niks, rm kan niet verwijderen

[Verwijderd]

Ik heb een beetje wazig probleem, ik heb nl een redhad bak en als ik in een bepaalde directory een ls -lia doe is deze directory leeg. maar doe ik dan een rm -rf op die directory volgt de melding dat de directory nie leeg is. Dit alles doe ik als root dus de rechten moet ik wel hebben.

De directory is de incomming map van de ftp server (proftpd)

[Verwijderd]

Misschien heeft een deamon of ander proggie een lock in of op die directory.

Probeer is het command "lsof" op de directory om te kijken wie er allemaal met ze tengels aanzit

Meest waarschijnlijke is overigens dat proftpd een lock heeft op die dir, dus die zal je dan eerst moeten killen om die dir te kunnen verwijderen.

edit:

Spell check, and additions

[ Voor 43% gewijzigd door Verwijderd op 15-01-2004 13:37 ]

[Verwijderd]

Ook gechecked of er geen bestanden in die map staan waar een . voor staat?

[Verwijderd]

Verwijderd schreef op 15 januari 2004 @ 13:40:
Ook gechecked of er geen bestanden in die map staan waar een . voor staat?

Die zou rm -Rf in princiepe ook mee moeten nemen. Dus ik denk niet dat daar het probleem ligt.

[Wilke]

Huh Sinds wanneer klaagt rm -rf als een dir niet leeg is?

Is dit een of ander fijn Red Hat trucje ofzo

Welke Red Hat versie, en welke melding krijg je precies?

[Verwijderd]

ls -lia zegt ie toch?
post je /root/.bashrc is.. daar zou 't in de verte ook nog aan kunnen liggen, maar default niet..

en volgens mij maakt redhat default een alias aan voor rm e.d. zodat de -i (geloof ik) switch meegepasst wordt die (geloof ik) om bevestiging vraagt. alleen bij root overigens (of -f daar nog doorheen dramt weet ik zo ook niet)

[ Voor 54% gewijzigd door Verwijderd op 15-01-2004 13:46 ]

[Confusion]

En ls -a zou ze moeten laten zien.

edit:
Dit was als direct aanvulling op JUDGExKTF bedoeld DeMon, maar er zijn nogal veel mensen aan het replyen . Mijn punt was dat ls en rm hetzelfde mechanisme gebruiken om de files in de directory te weten te komen IIRC

[ Voor 92% gewijzigd door Confusion op 15-01-2004 13:51 ]

[Verwijderd]

wat trouwens mischien ook wel handig is om te vertellen, is dat steeds in de directory's welke ik nie kan verwijdren, steeds rar files stonden. toevallig was iedre keer *.r40 weg. en als je deze der later weer heen probeerd te ftp-en zegt ut ftp programma, dat de file al bestaat. dus denk dat dat brakke proftpd de boos doenner is.

[DeMoN]

Confusion schreef op 15 januari 2004 @ 13:44:
En ls -a zou ze moeten laten zien.

Ja maar dat heeft ie toch al gedaan?
Misschien dat er een alias staat in de bashrc maar dat lijkt me niet want dan zal het waarschijnlijk ook niet werken in andere dirs. En volgens mij heeft hij alleen bij één bepaalde dir dit probleem.

[pistole]

Verwijderd schreef op 15 januari 2004 @ 13:44:
wat trouwens mischien ook wel handig is om te vertellen, is dat steeds in de directory's welke ik nie kan verwijdren, steeds rar files stonden. toevallig was iedre keer *.r40 weg. en als je deze der later weer heen probeerd te ftp-en zegt ut ftp programma, dat de file al bestaat. dus denk dat dat brakke proftpd de boos doenner is.

heb je al een

lsof | grep <naamvanjoudir>

gedaan? En anders eens proftpd stoppen en nogmaals proberen.

[ Voor 7% gewijzigd door pistole op 15-01-2004 13:52 ]

[Wilke]

Hmmmmmmm.......

En unmount anders die partitie eens en check 'm met e2fsck (of reiserfsck, wat voor filesystem is het eigenlijk?)

Het is namelijk echt abnormaal dat je een directory niet kunt verwijderen met 'rm -rf'. Zojuist wees moto-moi me er op dat dit op een manier toch mogelijk is, als je met 'chattr +i bestand' (dit is ext2- en dus per definitie ook linux-specifiek) het 'immutable' bit zet, maar het lijkt me niet dat er veel progs bestaan die dit doen, en FTP servers al zeker niet - bovendien kun je dit ook alleen als root doen.

[usr-local-dick]

Iemand heeft een zooitje warez geupload en die in een ellen lange tree gezet met hele fijne namen die heel moeilijk zijn te benaderen met jouw unix shell. Ik had dit ook ooit, een map met de naam --="THeKing"=-- enzo
Ga daar maar even in kijken met cd ja?

[Wilke]

usr-local-dick: Dan nog maakt dat niets uit als je domweg 'rm -rf' op die hele dir doet.

[Verwijderd]

de laatste keer dat ik redhat had, stond er in .bashrc van root een alias voor rm en rmdir, zodat ie altijd om bevestiging vraagt, maar ik weet niet of -f daar boven staat?

[Verwijderd]

ff kleine update, als ik een vi doe op de excate bestandsnaam dan leest vi het hele bestand wel gewoon in, probeer ik het bestand dan ergens anders heen te schrijven werkt het neit en blijft hij daar ook ontzichbaar. als ik nu een rm op de exacte bestandsnaam doe word deze alleen niet verwijderd. als iemand nog eens wat weet houd ik me aanbevolen!

[blaataaps]

wat zegt 'strace rm bestandsnaam' ? wat zegt cp als je het probeert te kopieren? heb je al een fsck geprobeerd?

[Wilke]

Verwijderd schreef op 16 januari 2004 @ 14:58:
als iemand nog eens wat weet houd ik me aanbevolen!

ja, wat ik dus zeg. Het fs checken met whateverfsck (ext2fsck, reiserfsck, ...)

[Robtimus]

Verwijderd schreef op 15 januari 2004 @ 14:20:
de laatste keer dat ik redhat had, stond er in .bashrc van root een alias voor rm en rmdir, zodat ie altijd om bevestiging vraagt, maar ik weet niet of -f daar boven staat?

Er staat idd iets als rm="rm -i", maar omdat een rm -f dan wordt "rm -i -f", en de -f later staat, telt de -f zwaarder en wordt dus alsnog alles verwijderd zonder bevestiging. Als je daarentegen (zonder alias) een "rm -f -i" doet, moet je WEL weer bevestigen.

[Justin_Time]

Het kan ook dat rm een alias is geworden door redhat.

Probeer het is met het absolute path.

/bin/rm -fr /jouwdirectory

ps: sorry slaap iets teveel zie dat dit al eerder is aangestipt.

[ Voor 22% gewijzigd door Justin_Time op 16-01-2004 15:30 ]

[igmar]

Verwijderd schreef op 15 januari 2004 @ 14:20:
de laatste keer dat ik redhat had, stond er in .bashrc van root een alias voor rm en rmdir, zodat ie altijd om bevestiging vraagt, maar ik weet niet of -f daar boven staat?

Dat verklaart het nog steeds de melding niet. Indien het alias je dwars zit : unalias rm doet wonderen

[arikkert]

Wilke schreef op 15 januari 2004 @ 14:18:
usr-local-dick: Dan nog maakt dat niets uit als je domweg 'rm -rf' op die hele dir doet.

dat d8 ik ook toen ik daarmee te maken kreeg bij een ftp directory van 1 van onze klanten. daar stond ook een serie dirs in dirs in dirs enz en ergens heel diep daarin een symlink naar een system file. Het was een hack waarbij gebruik wordt gemaakt van een volgelopen tabel/array/bufferoverflow of wat dan ook van de unix distributie. Was opgelost door een guru die iets deed als recursief afdalen en vanaf daar op slimme manier removen.
maar kijk vanwege die links i.i.g. dus uit met als root "rm -rf dir", misschien eerst iets als "su - {ownervandiedirs}" doen

[Verwijderd]

als je gewoon rm <linknaam> doet, verwijdert ie toch de link en niet de file waar ie naar linkt? of is dat alleen bij zachte links?

[mOrPhie]

Is er niet een deamon of anderzins progje dat bij het verwijderen van een bestand het bestand weer terugplaatst? Een bepaald bestandje dat nodig is voor iets anders?

"rm -rf" is volgens mij niets meer dan een sequentie (+ recursief) van de 2 acties (op de achtergrond iets slimmer natuurlijk, door er een transactie van te maken, zodat bij een fout de oude situatie weer wordt hersteld):

• rm dir/*
• rm dir

Als er dan na de eerste actie iets wordt terug geplaatst dan kan hij de directory niet verwijderen. Waarna "rm dir" niet meer gaat. Of "lockt" rm de directory eerst voor dit soort dingen?

Affin, dit zou zomaar kunnen. lsof zou dit ook niet kunnen listen, dus dat zou dat ook duidelijk maken.

[Verwijderd]

Eerst moet je een paar zaken controleren:

1. Zie je niet toevallig filetjes met tekens zoals * { } o.i.d. in de directory staan ?
2. Heb je geen mount point in onder de directory die je wilt verwijderen in gebruik ?
Dus controleer met df -k of de betreffende directory niet voorkomt in het lijstje.

3. Is je machine niet gehacked ? Immers het resultaat dat df -kweergeeft kan met een kernel module worden "aangepast". Dit kan je maar op een manier controleren, booten vanaf een installatie cd (maakt niet uit welke Linux distro). Mount de disk waarop de directory staat en verwijder hem.
Daarna moet je maar eens kijken of er op de bootpartitie geen "vreemde" files voorkomen of dat er aanpassingen zijn gemaakt aan /etc/rc.local o.i.d.
Check out : http://www.forensics.nl/ of zoek op www.securityfocus.com op keyword forensics.

Als je zeker weet dat er geen processen zijn die files open houden in de directory, of dat je machine gehacked is, dan moet je eens de volgende truuk proberen:

Ga in de directory die je wilt verwijderen staan met cd. Controleer of dat zo is met pwd. Anders verwijder je namelijk iets dat je niet wilt verwijderen.

# met onderstaande opdracht verwijder je eerst alle files uit de betreffende directory:
find . - type f -exec unlink {} \;
# met onderstaande opdracht verwijder je vervolgens alle onderliggende directories;
find . - type d -exec rmdir {} \;
cd ..
rm -rf "de directory die je wil verwijderen"