Linux: Datei löschen, Ordner und Verzeichnis löschen mit rm, rm -r und rmdir

Kurz gesagt: Eine Datei löschst du unter Linux mit rm datei.txt. Einen Ordner (ein Verzeichnis) mit seinem gesamten Inhalt löschst du mit rm -r ordnername; rmdir ordnername entfernt nur einen leeren. Einen Papierkorb gibt es nicht: Nichts in der Shell macht rm rückgängig, liste also zuerst auf, was du gleich löschst.

rm old.log                 # eine Datei löschen
rm -r project/             # ein Verzeichnis mit allem darin löschen
rm -rf build/              # dasselbe, ohne jede Rückfrage
rmdir empty-folder/        # ein Verzeichnis nur löschen, wenn es leer ist

Die Ausgaben auf dieser Seite stammen von Debian 12 mit GNU coreutils 9.1, findutils 4.9.0, bash 5.2.15 und lsof 4.95, ausgeführt in einem Scratch-Verzeichnis, teils als Benutzer ohne Root-Rechte. Die Abschnitte zu --preserve-root, chattr, Mountpoints und trash-cli folgen der Dokumentation von coreutils, e2fsprogs und trash-cli und wurden auf diesem Host nicht ausgeführt. Ubuntu, Rocky Linux und AlmaLinux liefern dasselbe GNU-rm aus. Läuft dein System mit deutscher Spracheinstellung, erscheinen dieselben Meldungen auf Deutsch; mit LC_ALL=C vor dem Befehl bekommst du die englischen Originale, nach denen sich leichter suchen lässt.

rm-Spickzettel

Wie lösche ich unter Linux eine Datei?

rm nimmt einen oder mehrere Dateinamen und entfernt sie ohne Rückfrage und ohne Meldung. -v gibt jede einzelne aus. Ein Name, der nicht existiert, ist ein Fehler, es sei denn, du ergänzt -f. Dann endet auch dieser Fall still und erfolgreich:

$ rm -v old.log
removed 'old.log'
$ rm nofile
rm: cannot remove 'nofile': No such file or directory
$ rm -f nofile; echo $?
0

Zum Löschen einer Datei brauchst du Schreibrechte auf das Verzeichnis, in dem sie liegt, nicht auf die Datei selbst. Eine schreibgeschützte Datei in deinem eigenen Verzeichnis lässt sich löschen, aber rm fragt vorher nach, wenn es in einem Terminal läuft:

rm: remove write-protected regular empty file 'wp'? n

Root wird das nie gefragt, und -f überspringt die Frage für alle. Setze Namen mit Leerzeichen in Anführungszeichen: rm my file.txt versucht, my und file.txt zu löschen, und scheitert zweimal mit No such file or directory, während rm "my file.txt" die eine Datei entfernt.

Wie lösche ich einen Ordner mit seinem Inhalt?

Ein einfaches rm lehnt Verzeichnisse ab. -r (rekursiv) löscht das Verzeichnis mit jeder Datei und jedem Unterverzeichnis darin:

$ rm project
rm: cannot remove 'project': Is a directory
$ rm -rv project
removed 'project/src/main.c'
removed directory 'project/src'
removed directory 'project'

rm -rf ergänzt -f: keine Rückfragen bei schreibgeschützten Dateien, kein Fehler bei Namen, die nicht existieren. Deshalb ist es die übliche Form in Skripten und im Terminal die gefährliche, denn ein Tippfehler im Pfad wird genauso still ausgeführt. Für ein leeres Verzeichnis ist rmdir das sicherere Werkzeug, weil es alles ablehnt, was Inhalt hat:

$ rmdir d
rmdir: failed to remove 'd': Directory not empty
$ rmdir -pv d/e
rmdir: removing directory, 'd/e'
rmdir: removing directory, 'd'

rmdir -p d/e hat d/e entfernt und dann d, weil d leer war, sobald e weg war; es hält beim ersten übergeordneten Verzeichnis an, das noch Inhalt hat.

Rückfragen: -i, -I und -f

$ rm -i a
rm: remove regular empty file 'a'? n
$ rm -I c1 c2 c3 c4
rm: remove 4 arguments? n
$ rm -rI tree
rm: remove 1 argument recursively? n

-i fragt bei jeder Datei, was bei drei Dateien in Ordnung ist und bei dreitausend nutzlos. -I fragt einmal, und nur, wenn du mehr als drei Dateien oder rekursiv löschst; bei drei Namen oder weniger läuft es einfach. Damit ist alias rm='rm -I' in ~/.bashrc ein vernünftiges Sicherheitsnetz, das nicht im Weg steht. Von -i, -I und -f gewinnt das letzte auf der Kommandozeile: rm -f -i fragte nach, rm -i -f nicht, ein unter diesem Alias getipptes rm -rf läuft also trotzdem ohne Rückfrage. Skripte sehen den Alias gar nicht: bash expandiert Aliase in einer nicht interaktiven Shell nicht.

