Disk-usage tools can be misleading on a NAS because a directory may be either ordinary local storage or the place where another filesystem is mounted. This January 2026 thread began with a 1 TB ZimaOS drive showing roughly 915 GB used even though the user believed only about 450 GB of media existed. The first assumption was Docker cache. The command output instead pointed toward /DATA/.media, bei dem Sicherungs- und Remote-Speicher-Einhängepunkte beteiligt waren. Dienstprogramme zur Speicherplatzanalyse können auf einem NAS irreführend sein, da ein Verzeichnis entweder gewöhnlicher lokaler Speicher oder der Ort sein kann, an dem ein anderes Dateisystem eingehängt ist. Dieser Thread vom Januar 2026 begann mit einem 1-TB-ZimaOS-Laufwerk, das eine Belegung von etwa 915 GB anzeigte, obwohl der Nutzer glaubte, nur etwa 450 GB Mediendaten zu haben. Die erste Vermutung war ein Docker-Cache. Die Befehlsausgabe wies stattdessen auf
Docker vor dem Bereinigen messen
Die erste Antwort aus der Community schlug vor, die größten Ordner unter /DATA und die eigene Speicheraufstellung von Docker überprüfte. Das war nachvollziehbar, doch das Ergebnis des Nutzers zeigte nur etwa 2,1 GB im Docker-Verzeichnis und etwa 2 GB an AppData.
Docker konnte daher nicht Hunderte fehlende Gigabyte erklären.
/DATA Die Partition war fast voll.Der erste Nutzer fand 424 GB unter /DATA/.media/UNTITLED 2
Die Größenanalyse zeigte ungefähr 419 GB gewöhnliche Mediendaten sowie weitere 424 GB unter /DATA/.media/UNTITLED 2. Der Nutzer erkannte diesen Namen als die SSD, die zuvor als ZimaOS-Sicherungsziel verwendet worden war.
Verwirrend war, dass das physische Sicherungslaufwerk nicht mehr angeschlossen war.
Ein Einhängepunkt kann zu einem gewöhnlichen lokalen Ordner werden
Linux-Einhängepunkte sind Verzeichnisse. Wenn ein USB-Laufwerk oder eine SMB-Freigabe eingehängt wird, greifen Zugriffe auf das Verzeichnis auf das externe Dateisystem zu. Verschwindet das externe Dateisystem und schreibt eine Anwendung weiterhin in dasselbe Verzeichnis, können diese Schreibvorgänge im darunterliegenden lokalen Dateisystem landen.
Dadurch entsteht das klassische Fehlerbild: „Mein Sicherungsziel ist extern – warum ist dann die Systemfestplatte voll?“
Löschen Sie kein .media-Verzeichnis, bevor Sie wissen, ob es eingehängt ist
Die ursprüngliche Fehlerbehebung schlug nach der Prüfung des Einhängezustands destruktive Löschbefehle vor. Diese Reihenfolge ist wichtig. Das Löschen von Dateien auf einem aktiv eingehängten Sicherungsziel kann die tatsächliche externe Sicherung löschen, statt lokal verborgene Daten freizugeben.
Da der Löschbefehl eher eine Empfehlung aus der Community als eine Supportanweisung von IceWhale war, wird er auf dieser Seite nicht als allgemeine Bereinigungsanleitung dargestellt.
Ein zweiter Nutzer reproduzierte dasselbe Muster nach einem Stromausfall
Später im Thread verlor ein anderer Nutzer mit einer kleinen ZimaOS-HD-System-/Datenpartition nach einem Stromausfall, der laufende Sicherungsaktivitäten unterbrach, den gesamten verbleibenden freien Speicherplatz. Seine Rohdaten du Die Ausgabe wirkte enorm, weil auch eingehängte RAID- und SMB-Daten darunter mitgezählt wurden. /DATA/.media.
Verwenden Sie einen Scan auf demselben Dateisystem, um lokale Daten von Mounts zu trennen
Die Community empfahl einen du einen Scan, der auf demselben Dateisystem bleibt, damit eingebundene Netzwerkfreigaben ausgeschlossen werden. Im zweiten Fall wurden dadurch etwa 30 GB tatsächlich lokaler Daten unter einem nach einer IP benannten Verzeichnis innerhalb von /DATA/.media.
Der zweite Benutzer gewann 30 GB zurück
Nachdem bestätigt worden war, dass das nach der IP benannte Verzeichnis kein aktiver SMB-Mount war, und festgestellt wurde, dass es sich um lokale Daten handelte, die unter dem Einhängepunkt zurückgeblieben waren, entfernte der Benutzer die unerwünschten Inhalte und meldete die Wiederherstellung von 30 GB.
Das ist das am stärksten bestätigte Ergebnis im Thread.
Die Theorie der Community war, dass das Backup geschrieben wurde, während das Ziel nicht eingebunden war
Der Antwortende ging davon aus, dass der Backup-Prozess weiterhin in den erwarteten SMB-Pfad schrieb, obwohl die Freigabe nicht korrekt eingebunden war, sodass Linux stattdessen in das lokale Verzeichnis schrieb.
Die bestätigte Wiederherstellung von 30 GB stützt die Annahme, dass sich lokale Dateien unterhalb des Einhängepunkts befanden. Der genaue Backup-Konflikt war in diesem Thread jedoch eine Diagnose der Community und kein Beitrag der IceWhale-Entwickler.
Die Handhabung von Backups und Speicher in aktuellem ZimaOS hat sich geändert
Die aktuelle ZimaOS-Dokumentation behandelt verwaltete Backup-Aufgaben und die allgemeine Speicherverwaltung. Verwenden Sie für neue Aufträge den aktuellen ZimaOS-Backup-Workflow und überprüfen Sie, ob das vorgesehene Ziel tatsächlich eingebunden ist, bevor große Schreibvorgänge beginnen.
Ein sichererer Workflow zur Suche nach fehlendem Speicherplatz
- Verwenden Sie
dfum zu bestätigen, welches lokale Dateisystem voll ist. - Scannen Sie nur dieses Dateisystem, damit SMB-, USB- und RAID-Einhängungen die Summen nicht verfälschen.
- Überprüfen Sie Docker und AppData separat.
- Untersuchen
/DATA/.mediafür Einhängepunktverzeichnisse, die echte lokale Dateien enthalten. - Bestätigen Sie vor dem Löschen von Daten unterhalb eines Einhängepunkts, dass das Ziel nicht eingebunden ist.
- Überprüfen Sie nach der Bereinigung den freien Speicherplatz und testen Sie das Backup-Ziel erneut.
Der Fall des ersten Benutzers mit 424 GB war weniger eindeutig als der spätere Fall mit 30 GB
Der ursprüngliche Verfasser sah unter einem Verzeichnis mit dem Namen der getrennten Backup-SSD ungefähr 424 GB und hielt diese für redundant. Anschließend ging die Diskussion über Mount-Prüfungen und vorgeschlagene Bereinigungen weiter, doch die eindeutigste bestätigte Wiederherstellung kam vom späteren Benutzer, der 30 GB zurückgewann.
Diese Unterscheidung ist wichtig, weil ein Verzeichnis unter /DATA/.media kann einen aktiven Einhängepunkt, einen veralteten Einhängepunkt oder echte lokale Dateien darstellen. Derselbe aussehende Pfad bedeutet nicht, dass auf jedem System dieselbe sichere Bereinigungsmaßnahme gilt.
Verwenden Sie df und du für unterschiedliche Fragen
df beantwortet die Frage „Welches Dateisystem ist tatsächlich voll?“ während du beantwortet die Frage „Welche sichtbaren Verzeichnisse enthalten Dateien?“ Auf einem NAS mit verschachtelten Einhängungen können die beiden Werkzeuge scheinbar widersprüchliche Ergebnisse liefern, weil du kann andere Dateisysteme durchlaufen, wenn dies nicht verhindert wird.
Der Thread wurde erst deutlich verständlicher, nachdem bei der Fehlersuche das lokale ZimaOS-HD-Dateisystem von eingehängten SMB- und RAID-Inhalten getrennt betrachtet wurde.
Unerwartete Stromausfälle machen Fehler bei Einhängepunkten gefährlicher
Der spätere Fall mit 30 GB begann nach einem Stromausfall, während Sicherungen aktiv waren. Wenn ein entferntes Ziel nach dem Start nicht ordnungsgemäß erneut eingehängt wird, ein Sicherungsauftrag jedoch fortgesetzt oder neu gestartet wird, kann der Pfad weiterhin als gewöhnliches lokales Verzeichnis vorhanden sein.
Bei wichtigen Sicherungsaufträgen sollten Sie nach einem Neustart oder Stromausfall überprüfen, dass das Ziel eingehängt und beschreibbar ist, bevor Sie annehmen, dass der alte Pfad weiterhin auf das externe Ziel verweist.
Docker-overlay2 nicht manuell löschen, um Speicherplatz freizugeben
Zu Beginn des Threads wirkten die Docker-Overlay-Pfade in der Dateisystemausgabe optisch auffällig. Die Community warnte ausdrücklich davor, beliebige Dateien aus overlay2. Dockers Speicherschicht sollte über Docker oder den Lebenszyklus der Anwendung verwaltet werden, nicht durch das Entfernen beliebiger Layer-Verzeichnisse.
Aktuelle ZimaOS-Versionen zeigen auch die Speichernutzung von Apps an
Die aktuellen ZimaOS-App-Einstellungen zeigen den Speicherverbrauch von Anwendungen und ermöglichen bei unterstützten Apps die Bereinigung des Caches. Das ist hilfreich, um normales Wachstum von Anwendungen von Daten an Einhängepunkten zu unterscheiden, bevor man zum Terminal wechselt.
Die Erklärung dazu, wo aktuelle ZimaOS-Anwendungen Daten und den Cache speichern, bietet eine sicherere erste Übersicht über das Dateisystem.
FAQ zu fehlendem Speicherplatz
War Dockers overlay2 für die Hunderte fehlender Gigabytes des ersten Nutzers verantwortlich?
Nein. Docker machte in der veröffentlichten Ausgabe nur einen kleinen Teil des belegten Speicherplatzes aus.
Warum kann du Terabytes auf einer viel kleineren lokalen Festplatte melden?
Es kann eingehängte Remote- oder RAID-Dateisysteme rekursiv mitzählen, sofern die Suche nicht auf das lokale Dateisystem beschränkt wird.
Wurde eine Wiederherstellung bestätigt?
Ja. Der spätere Nutzer stellte 30 GB aus lokal unterhalb eines SMB-Einhängepunktverzeichnisses gespeicherten Daten wieder her.
