“Built-in storage almost full” is a symptom, not a single ZimaOS bug. This source thread exposed at least three different causes: a Backup task whose USB destination disappeared and was effectively recreated under local /DATA, een ongeremd Docker-JSON-logboek dat tot 519 GB groeide, en een ander systeem waarop “Ingebouwde opslag bijna vol” een symptoom is en geen afzonderlijke ZimaOS-bug. Deze brondiscussie bracht minstens drie verschillende oorzaken aan het licht: een back-uptaak waarvan de USB-bestemming verdween en feitelijk opnieuw werd aangemaakt onder lokale /DATA/.media 409 GB in beslag nam.
De veiligste aanpak is eerst meten, de verantwoordelijke service identificeren, de schrijfactie stoppen en vervolgens alleen de bevestigde gegevens opruimen. Verwijder niet recursief /DATA/.docker, .media of AppData alleen omdat ze groot zijn.
/DATA hoewel de grote gegevenspool nog meerdere terabytes beschikbaar had.Het migreren van appgegevens garandeert niet dat elke toekomstige schrijfactie /DATA verlaat
Gebruik alleen-lezencontroles met du om de grootste map te vinden
De gebruiker van de bron deelde:
sudo du -x -h --max-depth=1 /DATA 2>/dev/null | sort -hrDit wijzigt geen bestanden. Voer de opdracht opnieuw uit voor een verdachte map om de grootste submap te vinden.
Een losgekoppelde back-upbestemming was de eerste bevestigde oorzaak
Cobblerkid ontdekte dat een back-uptaak een externe USB-schijf verwachtte. Nadat de schijf was losgekoppeld, werd de back-upstructuur opnieuw aangemaakt onder /DATA en de geplande taak bleef schrijven totdat de lokale opslag vol was.
Zima-Jerry bevestigde dat dit een probleem leek en stuurde het intern door. Het gaat dus om meer dan alleen een theorie uit de community.
Een andere gebruiker vond een JSON-logboek van 519 GB voor een container
Een tweede deelnemer inspecteerde de map van één Docker-container en vond een *-json.log een bestand van ongeveer 519 GB, dat aan een Home Assistant-container werd toegeschreven.
De gebruiker verwijderde de container en maakte ruimte vrij. Trek daar niet de algemene conclusie uit dat je Docker-logboeken handmatig moet verwijderen; identificeer eerst de container die de vele logregels veroorzaakt, inspecteer de logboeken en verhelp de terugkerende fout die het logboek blijft vullen.
Een derde systeem had 409 GB onder /DATA/.media
Een andere gebruiker plaatste een overzicht van de opslaggrootte waarin normale AppData ongeveer 225 GB in beslag nam, .docker slechts 3,5 GB, maar .media 409 GB in beslag nam. Dit laat zien waarom één opschoonopdracht niet elk rapport over een “volle schijf” kan oplossen.
De huidige ZimaOS-versie biedt meer controle over appopslag en cache
Volgens de huidige IceWhale-documentatie toont Instellingen → Apps de locatie van AppData en opties voor gebruik per app en het opschonen van cache. Door AppData op de hoofdopslagarray te bewaren, wordt de druk op de kleine systeemschijf verminderd.
Gebruik de huidige opslagopties voor ZimaOS-apps voordat je shell-opruiming uitvoert.
Een veiligere herstelvolgorde
- stop de taak/app die nog steeds gegevens genereert;
- meten
/DATAalleen-lezen; - identificeer het exacte bestand/de exacte map en de eigenaar;
- maak een back-up van belangrijke AppData/configuratie;
- gebruik waar mogelijk ondersteunde app-/cacheopties;
- verwijder alleen wegwerpbare of aantoonbaar foutieve gegevens;
- controleer of de vrije ruimte na het opnieuw opstarten stabiel blijft.
docker image prune lost niet elk Docker-opslagprobleem op
In de bron vermeldde raller1028 docker image prune -a als manier om images te verwijderen die niet door containers worden gebruikt. Dat kan ongebruikte imagelagen terugwinnen, maar lost geen actief container-JSON-logboek van 519 GB, een op hol geslagen back-updoel of gebruikersgegevens onder .media.
Gebruik de groottecontrole om eerst de categorie te identificeren. Een opruimcommando voor de verkeerde categorie kan vrijwel niets vrijmaken en tegelijkertijd nieuwe risico's veroorzaken.
Een enorm JSON-logboek betekent dat de foutenlus van de container nog steeds relevant is
Het verwijderen van de problematische container maakte voor één gebruiker ruimte vrij, maar de betere langetermijnvraag is waarom de applicatie honderden gigabytes aan logboeken schreef. Controleer recente logboeken op herhaalde fouten, herstartlussen, niet-beschikbare apparaten of configuratieproblemen voordat je dezelfde workload opnieuw installeert.
Als de opnieuw aangemaakte container direct weer logboeken begint te genereren, keert de schijfvolsituatie terug.
Behandel .media als beheerde opslag, niet als wegwerpbare cache
De 409 GB /DATA/.media het voorbeeld kan echte beheerde mount-/bestandsgegevens bevatten in plaats van tijdelijke cache. Identificeer voordat je daar iets verwijdert welke opslag/share/app de gegevens beheert en bevestig dat dezelfde bestanden elders bestaan.
Veelgestelde vragen over volle ingebouwde opslag
Bewees de bron dat de migratie van AppData zelf was mislukt?
Nee. De oorspronkelijke poster had de beheerde categorieën gemigreerd; de bevestigde vulling was afkomstig van een losgekoppeld back-updoel.
Is het veilig om de volledige map .docker te verwijderen?
Nee. Deze kan de actieve containerstatus, logboeken, images en applicatieafhankelijkheden bevatten.
Wat is volgens de bron het beste eerste commando?
Een alleen-lezen du groottecontrole van /DATA om de daadwerkelijke grote submap te identificeren.
