Linux: „No space left on device“ durch Speicher-, Inode- und Dateianalyse beheben

EdwardMoon

Die Linux-Fehlermeldung No space left on device lässt zunächst an einen vollen Datenträger denken. Neben fehlenden Datenblöcken kommen jedoch auch erschöpfte Inodes, gelöschte und weiterhin geöffnete Dateien, fehlgeschlagene Mounts oder stark anwachsende Logs als Ursache infrage.

Wer ohne Diagnose zuerst Dateien mit rm -rf löscht, kann wichtige Fehlerprotokolle verlieren oder den Dienstausfall verschärfen. Dieser Leitfaden beschreibt eine geordnete Diagnose und sichere Abhilfen für übliche Linux-Server mit Rocky Linux, RHEL, CentOS oder Ubuntu.

Diagnose von No space left on device: Ablauf mit findmnt, df, Inodes, du und lsof — Diagnosereihenfolge nach Ursache des Fehlers No space left on device

No space left on device: fünf Befehle für die erste Diagnose

Bei Zeitdruck die folgenden Prüfungen in dieser Reihenfolge ausführen. Für /path ein tatsächlich vorhandenes Verzeichnis auf demselben Dateisystem wie der fehlerhafte Pfad einsetzen. Konnte die Datei gar nicht erst angelegt werden, das nächstgelegene vorhandene Elternverzeichnis verwenden.

# 1. Dateisystem des fehlerhaften Pfads ermitteln
findmnt -T /path

# 2. Belegung der Datenblöcke prüfen
df -hT /path

# 3. Inode-Belegung prüfen
df -i /path

# 4. Große Verzeichnisse innerhalb desselben Dateisystems suchen
sudo du -xhd1 /path 2>/dev/null | sort -h

# 5. Gelöschte, von Prozessen weiterhin geöffnete Dateien prüfen
sudo lsof +L1 2>/dev/null

Achtung: du und find können auf Servern mit vielen Dateien zusätzliche Datenträger-I/O verursachen. Den Suchbereich eingrenzen und dabei die Last der produktiven Dienste beobachten.

Häufige Ursachen für No space left on device

Ursache	Typisches Symptom	Erster Prüfbefehl
Keine freien Datenblöcke	`Use%` liegt bei 100 % oder nahe dem Grenzwert	`df -hT`
Inodes erschöpft	Freier Speicher vorhanden, aber neue Dateien lassen sich nicht anlegen	`df -i`
Gelöschte, noch geöffnete Dateien	Nach dem Löschen sinkt die von `df` gemeldete Belegung nicht	`lsof +L1`
Stark wachsende Logs oder Caches	`/var` oder das Root-Dateisystem füllt sich schnell	`du`, `journalctl --disk-usage`
Mount fehlgeschlagen	Daten für einen separaten Datenträger landen im Root-Dateisystem	`findmnt -T`, `lsblk -f`

Diagnose 1: Belegung der Datenblöcke prüfen

df -hT
df -hT /var/log

df zeigt für jedes Dateisystem Gesamtgröße, belegten und freien Speicher, Auslastung und Einhängepunkt. -h verwendet gut lesbare Einheiten; -T ergänzt den Dateisystemtyp wie XFS oder ext4. Neben Use% auch Avail prüfen: Dieser Wert beschreibt den für normale Benutzer verfügbaren Platz. Durch reservierte ext4-Blöcke kann root noch Speicher zur Verfügung stehen, obwohl normale Benutzer keinen mehr nutzen können.

Die Gesamtübersicht allein reicht nicht aus. Als Argument ein vorhandenes Verzeichnis auf dem Dateisystem des fehlgeschlagenen Schreibzugriffs angeben. Kann eine Anwendung beispielsweise /data/app.log nicht schreiben, wurde die Datei möglicherweise noch gar nicht erzeugt. Dann das vorhandene Elternverzeichnis /data prüfen.

findmnt -T /data
df -hT /data

Auch bei freiem Platz im Root-Dateisystem können unter /data keine neuen Dateien entstehen, wenn dieses separate Dateisystem voll ist.

Diagnose 2: Inode-Belegung prüfen

df -i
df -i /var

Ein Inode verwaltet Metadaten einer Datei, etwa Rechte, Eigentümer, Größe, Zeitangaben und Datenpositionen. Sehr viele kleine Dateien können alle verfügbaren Inodes verbrauchen, obwohl noch Speicherplatz frei ist. Bei ext4 wird die Inode-Anzahl beim Erstellen des Dateisystems festgelegt, während XFS Inodes dynamisch zuweist. Auch bei XFS können neue Dateien scheitern, wenn Platz für Daten oder Metadaten fehlt. Deshalb df -i und df -hT gemeinsam auswerten.

Steht IUse% bei 100 %, hilft das Entfernen vieler nicht mehr benötigter kleiner Dateien mehr als das Löschen weniger großer Dateien. Verzeichnisse mit vielen Dateien lassen sich mit folgendem Befehl finden.

