Eine volle Systempartition kann NAS-Apps stoppen, selbst wenn im großen Datenpool noch Terabytes frei sind.
Anwendungen benötigen lokalen Speicherplatz für Protokolle, Datenbanken, temporäre Dateien, Aktualisierungen, Container-Layer, Sockets und Konfigurationsänderungen. Ermittle, welches Mount voll ist, ordne den App-Fehler einem fehlgeschlagenen Schreibvorgang zu, finde den Systemverbraucher und gib Speicherplatz über die dafür zuständige Komponente frei.
Bestätige, dass die Systempartition das volle Mount ist
Prüfe alle eingehängten Dateisysteme und ermittle die Pfade für Root, Boot, Anwendungen, Container und Daten. Zuerst musst du das genau betroffene volle Mount bestätigen, denn freier Speicherplatz im Datenpool kann einen Schreibvorgang auf dem Root-Dateisystem nicht ermöglichen.
Verwende df -h für die Blockkapazität und df -i für die Dateieinträge. Ein Pfad kann neue Dateien ablehnen, wenn freie Blöcke und freie Inodes getrennte Grenzwerte sind und einer davon erschöpft ist.
| App-Symptom | Wahrscheinlich fehlgeschlagener Schreibvorgang | Prüfung |
|---|---|---|
| Anmelde- oder Datenbankfehler | Datenbank-Journal oder Socket | App-Protokolle und Datenbankpfad |
| Aktualisierung oder Installation schlägt fehl | Paket-Cache oder temporäre Datei | Root- und temporäre Mounts |
| Container lässt sich nicht starten | Overlay-Layer, Protokoll oder Statusdaten | Speicherplatzverbrauch des Containers |
| Uploads schlagen fehl | Temporärer Bereitstellungspfad | Konfiguriertes temporäres Verzeichnis |
App-Ausfälle mit fehlendem Schreibspeicherplatz abgleichen
Lies die App-, Datenbank-, Container- und Systemprotokolle auf Meldungen wie „no space left“, schreibgeschütztes Dateisystem, fehlgeschlagenes Journal oder die Unfähigkeit, eine temporäre Datei zu erstellen. Eine App zeigt ihre Webseite möglicherweise weiterhin aus dem Arbeitsspeicher an, während Hintergrundaufgaben, Uploads und Datenbank-Commits fehlschlagen.
Notiere die Zeitstempel und teste einen unbedenklichen Schreibvorgang im betroffenen Pfad. Vermeide umfangreiche Neustarts, bis du die Beweise gesichert hast. Ein Neustart aller Apps kann weitere Protokolle erzeugen, den ersten Fehler verschleiern und verändern, welcher Dienst als Nächstes ausfällt.
Protokolle, Container-Layer, Inodes und gelöschte Dateien finden
Messen Sie die Größe der Systemverzeichnisse der obersten Ebene und untersuchen Sie dann das größte davon genauer. Häufige Speicherfresser sind Journale, Anwendungsprotokolle, Image-Layer, Build-Caches, Absturzprotokolle, Paket-Caches, Vorschaubilder und temporäre Dateien. Prüfen Sie die Berichte der App oder des Container-Managers, bevor Sie undurchsichtige Datenverzeichnisse löschen.
Wenn die Verzeichnisgrößen die Dateisystemnutzung nicht erklären, prüfen Sie, ob gelöschte Dateien noch geöffnet sind. Sind alle Inodes belegt, suchen Sie nach Verzeichnissen mit sehr vielen kleinen Cache- oder Sitzungsdateien. Richten Sie nach der Wiederherstellung Protokollrotation und Aufbewahrungsgrenzen ein, statt wiederholt Dateien in einer Notlage zu löschen.
Speicherplatz sicher freigeben und Wiederherstellung überprüfen
Beginnen Sie mit den dokumentierten Bereinigungsverfahren: Rotieren oder leeren Sie Protokolle, entfernen Sie nachweislich nicht mehr benötigte Paket-Caches, bereinigen Sie nur ungenutzte Container-Artefakte und löschen Sie alte Absturzprotokolle mit den dafür vorgesehenen Tools. Bewahren Sie Datenbanken, benannte Volumes, aktive Images und Konfigurationen auf, bis Sie eine verifizierte Sicherung haben.
Prüfen Sie erneut die Nutzung des Dateisystems und der Inodes. Starten Sie dann nur die betroffene Abhängigkeitskette neu und testen Sie einen echten Schreibvorgang der App. Wenn die Wiederherstellung weiterhin fehlschlägt, untersuchen Sie die Reihenfolge des Dienststarts nach einem Neustart, statt anzunehmen, dass weiterhin der Speicherplatz die Ursache ist.
FAQ
Warum funktioniert eine App nicht, obwohl im NAS-Datenpool noch Speicherplatz frei ist?
Die App schreibt ihre Datenbank, Protokolle, temporären Dateien oder den Containerstatus möglicherweise auf die kleinere Systempartition. Der Speicherplatz wird nicht automatisch zwischen verschiedenen Mounts geteilt.
Kann das Löschen von Protokolldateien das Problem verschlimmern?
Ja. Ein laufender Prozess kann eine gelöschte Protokolldatei weiterhin geöffnet halten, sodass der Speicherplatz belegt bleibt, obwohl der Pfad nicht mehr vorhanden ist. Rotieren oder kürzen Sie Protokolle gemäß dem Verfahren des jeweiligen Dienstes.
Wie viel freier Speicherplatz sollte auf der Systempartition bleiben?
Es gibt keinen allgemein gültigen Prozentsatz. Halten Sie ausreichend Reserven für Updates, Protokolle, Datenbankwartung, das Wachstum von Containern und Wiederherstellungsvorgänge vor. Richten Sie dann Warnmeldungen sowohl für die Wachstumsrate als auch für den verbleibenden Speicherplatz ein.
Support und Tipps
Mehr zum Lesen

Was vor dem Laden eines Community-Modells in Transformers zu beachten ist
Nutze das Transformers-Jinja-Sandbox-Update, um die Herkunft des Modells, Chat-Vorlagen, Remote-Code, serialisierte Gewichte und isolierte erste Ausführungen zu überprüfen.

Mirage lokal ausführen: OCR und Objekterkennung aus einem einzigen Bild
Testen Sie das kleine lokale Vision-Modell von Cactus Compute, überprüfen Sie die OCR- und Objektextraktion anhand realer Eingaben und verstehen Sie die Grenzen in...

So planst du einen Coding-Agenten in Open WebUI auf einem Homeserver ein
Richte in Open WebUI eine Coding-Agent-Automatisierung im Nur-Bericht-Modus ein, wähle ihr Terminal und ihren Arbeitsbereich aus und überprüfe Berechtigungen, Protokolle und die Wiederherstellung nach...



