Wanneer Docker na een ZimaOS-gegevensmigratie weigert te starten, kan de laatste regel in het log misleidend zijn. In deze broncasus uit februari 2026 meldde Docker uiteindelijk dat de opslagdriver overlay2 niet werd ondersteund. Enkele regels eerder staat de werkelijke fout: Docker kon geen tijdelijke bestanden maken of overlay-opslag testen omdat er geen ruimte meer op het apparaat was.
De gebruiker had een ZimaOS-SSD van 180 GB en had per ongeluk een groeiende Immich-database daarop laten staan. Tegen de tijd dat de gebruiker de migratie probeerde, was er niet genoeg vrije ruimte voor een probleemloze verplaatsing. Na meerdere pogingen en het handmatig verwijderen van logboeken leek AppData te zijn gemigreerd, maar de systeemschijf bereikte nog steeds 100% en Docker kon na het opnieuw opstarten niet meer worden geïnitialiseerd.
Immich vulde de kleine systeem-SSD voordat de migratie plaatsvond
De brongebruiker installeerde Immich zonder de database van de systeemschijf te verplaatsen. Naarmate de fotostack groeide, raakte de schijf vol en begon ZimaOS fouten te melden.
Dit komt overeen met de huidige richtlijnen van IceWhale: applicatiegegevens moeten op de hoofdopslagruimte worden geplaatst in plaats van op een kleine systeemschijf, omdat fotobibliotheken, mediametagegevens, documentindexen, databases en caches snel kunnen groeien.
De migratie zelf had werkruimte nodig
De gebruiker probeerde de ZimaOS-migratieworkflow pas nadat de systeemschijf al kritiek vol was. De gebruiker gaf aan dat de eerste migratiepogingen mislukten omdat er onvoldoende vrije ruimte was om de bewerking te bufferen.
Dit is een belangrijke operationele les: verplaats AppData voordat er nog maar enkele gigabytes op de systeemschijf vrij zijn, niet pas nadat Docker en migratieservices al geen werkruimte meer hebben.
De melding over de Docker-socket was slechts een symptoom
De applicaties meldden:
Kan geen verbinding maken met de Docker-daemon via unix:///var/run/docker.sock.
Draait de Docker-daemon?Die melding betekent dat de Docker-daemon niet beschikbaar is. Ze geeft niet aan waarom de daemon is uitgevallen.
Het journaal onthulde de werkelijke oorzaak
De belangrijkste regels waren:
geen ruimte meer op het apparaat
Kan het standaard-AppArmor-profiel niet laden
mkdir /var/lib/docker/overlay2/check-overlayfs-support...: geen ruimte meer op het apparaat
daemon kon niet starten: fout bij het initialiseren van graphdriverDocker faalde aanvankelijk omdat het geen tijdelijke gegevens kon schrijven. De latere driver wordt niet ondersteund melding was een gevolg van de mislukte initialisatie van de opslagdriver, niet het bewijs dat de actieve kernel na de migratie plotseling de ondersteuning voor overlay2 was kwijtgeraakt.
Waarom het opnieuw starten van Docker dit niet oploste
De gebruiker probeerde opnieuw te starten docker.service en docker.socket handmatig opnieuw te starten en kreeg ‘Toegang geweigerd’. Een communityreactie bracht dat in verband met de appliance-achtige servicebesturing van ZimaOS.
Zelfs als het opnieuw starten van de service was toegestaan, zou dit geen vrije schijfruimte opleveren. De daemon zou opnieuw tegen dezelfde schrijffout aanlopen.
Tijdelijke Docker-bestanden verwijderen maakte niet genoeg ruimte vrij
De community stelde voor om eerst de schijfruimte te controleren en daarna tijdelijke Docker-bestanden te wissen. De oorspronkelijke gebruiker probeerde dat en antwoordde dat de systeemschijf nog steeds 100% vol was en Docker nog altijd niet wilde starten.
Dit negatieve resultaat is nuttig: een kleine tijdelijke opruiming kan een opslagontwerp waarbij de systeemschijf volledig verzadigd blijft, niet herstellen.
De brongebruiker koos voor een back-up en fabrieksherstel
Na de mislukte opruimpoging besloot de gebruiker een back-up te maken van /DATA/AppData en ZimaOS opnieuw te installeren/terug te zetten. De communityreactie adviseerde om de geïnstalleerde apps te noteren, Factory System Restore te gebruiken en vervolgens appgerelateerde opslag naar de grote schijf te migreren voordat de apps opnieuw werden geïnstalleerd.
De openbare thread eindigt nadat de gebruiker zei dat hij dat zou doen. Er staat geen bevestiging na het terugzetten in, dus de pagina mag het opnieuw installeren niet bestempelen als een geverifieerde definitieve oplossing voor deze specifieke gebruiker.
De gegevensmigratie in de huidige versie van ZimaOS maakt explicieter wat kan worden verplaatst
De huidige versie van ZimaOS biedt afzonderlijke migratiecategorieën voor:
- Docker-images;
- Docker-toepassingsgegevens;
- gebruikersdatabases zoals Galerij, Downloads, Documenten, Media en Back-up.
Dit is een belangrijke aanvulling op de oudere thread, waarin de discussie soms deed alsof ‘AppData-migratie’ automatisch alle Docker-opslag omvatte.
Gebruik de huidige categorieën voor gegevensmigratie in ZimaOS voordat een kleine systeemschijf kritiek vol raakt.
Voorkom het probleem door de locatie voor toepassingsgegevens vroeg in te stellen
De huidige ZimaOS toont ook een locatie voor toepassingsgegevens onder Instellingen > Apps. IceWhale raadt aan deze vanaf het begin naar de opslagarray te laten wijzen, in plaats van alle persistente groei van apps op het systeemapparaat te laten plaatsvinden.
De huidige uitleg over waar ZimaOS-apps persistente gegevens opslaan is de beste preventieve referentie.
Controleer zowel capaciteit als inodes
Een bestandssysteem kan nieuwe bestanden weigeren omdat er geen vrije blokken meer zijn of omdat alle inodes zijn opgebruikt. Bij het oplossen van het probleem op het bronsysteem werd aangeraden beide te controleren. De log wijst in dit geval sterk op normaal capaciteitsgebrek, maar beide waarden controleren blijft een nuttige diagnose zonder schrijfbewerkingen.
Wanneer opnieuw installeren redelijk wordt
Als de systeemschijf voor 100% vol is geweest, Docker-opslagmetagegevens beschadigd zijn, de daemon niet kan starten en veilig opschonen niet genoeg werkruimte kan vrijmaken, kan een gecontroleerd systeemherstel sneller en veiliger zijn dan handmatig de overlaymetagegevens van Docker bewerken.
Bescherm AppData en gebruikersgegevens eerst, zorg dat je begrijpt welke schijven door het herstel worden geraakt en verwijder niet de enige kopie van toepassingsdatabases.
Veelgestelde vragen over Docker na migratie
Werd overlay2 op de bronhardware daadwerkelijk niet ondersteund?
In de logs staat eerst dat Docker geen overlay2-testbestanden kon maken omdat de schijf vol was. De driverfoutmelding volgde op die mislukking.
Heeft het wissen van Docker tmp het bronsysteem hersteld?
Nee. De oorspronkelijke poster zei dat de OS-schijf voor 100% vol bleef.
Kun je met de huidige ZimaOS Docker-images afzonderlijk van AppData verplaatsen?
Ja. In de huidige functie voor gegevensmigratie worden Docker-images en Docker-toepassingsgegevens als afzonderlijke verplaatsbare categorieën vermeld.
Werd in de thread bevestigd dat het herstellen naar de fabrieksinstellingen was geslaagd?
Nee. De gebruiker zei dat hij ermee door zou gaan, maar de openbare thread eindigt voordat er een resultaat na het herstellen wordt gemeld.