# Verzeichnisse mit vielen Dateien im Dateisystem von /var suchen
sudo find /var -xdev -type f -printf '%h\n' 2>/dev/null \
  | sort | uniq -c | sort -nr | head -n 30

Häufige Ursachen sind massenhaft angelegte Sitzungsdateien, Anwendungscaches, Mail-Warteschlangen oder temporäre Dateien. Vor dem Löschen unbedingt Aufbewahrungsfristen und Auswirkungen auf Dienste prüfen.

Diagnose 3: große Verzeichnisse und Dateien finden

Ist das Root-Dateisystem voll, zunächst die Belegung seiner obersten Verzeichnisse prüfen und anschließend schrittweise in die großen Verzeichnisse wechseln.

sudo du -xhd1 / 2>/dev/null | sort -h
sudo du -xhd1 /var 2>/dev/null | sort -h
sudo du -xhd1 /var/log 2>/dev/null | sort -h

-x verhindert den Wechsel in andere Dateisysteme. -d1 beschränkt lediglich die Ausgabe auf eine Verzeichnisebene. Tiefer liegende Dateien und Verzeichnisse werden für die Summen weiterhin durchlaufen. Die Option allein verringert somit weder Suchaufwand noch I/O. Die genaue Wirkung der Optionen beschreibt das offizielle GNU-du-Handbuch.

Das folgende Beispiel sucht innerhalb eines bestimmten Dateisystems nach Dateien über 1 GB.

sudo find /var -xdev -type f -size +1G \
  -printf '%s %p\n' 2>/dev/null \
  | sort -nr | head -n 30

Typische Prüfpunkte sind /var/log, /var/cache, /tmp, /home, /opt und /var/lib/docker. Dateien unter /var/lib jedoch nicht wahllos manuell löschen: Das kann Datenbanken oder Container-Laufzeiten beschädigen. Die vorgesehenen Bereinigungsverfahren des jeweiligen Dienstes verwenden.

Diagnose 4: gelöschte, noch geöffnete Dateien prüfen

Hält ein laufender Linux-Prozess eine Datei geöffnet, gibt das Entfernen ihres Namens die Datenblöcke nicht sofort frei. Die Datei ist im Verzeichnis nicht mehr sichtbar und wird von du nicht erfasst. Bis der Dateideskriptor geschlossen wird, bleibt ihr Platz in df jedoch als belegt ausgewiesen.

sudo lsof +L1 2>/dev/null

# Größte Einträge zuerst prüfen
sudo lsof +L1 2>/dev/null \
  | awk 'NR>1 {print $7, $1, $2, $4, $9}' \
  | sort -nr | head -n 30

In der Ausgabe Prozessname, PID, Dateideskriptor und Größe prüfen. Abhilfe schafft, den betreffenden Dienst ordnungsgemäß neu zu starten oder die Anwendung zum erneuten Öffnen der Datei zu veranlassen.

sudo systemctl restart 서비스명
sudo lsof +L1 2>/dev/null
df -hT

Auf Produktionsservern zuvor Redundanz und Auswirkungen prüfen. Prozesse ungeprüft mit kill -9 zu beenden oder Dateien über /proc/PID/fd gewaltsam zu leeren, kann Datenverlust und Ausfälle verursachen und empfiehlt sich nicht als erste Maßnahme.

5. Wenn das systemd-Journal viel Speicher belegt

journalctl --disk-usage

Belegt das systemd-Journal viel Platz, lassen sich ältere archivierte Logs anhand ihrer Größe oder ihres Alters bereinigen.

# Aktive Logs zuerst archivieren, danach archivierte Logs auf höchstens 500 MB begrenzen
sudo journalctl --rotate --vacuum-size=500M

# Archivierte Logs entfernen, die älter als 14 Tage sind
sudo journalctl --vacuum-time=14d

Die Optionen --vacuum-* wirken auf archivierte Journaldateien. Sollen auch die bisher aktiven Logs sofort berücksichtigt werden, ist die Kombination mit --rotate sinnvoll.

Um erneutes Anwachsen zu verhindern, die maximale Journalbelegung passend zur Distribution und den Betriebsvorgaben begrenzen.

# /etc/systemd/journald.conf.d/10-size-limit.conf
[Journal]
SystemMaxUse=1G
RuntimeMaxUse=256M

sudo systemctl restart systemd-journald
journalctl --disk-usage

Als Einführung in die Dienststruktur dient auch der Artikel systemd-Dienste erstellen und ihre Bestandteile verstehen.

6. Daten landen nach einem fehlgeschlagenen Mount auf dem Root-Datenträger

Soll /data auf einem separaten Speicher liegen, ist dieser nach einem Start- oder Netzwerkfehler aber nicht eingehängt, kann die Anwendung unter demselben Pfad im Root-Dateisystem weiterschreiben.

findmnt -T /data
lsblk -f
systemctl --failed
journalctl -b -u '*.mount'

In diesem Fall zuerst die Schreibzugriffe der Anwendung stoppen und den Mount des vorgesehenen Dateisystems wiederherstellen. Zum Prüfen von Dateien, die unter einem Mount verdeckt liegen, ist ein Wartungsverfahren erforderlich, das Dienstauswirkungen und Datenkonsistenz berücksichtigt.