Namen mit Bindestrich und die Falle bei rm *

Eine Datei, deren Name mit einem Bindestrich beginnt, sieht aus wie eine Option. GNU rm sagt dir sogar, wie du sie loswirst:

$ rm -foo
rm: invalid option -- 'o'
Try 'rm ./-foo' to remove the file '-foo'.
Try 'rm --help' for more information.
$ rm -- -foo

-- beendet die Optionen, alles danach ist also ein Dateiname; ./-foo funktioniert ebenfalls. Derselbe Mechanismus macht ein nacktes rm * riskant. Die Shell expandiert *, bevor rm läuft, und GNU rm liest eine Datei namens -r als Option, egal wo sie in der Liste landet:

$ ls
-r  a  sub
$ echo rm *
rm -r a sub
$ rm *          # löscht sub/ samt Inhalt, ohne dass du -r getippt hast

Schreib rm ./* oder rm -- *, und die seltsame Datei ist wieder nur eine Datei. Zwei weitere Überraschungen bei Globs: * erfasst keine versteckten Dateien, deshalb ließ rm -rf cache/* die Datei cache/.hidden stehen, und passt gar nichts, übergibt bash das Muster wörtlich, was mit cannot remove '*.tmp': No such file or directory endet. Um ein Verzeichnis komplett zu leeren, es aber zu behalten, nimm find cache -mindepth 1 -delete.

rm -rf / und --preserve-root

GNU rm weigert sich, rekursiv auf / selbst zu arbeiten. Laut dem coreutils-Handbuch ist --preserve-root der Standard, und rm -rf / bricht mit it is dangerous to operate recursively on '/' ab, solange du nicht --no-preserve-root ergänzt. Verlass dich nicht darauf:

• rm -rf /* ist nicht geschützt. Die Shell expandiert es zu /bin /boot /etc ..., und keines davon ist /.
• Eine leere Variable wird zum Pfad. rm -rf "$DIR"/* mit nicht gesetztem DIR ist rm -rf /*. Schreib rm -rf "${DIR:?}"/*: bash bricht dann mit DIR: parameter null or not set ab, bevor rm läuft.
• Ein falsches Verzeichnis ist genauso endgültig. Gegen rm -rf /var/www statt /var/www/old schützt dich nichts.

--preserve-root=all geht einen Schritt weiter: rm verweigert dann auch jedes Argument, das auf einem anderen Dateisystem liegt als sein übergeordnetes Verzeichnis, etwa eine eingehängte Backup-Platte.

Nach Alter oder Muster löschen: find -delete

Für alles, was gezielter sein muss als ein Glob, lass find die Dateien auswählen, und führe es mit -print aus, bevor du -delete einsetzt:

$ find logs -name '*.log' -mtime +14 -print
logs/a.log
logs/old/b.log
$ find logs -name '*.log' -mtime +14 -delete
$ find logs -type d -empty -delete          # dann die Ordner, die jetzt leer sind

Gewohnheiten, die böse Überraschungen verhindern

1. 1Auflisten, was der Befehl trifft

   Lass denselben Pfad zuerst durch ls -d laufen oder das find mit -print, oder setz echo vor das rm. Lies die Liste, dann drück die Pfeiltaste nach oben und ändere nur den Befehl.

2. 2In Skripten absolute Pfade nutzen

   Ein relativer Pfad löscht in dem Verzeichnis, in dem das Skript gerade läuft. Cronjobs starten im Home-Verzeichnis des Benutzers, nicht dort, wo das Skript liegt.

3. 3Variablen absichern

   "${VAR:?}" für jede Variable, die einen Pfad für rm bildet, dazu set -u am Anfang des Skripts.

4. 4Wo es passt, stattdessen in einen Papierkorb verschieben

   Das Paket trash-cli (Debian und Ubuntu: apt install trash-cli) bringt trash-put, trash-list, trash-restore und trash-empty mit, die denselben Papierkorb-Ordner nutzen wie die Dateimanager auf dem Desktop. Praktisch in der interaktiven Shell; auf einem Server wird der Platz erst frei, wenn du den Papierkorb leerst.

Kann ich rm rückgängig machen?

Nein. rm entfernt den Namen aus dem Verzeichnis, und das Dateisystem markiert die Blöcke als frei; es gibt keinen Papierkorb und kein Rückgängig. Wiederherstellungstools für ext4 finden manchmal Blöcke, die noch nichts überschrieben hat, aber ein Server, der ständig Logs und Caches schreibt, verschlechtert diese Chancen mit jeder Minute. Was wirklich hilft:

• Ein Backup oder Snapshot von vorher. Auf einem VMHeaven-VPS legst du Snapshots im Panel an, von Hand oder nach einem täglichen, wöchentlichen oder monatlichen Zeitplan, und stellst sie dort auch wieder her. Einer direkt vor dem Aufräumen kostet eine Minute.
• Ein Prozess, der die Datei noch offen hat. Bis er die Datei schließt, liegen die Daten noch auf der Platte und sind über /proc lesbar. Im Test unter Debian 12 kam eine gelöschte, von einem Prozess noch offen gehaltene Datei mit cp /proc/PID/fd/3 data.db.recovered vollständig zurück. sudo lsof +L1 zeigt die PID und die Nummer des Deskriptors.

rm-Fehler und was sie bedeuten

rm: cannot remove: Permission denied

rm: cannot remove 'f': Permission denied
rm: cannot remove 'locked/f': Permission denied

Beide Dateien waren nur für root beschreibbar, aber das war nicht der Grund: Die Verzeichnisse, in denen sie lagen, gehörten root, und das Entfernen eines Namens ändert das Verzeichnis. In einem Verzeichnis mit Sticky Bit wie /tmp darfst du selbst mit Schreibrechten auf das Verzeichnis nur deine eigenen Dateien entfernen; dieser Fall meldet stattdessen Operation not permitted. Prüfe das übergeordnete Verzeichnis mit ls -ld und korrigiere Besitzer oder Modus wie in der Anleitung zu chmod (engl.) beschrieben, oder führe rm mit sudo aus, wenn die Dateien wirklich zum System gehören.

rm: cannot remove: Operation not permitted, selbst als root

Bekommt root Operation not permitted, trägt die Datei meist das Attribut immutable. Laut der Manpage von chattr lässt sich eine Datei mit +i von niemandem löschen, umbenennen, verlinken oder beschreiben, bis das Attribut entfernt ist:

lsattr suspicious.conf          # ein 'i' in den Flags heißt immutable
sudo chattr -i suspicious.conf
sudo rm suspicious.conf

Eine Datei mit immutable-Attribut, das du nicht selbst gesetzt hast, verdient einen zweiten Blick, bevor du sie löschst: Angreifer nutzen chattr +i, um einen eingeschleusten Cron-Eintrag oder SSH-Schlüssel an Ort und Stelle zu halten.

rm: cannot remove: Device or resource busy

Ein Verzeichnis, an dem ein Dateisystem eingehängt ist, kann rm nicht entfernen. Das trifft rm -r auf ein Verzeichnis, unter dem etwas eingehängt ist, etwa ein Docker-Volume oder ein Bind-Mount. findmnt -R /path listet, was dort eingehängt ist. Achte darauf, was vor dem Fehler passiert ist: rm steigt standardmäßig in eingehängte Dateisysteme hinab und löscht darin, was es kann, bevor es am Mountpoint scheitert. Hänge das Dateisystem zuerst aus oder ergänze --one-file-system; dann überspringt rm jedes Verzeichnis auf einem anderen Dateisystem als dem des angegebenen Pfads. Auf NFS kann dieselbe Meldung von .nfsXXXX-Dateien kommen, die für gelöschte Dateien stehen, die ein Prozess noch offen hat; sie verschwinden, wenn der Prozess sie schließt.

Große Datei gelöscht, aber die Platte ist immer noch voll?

Löschen entfernt den Namen. Hat ein Prozess die Datei noch offen, typischerweise eine Logdatei, in die die Anwendung weiter schreibt, bleibt der Platz belegt, bis der Prozess sie schließt. df sagt voll, du findet nichts. lsof +L1 listet Dateien, die keinen Namen mehr haben:

COMMAND    PID USER   FD   TYPE DEVICE SIZE/OFF NLINK    NODE NAME
sleep   353107 root    3w   REG    8,1  5242880     0 3542659 /srv/app/app.log (deleted)

Starte den Prozess neu oder lade ihn neu, um den Platz freizugeben, oder leere ein Log, das du nicht mehr brauchst, über /proc mit : > /proc/353107/fd/3; im Test setzte das SIZE/OFF auf 0, während der Prozess weiterlief. Wie du diese Liste auf einem ausgelasteten Server sortierst, zeigt die Anleitung zu lsof (engl.), und um den Rest einer vollen Platte geht es in No space left on device (engl.). Bevor du etwas löschst, um Platz zu schaffen, sieh mit du und df (engl.) nach, was ihn wirklich belegt.

Häufige Fragen