rm (von remove) ist eines der mächtigsten und gefährlichsten Werkzeuge auf der Linux-Kommandozeile. Es entfernt Dateien und Verzeichnisse sofort und ohne Papierkorb — was weg ist, ist im Regelfall weg. Wer mit rm arbeitet, sollte verstehen, was beim Löschen technisch passiert, welche Optionen schützen und welche Stolperfallen dich in Sekunden ein ganzes Home-Verzeichnis kosten können.

Was rm wirklich tut

Der Name suggeriert, dass rm Dateien „löscht”. Technisch korrekt ist das nicht. rm entfernt einen Verzeichnis-Eintrag (eine Verbindung zwischen Dateiname und Inode) und dekrementiert den Link-Counter des Inodes um eins. Erst wenn dieser Counter den Wert null erreicht — also kein einziger Hardlink mehr auf die Datei zeigt — gibt das Dateisystem die zugehörigen Datenblöcke zur Wiederverwendung frei.

Wichtig: Freigegeben heißt nicht überschrieben. Die Datenblöcke liegen physisch weiterhin auf der Disk, bis ein anderer Prozess neue Daten genau auf dieselben Sektoren schreibt. Solange das nicht passiert, können forensische Werkzeuge die Datei rekonstruieren.

Syntax

Bash
rm [OPTION] DATEI...
Optionen
-i, --interactive

Fragt vor jedem Löschen nach. Sicherste Variante für interaktive Sessions, bei vielen Dateien aber nervig.

-I

Fragt nur einmal nach, wenn mehr als drei Dateien gelöscht werden oder rekursiv gelöscht wird. Guter Kompromiss zwischen Sicherheit und Bedienbarkeit.

-f, --force

Erzwingt das Löschen. Ignoriert nicht existierende Dateien, fragt nicht nach. Überstimmt -i.

-r, -R, --recursive

Löscht Verzeichnisse rekursiv samt Inhalt. Ohne diese Option lehnt rm Verzeichnisse ab.

-d, --dir

Löscht leere Verzeichnisse — Alternative zu rmdir.

-v, --verbose

Gibt für jede gelöschte Datei eine Zeile aus.

--preserve-root

Lehnt das Löschen von / ab. Standardverhalten der GNU-Coreutils.

--no-preserve-root

Hebt den Schutz für / auf. Diese Option will niemand jemals brauchen.

--one-file-system

Bei rekursivem Löschen: Bleibt innerhalb desselben Dateisystems. Schützt vor versehentlichem Löschen über Mount-Points hinweg.

--help

Zeigt die Hilfe an.

--version

Zeigt Versionsinformationen.

Verzeichnisse löschen

Ohne -r lehnt rm Verzeichnisse rundheraus ab.

Bash Verzeichnis ohne -r
rm projekt/
Output
rm: cannot remove 'projekt/': Is a directory

Für Verzeichnisse samt Inhalt brauchst du die rekursive Option:

Bash Verzeichnis rekursiv löschen
rm -r alter-build/

Leere Verzeichnisse löschst du klassisch mit rmdir oder mit rm -d. Beide schlagen fehl, sobald das Verzeichnis noch Inhalt hat — eine willkommene Schutzfunktion, wenn du dir nicht sicher bist:

Bash Leeres Verzeichnis löschen
rmdir leerer-ordner/
rm -d leerer-ordner/

Sicheres Arbeiten mit rm

Die wichtigste Regel zuerst: Vor jedem Glob-Löschen erst ls mit demselben Glob. Wenn ls *.log die richtigen Dateien anzeigt, kannst du rm *.log mit ruhigem Gewissen ausführen — und nicht vorher.

