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, waarbij aankoppelpunten voor back-ups en externe opslag betrokken waren.
Docker meten voordat je opruimt
De eerste communityreactie stelde voor om de grootste mappen onder /DATA en de eigen administratie van Docker te controleren. Dat was redelijk, maar het resultaat van de gebruiker liet slechts ongeveer 2,1 GB onder de Docker-structuur en ongeveer 2 GB aan AppData zien.
Docker kon daarom geen verklaring zijn voor honderden ontbrekende gigabytes.
/DATA de partitie was bijna vol.De eerste gebruiker vond 424 GB onder /DATA/.media/UNTITLED 2
De groottecontrole toonde ongeveer 419 GB aan normale media, plus nog eens 424 GB onder /DATA/.media/UNTITLED 2. De gebruiker herkende die naam als de SSD die eerder als back-upbestemming van ZimaOS was gebruikt.
Het verwarrende was dat de fysieke back-upschijf niet langer was aangesloten.
Een aankoppelpunt kan een gewone lokale map worden
Linux-aankoppelpunten zijn mappen. Wanneer een USB-schijf of SMB-share wordt aangekoppeld, gaan toegangen tot die map naar het externe bestandssysteem. Als het externe bestandssysteem verdwijnt en een toepassing naar dezelfde map blijft schrijven, kunnen die schrijfbewerkingen op het onderliggende lokale bestandssysteem terechtkomen.
Hierdoor ontstaat het klassieke probleem: “mijn back-updoel is extern, dus waarom raakte de systeemschijf vol?”
Verwijder een .media-map niet voordat je weet of deze is aangekoppeld
Bij het oplossen van het probleem werd voorgesteld om, na controle van de aankoppelstatus, destructieve verwijdercommando's uit te voeren. Die volgorde is belangrijk. Bestanden verwijderen uit een actief aangekoppelde back-updoelmap kan de daadwerkelijke externe back-up wissen in plaats van lokale verborgen gegevens op te ruimen.
Omdat het verwijdercommando afkomstig was uit de community en niet uit een ondersteuningsinstructie van IceWhale, presenteert deze pagina het niet als een algemene opruimprocedure.
Een tweede gebruiker zag hetzelfde patroon na een stroomstoring
Later in de discussie verloor een andere gebruiker met een klein ZimaOS-HD-systeem/data-partitie alle resterende vrije ruimte nadat een stroomstoring de back-upactiviteit had onderbroken. Hun ruwe du de uitvoer leek enorm omdat ook aangekoppelde RAID- en SMB-gegevens eronder werden meegeteld /DATA/.media.
Gebruik een scan op hetzelfde bestandssysteem om lokale gegevens van mounts te onderscheiden
De community raadde een du scan die op hetzelfde bestandssysteem blijft, zodat aangekoppelde netwerkshares worden uitgesloten. In het tweede geval bracht dit ongeveer 30 GB aan daadwerkelijk lokale gegevens aan het licht onder een naar een IP-adres genoemde map in /DATA/.media.
De tweede gebruiker maakte 30 GB vrij
Nadat was bevestigd dat de map met de naam van het IP-adres geen actieve SMB-mount was en dat het om lokale gegevens ging die onder het mountpunt waren achtergebleven, verwijderde de gebruiker de ongewenste inhoud en meldde 30 GB te hebben vrijgemaakt.
Dat is de best bevestigde uitkomst in de thread.
De theorie van de community was dat de back-up werd geschreven terwijl de bestemming niet was aangekoppeld
De beantwoorder dacht dat het back-upproces bleef schrijven naar het verwachte SMB-pad toen de share niet correct was aangekoppeld, waardoor Linux in plaats daarvan naar de lokale map schreef.
Het bevestigde herstel van 30 GB ondersteunt dat er lokale bestanden onder het mountpunt stonden, maar de precieze back-uprace was een diagnose uit de community en geen technisch bericht van IceWhale in deze thread.
De huidige back-up- en opslagverwerking van ZimaOS is gewijzigd
De huidige documentatie van ZimaOS beschrijft beheerde back-uptaken en uitgebreider opslagbeheer. Gebruik de huidige ZimaOS-back-upwerkwijze voor nieuwe taken en controleer of de beoogde bestemming daadwerkelijk is aangekoppeld voordat grote schrijfbewerkingen beginnen.
Een veiligere werkwijze bij ontbrekende schijfruimte
- Gebruik
dfom te bevestigen welk lokaal bestandssysteem vol is. - Scan alleen dat bestandssysteem, zodat SMB-, USB- en RAID-mounts de totalen niet verhogen.
- Controleer Docker en AppData afzonderlijk.
- Inspecteren
/DATA/.mediavoor mountpuntmappen die echte lokale bestanden bevatten. - Bevestig dat de bestemming niet is aangekoppeld voordat je iets onder een mountpunt verwijdert.
- Controleer na het opschonen de vrije ruimte en test de back-upbestemming opnieuw.
De casus van 424 GB van de eerste gebruiker was onduidelijker dan de latere casus van 30 GB
De oorspronkelijke poster zag ongeveer 424 GB in een map met de naam van de losgekoppelde back-up-SSD en dacht dat dit overbodig was. Vervolgens ging de discussie over mountcontroles en voorgestelde opschoning, maar het duidelijkst geverifieerde herstel in de thread kwam van de latere gebruiker die 30 GB vrijmaakte.
Dat onderscheid is belangrijk, omdat een directory onder /DATA/.media kan staan voor een actieve koppeling, een verouderd mountpoint of echte lokale bestanden. Hetzelfde uitziende pad betekent niet dat op elk systeem dezelfde veilige opruimactie van toepassing is.
Gebruik df en du voor verschillende vragen
df beantwoordt de vraag: “Welk bestandssysteem is daadwerkelijk vol?” terwijl du beantwoordt de vraag: “Welke zichtbare directories bevatten bestanden?” Op een NAS met geneste koppelingen kunnen de twee hulpprogramma’s elkaar lijken tegen te spreken, omdat du kan andere bestandssystemen meenemen als dat niet wordt voorkomen.
De discussie werd pas veel duidelijker nadat het oplossen van het probleem het lokale ZimaOS-HD-bestandssysteem had gescheiden van gekoppelde SMB- en RAID-inhoud.
Onverwacht stroomverlies maakt problemen met mountpoints gevaarlijker
De latere casus van 30 GB begon na een stroomstoring terwijl back-ups actief waren. Als een externe bestemming na het opstarten niet correct opnieuw wordt gekoppeld, maar een back-uptaak wordt hervat of opnieuw gestart, kan het pad nog steeds als een gewone lokale directory bestaan.
Controleer voor belangrijke back-uptaken na een herstart of stroomstoring of de bestemming gekoppeld en schrijfbaar is, voordat je ervan uitgaat dat het oude pad nog steeds naar de externe bestemming verwijst.
Verwijder Docker overlay2 niet handmatig om ruimte vrij te maken
Aan het begin van de discussie vielen de Docker-overlaypaden visueel op in de uitvoer van het bestandssysteem. De community waarschuwde specifiek tegen het verwijderen van willekeurige bestanden uit overlay2. De opslaglaag van Docker moet via Docker of de levenscyclus van de toepassing worden beheerd, niet door willekeurige laagmappen te verwijderen.
Het huidige ZimaOS toont ook het app-opslaggebruik
De huidige ZimaOS-appinstellingen tonen het opslagverbruik van toepassingen en bieden voor ondersteunde apps de mogelijkheid om de cache op te schonen. Dat is nuttig om normale groei van toepassingen te onderscheiden van gegevens op mountpoints voordat je de terminal opent.
De uitleg van waar huidige ZimaOS-toepassingen gegevens en cache opslaan biedt een veiliger eerste overzicht van het bestandssysteem.
Veelgestelde vragen over ontbrekende ruimte
Was Docker overlay2 verantwoordelijk voor de honderden ontbrekende gigabytes van de eerste gebruiker?
Nee. Docker was in de geposte uitvoer slechts verantwoordelijk voor een klein deel van de gebruikte ruimte.
Waarom kan du terabytes rapporteren op een veel kleinere lokale schijf?
Het kan gekoppelde externe of RAID-bestandssystemen recursief meetellen, tenzij de scan wordt beperkt tot het lokale bestandssysteem.
Is er enig herstel bevestigd?
Ja. De latere gebruiker herstelde 30 GB aan lokale gegevens die waren opgeslagen onder een SMB-mountpointdirectory.