Warum df und du unterschiedliche Werte anzeigen

df meldet die vom Dateisystem zugewiesenen Blöcke. du durchläuft dagegen die im aktuellen Verzeichnisbaum erreichbaren Dateien und berechnet deren Belegung. Unterschiede können daher unter anderem folgende Ursachen haben.

Gelöschte Dateien, die ein Prozess weiterhin geöffnet hält
Dateisystem-Metadaten und reservierte Bereiche
Verzeichnisse, die du wegen fehlender Rechte nicht lesen kann
Andere Dateisysteme, die in Unterverzeichnissen eingehängt sind
Gemeinsam genutzte Blöcke von Snapshots und Copy-on-Write-Dateisystemen

Bei großen Abweichungen zwischen df und du zuerst lsof +L1 und die Mount-Struktur prüfen.

Wiederherstellungsablauf auf Produktionsservern

Fehlerhaften Pfad bestimmen: tatsächlichen Schreibpfad der Anwendung und zugehöriges Dateisystem prüfen.
Weiteres Wachstum stoppen: zuerst die Ursache laufend zunehmender Belegung unterbinden, etwa eine Logflut oder wiederholte Jobs.
Diagnosedaten sichern: benötigte Logs und Zustandsinformationen vor der Bereinigung an einem anderen Ort aufbewahren.
Vorgesehene Bereinigung nutzen: bevorzugt logrotate, Journal-Vacuum und die Cache-Bereinigung der Anwendung verwenden.
Wiederherstellung prüfen: Speicher- und Inode-Belegung, Dateierstellung, Dienststatus und Anwendungslogs erneut kontrollieren.

df -hT /path
df -i /path
touch /path/.write-test && rm -f /path/.write-test
systemctl --failed

Checkliste zur Vorbeugung

Neben der Speicherbelegung auch die Inode-Belegung überwachen.
Warn- und kritische Schwellenwerte getrennt festlegen und die Wachstumsgeschwindigkeit beobachten.
Für Anwendungslogs logrotate oder eine anwendungseigene Aufbewahrungsrichtlinie einrichten.
Maximale Größe und Aufbewahrungsdauer des systemd-Journals gemäß den Betriebsvorgaben begrenzen.
Bei Docker, Datenbanken und Sicherungslösungen die vorgesehenen Bereinigungsfunktionen verwenden.
/var/log, Daten und Sicherungen trennen, damit das Anwachsen eines Bereichs seltener das gesamte Betriebssystem lahmlegt.
Abhängigkeiten und Vorabprüfungen so einrichten, dass Anwendungen bei fehlgeschlagenem Mount nicht auf den lokalen Datenträger weiterschreiben.

Häufige Fragen

Warum erscheint No space left on device trotz freiem Speicher?

Zuerst die Inode-Belegung und das Dateisystem des tatsächlich betroffenen Pfads prüfen. Auch wenn df -h freien Platz zeigt, kann die Dateierstellung scheitern, wenn df -i 100 % meldet oder ein anderer Einhängepunkt voll ist.

Warum sinkt die df-Belegung nach dem Löschen einer Logdatei nicht?

Wahrscheinlich hält ein Prozess die gelöschte Datei weiterhin geöffnet. Den Prozess mit lsof +L1 ermitteln und den Dienst ordnungsgemäß neu starten oder zum erneuten Öffnen der Datei veranlassen, damit der Speicher freigegeben wird.

Dürfen alle Dateien unter /var/log gelöscht werden?

Das ist nicht empfehlenswert. Dabei können Informationen zur Fehlerursache und Audit-Protokolle verloren gehen. Je nach Anwendung fehlen anschließend möglicherweise Rechte, um die Logdatei neu anzulegen. Stattdessen logrotate, journalctl vacuum oder die produktspezifische Logbereinigung verwenden.

Was hilft, wenn du zu langsam ist?

-d1 begrenzt nur die Ausgabetiefe; untergeordnete Dateien werden weiterhin durchlaufen. Zuerst das betroffene Dateisystem und verdächtige Pfade eingrenzen und dort prüfen. -x verhindert die Untersuchung weiterer Dateisysteme. Ergebnisse aufbewahren, damit derselbe Baum nicht wiederholt gescannt wird. Server mit vielen Dateien möglichst bei geringer I/O-Last untersuchen.

Zusammenfassung

Zur Behebung von No space left on device gehört zuerst die Diagnose. Mit findmnt das Ziel-Dateisystem bestimmen, mit df -hT die Blockbelegung, mit df -i die Inodes, mit du die Verzeichnisbelegung und mit lsof +L1 gelöschte, noch geöffnete Dateien prüfen.

Nach der Eingrenzung eine passende Maßnahme umsetzen, beispielsweise Logaufbewahrung anpassen, einen Dienst neu starten oder einen Mount wiederherstellen. So lassen sich Datenverlust und wiederkehrende Störungen vermeiden.