ZimaOS Docker startar inte: inget utrymme efter migrering

När Docker vägrar starta efter en datamigrering i ZimaOS kan den sista raden i loggen vara missvisande. I det här källfallet från februari 2026 rapporterade Docker till slut att lagringsdrivrutinen overlay2 inte stöddes. Om man läser några rader tidigare framgår det verkliga felet: Docker kunde inte skapa temporära filer eller testa overlay-lagring eftersom systemdisken hade slut på utrymme.

Användaren hade en ZimaOS-SSD på 180 GB och hade av misstag låtit en växande Immich-databas ligga kvar på den. När de försökte migrera fanns det inte tillräckligt med ledigt utrymme för en felfri flytt. Efter flera försök och manuell radering av loggar verkade AppData ha migrerats, men systemdisken nådde fortfarande 100 %, och Docker kunde inte längre initieras efter omstart.

Immich fyllde den lilla system-SSD:n före migreringen

Användaren installerade Immich utan att flytta databasen från systemdisken. När fotosamlingen växte fylldes disken och ZimaOS började rapportera fel.

Detta stämmer överens med IceWhales aktuella vägledning: programdata bör placeras på det huvudsakliga lagringsutrymmet i stället för på en liten systemdisk, eftersom fotobibliotek, mediemetadata, dokumentindex, databaser och cachefiler kan växa snabbt.

Själva migreringen behövde arbetsutrymme

Användaren försökte använda ZimaOS migreringsflöde först när systemdisken redan var kritiskt full. De uppgav att de första migreringsförsöken misslyckades eftersom det inte fanns tillräckligt med ledigt utrymme för att buffra åtgärden.

Det här är en viktig lärdom i driften: flytta AppData innan systemdisken når de sista få gigabyte, inte efter att Docker och migreringstjänster redan har ont om arbetsutrymme.

Meddelandet om Docker-socketen var bara ett symtom

Program rapporterade:

Det går inte att ansluta till Docker-daemonen på unix:///var/run/docker.sock.
Kör Docker-daemonen?

Det meddelandet betyder att Docker-daemonen inte är tillgänglig. Det identifierar inte varför daemonen slutade fungera.

Journalen avslöjade den verkliga grundorsaken

De viktiga raderna var:

det finns inget utrymme kvar på enheten
Det gick inte att säkerställa att standardprofilen för AppArmor var inläst
mkdir /var/lib/docker/overlay2/check-overlayfs-support...: no space left on device
misslyckades med att starta demonen: fel vid initiering av graphdriver

Docker misslyckades först eftersom det inte kunde skriva tillfälliga data. Det senare drivrutin stöds inte meddelandet var en följd av den misslyckade initieringen av lagringsdrivrutinen, inte ett tecken på att den körande kärnan plötsligt hade förlorat stöd för overlay2 efter migreringen.

Varför en omstart av Docker inte löste problemet

Användaren försökte starta om docker.service och docker.socket manuellt och fick meddelandet Åtkomst nekad. Ett svar från communityn kopplade detta till ZimaOS tjänstekontroller i appliance-stil.

Även om tjänsten hade fått startas om skulle det inte ha skapat något ledigt diskutrymme. Demonen skulle helt enkelt stöta på samma skrivfel igen.

Att ta bort tillfälliga Docker-filer frigjorde inte tillräckligt med utrymme

Communityn föreslog att tillfälliga Docker-filer skulle rensas efter att diskutrymmet först kontrollerats. Den ursprungliga användaren försökte detta och svarade att systemdisken fortfarande var 100 % full och att Docker fortfarande inte startade.

Detta negativa resultat är användbart: en liten tillfällig rensning kan inte åtgärda en lagringsdesign där systemdisken fortfarande är helt full.

Källanvändaren valde säkerhetskopiering och fabriksåterställning

Efter att rensningsförsöket misslyckats beslutade användaren att säkerhetskopiera /DATA/AppData och installerade om/återställde ZimaOS. Community-svararen rekommenderade att notera installerade appar, använda fabriksåterställning av systemet och sedan migrera programrelaterad lagring till den stora disken innan apparna installerades om.

Den offentliga tråden slutar efter att användaren sagt att de skulle göra det. Den innehåller ingen bekräftelse efter återställningen, så sidan bör inte beskriva ominstallationen som en verifierad slutgiltig lösning för just den här användaren.

Den nuvarande datamigreringen i ZimaOS är tydligare med vad som kan flyttas

I nuvarande ZimaOS finns separata migreringskategorier för:

Docker-avbildningar;
Docker-applikationsdata;
användardatabaser som Galleri, Nedladdningar, Dokument, Media och Säkerhetskopiering.

Detta är en viktig uppdatering av den äldre tråden, där diskussionen ibland behandlade ”AppData-migrering” som om den automatiskt omfattade all Docker-lagring.

Använd de aktuella kategorierna för datamigrering i ZimaOS innan en liten systemdisk blir kritiskt full.

Förebygg problemet genom att ange platsen för appdata tidigt

Nuvarande ZimaOS visar också en plats för appdata under Settings > Apps. IceWhale rekommenderar att du från början anger lagringsarrayen som plats i stället för att låta all beständig tillväxt av appdata ske på systemenheten.

Den aktuella förklaringen av var ZimaOS-appar lagrar beständiga data är den bästa förebyggande referensen.

Kontrollera både kapacitet och inoder

Ett filsystem kan neka nya filer eftersom det saknar lediga block eller har slut på inoder. Felsökningen av källsystemet föreslog att kontrollera båda. Loggen i det här fallet pekar starkt på normal kapacitetsbrist, men det är ändå användbart att kontrollera båda värdena som en skrivskyddad diagnostik.

När en ominstallation blir rimlig

Om systemdisken har varit 100 % full, Dockers lagringsmetadata är skadad, daemonen inte kan starta och en säker rensning inte kan skapa tillräckligt med arbetsutrymme, kan en kontrollerad systemåterställning vara snabbare och säkrare än att manuellt redigera Dockers overlay-metadata.

Skydda AppData och användardata först, ta reda på vilka diskar återställningen kommer att påverka och undvik att radera den enda kopian av programmens databaser.

Vanliga frågor om Docker efter migrering

Var overlay2 faktiskt inte kompatibelt med maskinvaran i källsystemet?

Loggarna visar först att Docker inte kunde skapa testfiler för overlay2 eftersom disken var full. Drivrutinsmeddelandet kom efter det felet.

Löste det problemet på källsystemet att rensa Docker tmp?

Nej. Den ursprungliga skribenten sa att systemdisken fortfarande var 100 % full.

Låter nuvarande ZimaOS dig flytta Docker-avbildningar separat från AppData?

Ja. I den aktuella datamigreringen listas Docker-avbildningar och Docker-programdata som separata flyttbara kategorier.

Bekräftades det i tråden att fabriksåterställningen lyckades?

Nej. Användaren sa att de skulle genomföra det, men den offentliga tråden slutar innan resultatet efter återställningen.