Bash Prüflauf vor dem Löschen
ls -la /var/log/myapp/*.log
rm /var/log/myapp/*.log

Viele Distributionen setzen einen schützenden Alias für interaktive Shells:

Bash rm-Alias
alias rm='rm -i'

Damit wird jedes rm zu rm -i und du wirst pro Datei gefragt. Aber Vorsicht: In Skripten greift dieser Alias nicht, dort verhält sich rm weiterhin ungefragt. Ein zweiter sinnvoller Schutz ist der Standard-Schalter --preserve-root, der seit Jahren in GNU-Coreutils aktiviert ist und das Löschen von / verhindert. --no-preserve-root solltest du als Schalter behandeln, den du niemals anfasst.

Was passiert wirklich beim Löschen?

Im Detail läuft beim Aufruf von rm datei.txt das Folgende ab:

SchrittWas passiert im Dateisystem
1. Verzeichnis-Eintrag entfernenDer Eintrag datei.txt → Inode 12345 wird aus dem Verzeichnis gelöscht
2. Link-Counter dekrementierenDer nlink-Zähler des Inodes wird um 1 reduziert
3. Inode prüfenIst der Counter > 0, bleibt die Datei über andere Hardlinks erreichbar
4. Inode freigebenBei Counter = 0 und keinen offenen Dateideskriptoren wird der Inode freigegeben
5. Datenblöcke markierenDie zugehörigen Blöcke werden als „frei” markiert — nicht überschrieben

Genau dieser letzte Schritt ist der Grund, warum Recovery möglich ist. Werkzeuge wie extundelete, testdisk oder photorec können freigegebene Datenblöcke auslesen, solange sie nicht durch neue Schreibvorgänge überschrieben wurden. Bei modernen, viel beschriebenen Dateisystemen sinken die Chancen schnell — bei selten beschriebenen Backup-Disks sind sie hoch.

Ein Sonderfall: Wenn ein Prozess die Datei beim Löschen noch geöffnet hält, bleibt der Inode bestehen, bis der letzte Dateideskriptor geschlossen wird. So kannst du Logfiles eines laufenden Daemons löschen, ohne dass dieser stürzt — der Prozess schreibt weiter in den Inode, der Verzeichnis-Eintrag ist aber weg.

Sicheres Löschen mit shred

Soll eine Datei nachweislich nicht mehr rekonstruierbar sein, brauchst du mehr als rm. Klassisch ist shred: das Werkzeug überschreibt die Datei mehrfach mit Zufallsdaten, bevor es sie löscht.

Bash Datei sicher löschen
shred -v -n 3 -z -u geheim.txt
OptionBedeutung
-vVerbose, zeigt Fortschritt an
-n 3Drei Überschreib-Durchgänge mit Zufallsdaten
-zLetzter Durchgang mit Nullen, kaschiert die Spuren
-uUnlink — entfernt die Datei nach dem Überschreiben

shred funktioniert verlässlich auf klassischen Magnetplatten mit ext4 ohne Journal-Daten-Modus. Auf vielen modernen Setups dagegen nicht zuverlässig:

  • SSDs: Wear-Leveling und TRIM verteilen Schreibvorgänge auf andere Zellen — shred kann nicht garantieren, dass die ursprünglichen Daten überschrieben werden. Stattdessen den ATA-Befehl Secure Erase oder Hersteller-Tools nutzen.
  • Journaling-Dateisysteme: Bei ext4 mit data=journal oder bei btrfs/zfs werden Daten an mehreren Stellen geschrieben. shred überschreibt nur den ursprünglichen Block.
  • Verschlüsselte Dateisysteme: Sind ohnehin geschützt — bei verlorenem Schlüssel sind die Daten nicht lesbar.
  • Cloud- und Netzwerk-Dateisysteme: Sind außerhalb der Kontrolle von shred.

Für ganze Datenträger ist wipe, nwipe oder das Tool BleachBit praktischer.

rm vs. Alternativen

Wer sicherer arbeiten will, muss nicht zwingend bei rm bleiben. Es gibt mehrere etablierte Alternativen:

WerkzeugVerhalten
trash-cliVerschiebt Dateien in den XDG-Papierkorb (~/.local/share/Trash/). Wiederherstellbar, kompatibel zu Dateimanagern wie Nautilus oder Dolphin
gio trashGNOME-Bordmittel, gleiche XDG-Konvention wie trash-cli
find ... -deleteLöscht direkt ohne Umweg über rm. Effizienter für viele Dateien, aber dieselben Risiken wie rm
rmdirLöscht ausschließlich leere Verzeichnisse — fehlersicher
Dateimanager-TrashGrafische Oberflächen verschieben in ~/.local/share/Trash/ (XDG-Standard)

trash-cli lässt sich elegant aliasen, sodass du den Workflow von rm behältst, aber einen Papierkorb gewinnst:

Bash trash-cli als rm-Ersatz
alias rm='trash-put'

Häufige Stolperfallen

rm -rf / — der Klassiker unter den Katastrophen

Auch wenn die GNU-Coreutils heute standardmäßig —preserve-root setzen und das Löschen von / ablehnen, ist nicht jede rm-Implementierung gleich vorsichtig. BusyBox, ältere Unix-Varianten und manche eingebetteten Systeme schützen / nicht. Außerdem hilft der Schutz nicht gegen Varianten wie rm -rf /* oder rm -rf /home/../. Niemals auf den Standard-Schutz verlassen — sondern den Befehl vorher prüfen.

Leere Variablen können dein System zerlegen

rm -rf $VAR/ wird zu rm -rf /, wenn $VAR leer oder nicht gesetzt ist. Genau dieser Bug hat 2015 Steam unter Linux berühmt gemacht: Ein Installer-Skript enthielt rm -rf “$STEAMROOT/”* — bei Nutzern mit nicht gesetzter Variable wurde das gesamte Home-Verzeichnis gelöscht. Schutz: in Skripten immer set -u aktivieren oder ${VAR:?Fehler} verwenden, das bei leerer Variable abbricht.

Globs mit Leerzeichen sprengen sich selbst

rm -rf $HOME/Mein Projekt/* löscht nicht das gewünschte Verzeichnis, sondern zwei Argumente: $HOME/Mein und Projekt/*. Letzteres bezieht sich auf das aktuelle Arbeitsverzeichnis. Pfade mit Leerzeichen oder Sonderzeichen immer in doppelte Anführungszeichen setzen: rm -rf “$HOME/Mein Projekt/”* — und idealerweise vorher mit ls prüfen.

Symlinks zu Verzeichnissen — das Slash entscheidet

Bei rm symlink wird der Symlink selbst entfernt. Bei rm -r symlink/ mit angehängtem Slash dagegen folgt rm dem Symlink und versucht, das Zielverzeichnis rekursiv zu löschen. Das ist kontraintuitiv und besonders gefährlich, wenn der Symlink auf ein wichtiges Verzeichnis außerhalb des Arbeitsbereichs zeigt. Im Zweifel den Slash weglassen und mit ls -l symlink prüfen, wohin er zeigt.

rm -f ist kein Allheilmittel gegen Permission denied

-f bedeutet force, aber nicht ignore permissions. Wenn du keine Schreibberechtigung im übergeordneten Verzeichnis hast, schlägt das Löschen fehl — die Datei-Permissions selbst sind irrelevant, denn rm ändert das Verzeichnis, nicht die Datei. Lösung: Schreibrechte auf dem Eltern-Verzeichnis (oder sudo), nicht auf der Datei.

Dotfiles werden bei rm mit Glob nicht erfasst

Der Glob * matcht in der Bash standardmäßig keine Dateien, deren Name mit einem Punkt beginnt. rm -rf projekt/* löscht den sichtbaren Inhalt, lässt aber .git, .env und Konfigurationen stehen. Wer wirklich alles entfernen will, braucht shopt -s dotglob oder das explizite Muster rm -rf projekt/{*,.[!.]*}. Umgekehrt schützt das Standardverhalten manchmal vor dem versehentlichen Löschen sensibler Konfigurationen — beides solltest du bewusst entscheiden.

Kein Backup, keine Gnade

Recovery-Tools wie extundelete oder photorec können freigegebene Datenblöcke retten — aber nur, wenn sie noch nicht überschrieben wurden. Auf einem aktiven System ist das oft Sekundensache. Die einzige verlässliche Strategie gegen rm-Unfälle ist ein aktuelles Backup. Snapshot-Dateisysteme wie btrfs oder zfs erlauben sogar, einzelne Versionen wiederherzustellen, ohne ein externes Backup zu bemühen.

Weiterführende Ressourcen

Externe Quellen

/ Weiter

Zurück zu Dateisystem

Zur Übersicht