Quando Docker si rifiuta di avviarsi dopo una migrazione dei dati di ZimaOS, l'ultima riga del log può essere fuorviante. In questo caso reale del febbraio 2026, Docker ha infine segnalato che il driver di archiviazione overlay2 non era supportato. Leggendo alcune righe precedenti si scopre il vero errore: Docker non riusciva a creare file temporanei né a verificare lo storage overlay perché sul disco di sistema non c'era più spazio disponibile.
L'utente aveva un SSD ZimaOS da 180 GB e aveva lasciato accidentalmente su di esso un database Immich in continua crescita. Quando ha tentato la migrazione, non c'era abbastanza spazio libero per completare lo spostamento correttamente. Dopo diversi tentativi e la cancellazione manuale dei log, AppData sembrava essere stato migrato, ma il disco di sistema ha comunque raggiunto il 100% e Docker non è più riuscito a inizializzarsi dopo il riavvio.
Immich ha riempito il piccolo SSD di sistema prima della migrazione
L'utente di origine aveva installato Immich senza spostare il relativo database dal disco di sistema. Con la crescita dell'archivio fotografico, il disco si è riempito e ZimaOS ha iniziato a segnalare errori.
Questo è in linea con le attuali indicazioni di IceWhale: i dati delle applicazioni dovrebbero essere collocati nello spazio di archiviazione principale anziché su un piccolo disco di sistema, perché le librerie fotografiche, i metadati multimediali, gli indici dei documenti, i database e le cache possono crescere rapidamente.
La migrazione stessa aveva bisogno di spazio di lavoro
L'utente ha provato il flusso di migrazione di ZimaOS solo dopo che il disco di sistema era già pieno in modo critico. Ha detto che i primi tentativi di migrazione erano falliti perché non c'era spazio libero sufficiente per eseguire il buffering dell'operazione.
Questa è un'importante lezione operativa: sposta AppData prima che il disco di sistema raggiunga gli ultimi gigabyte disponibili, non dopo che Docker e i servizi di migrazione sono già rimasti senza spazio di lavoro.
Il messaggio del socket Docker era solo un sintomo
Le applicazioni hanno segnalato:
Impossibile connettersi al demone Docker all'indirizzo unix:///var/run/docker.sock.
Il demone Docker è in esecuzione?Quel messaggio significa che il demone Docker non è disponibile. Non identifica il motivo per cui il demone non è riuscito ad avviarsi.
Il journal ha rivelato la vera causa principale
Le righe importanti erano:
spazio esaurito sul dispositivo
Impossibile garantire il caricamento del profilo AppArmor predefinito
mkdir /var/lib/docker/overlay2/check-overlayfs-support...: no space left on device
failed to start daemon: error initializing graphdriverDocker ha inizialmente avuto un errore perché non riusciva a scrivere i dati temporanei. In seguito è comparso il messaggio driver non supportato il messaggio era una conseguenza dell'inizializzazione non riuscita del driver di archiviazione, non la prova che il kernel in esecuzione avesse improvvisamente perso il supporto per overlay2 dopo la migrazione.
Perché il riavvio di Docker non ha risolto il problema
L'utente ha provato a riavviare docker.service e docker.socket manualmente e ha ricevuto il messaggio Accesso negato. Una risposta della community ha collegato il problema ai controlli dei servizi in stile appliance di ZimaOS.
Anche se fosse stato possibile riavviare il servizio, non avrebbe creato spazio libero sul disco. Il demone avrebbe semplicemente incontrato di nuovo lo stesso errore di scrittura.
L'eliminazione dei file temporanei di Docker non ha recuperato spazio sufficiente
La community ha suggerito di cancellare i file Docker temporanei dopo aver controllato lo spazio su disco. L'utente originale ci ha provato e ha risposto che l'unità di sistema era ancora piena al 100% e che Docker continuava a non avviarsi.
Questo risultato negativo è utile: una piccola pulizia dei file temporanei non può risolvere una configurazione di archiviazione in cui il disco di sistema rimane completamente saturo.
L'utente ha scelto il backup e il ripristino delle impostazioni di fabbrica
Dopo che il tentativo di pulizia non è riuscito, l'utente ha deciso di eseguire il backup /DATA/AppData e reinstallare/ripristinare ZimaOS. Il membro della community ha consigliato di annotare le applicazioni installate, usare il ripristino del sistema alle impostazioni di fabbrica, quindi migrare lo spazio di archiviazione relativo alle applicazioni sul disco più capiente prima di reinstallare le applicazioni.
La discussione pubblica termina dopo che l'utente ha detto che lo avrebbe fatto. Non contiene una conferma successiva al ripristino, quindi la pagina non dovrebbe indicare la reinstallazione come soluzione finale verificata per questo specifico utente.
La migrazione dei dati nella versione attuale di ZimaOS indica più chiaramente cosa può essere trasferito
La versione attuale di ZimaOS offre categorie di migrazione separate per:
- Immagini Docker;
- Dati delle applicazioni Docker;
- database utente come Galleria, Download, Documenti, Media e Backup.
Questo è un aggiornamento importante della discussione precedente, in cui talvolta si considerava la “migrazione di AppData” come se coprisse automaticamente tutto lo spazio di archiviazione Docker.
Usa le categorie Migrazione dati dell'attuale ZimaOS prima che un disco di sistema di piccole dimensioni diventi pieno in modo critico.
Previeni il problema impostando subito la posizione dei dati delle app
L'attuale ZimaOS espone anche una posizione per i dati delle app in Impostazioni > App. IceWhale consiglia di indirizzarla all'array di archiviazione fin dall'inizio, invece di lasciare che tutta la crescita persistente delle app avvenga sul dispositivo di sistema.
L'attuale spiegazione di dove ZimaOS archivia i dati persistenti delle app è il miglior riferimento preventivo.
Controlla sia la capacità sia gli inode
Un filesystem può rifiutare nuovi file perché non dispone di blocchi liberi oppure perché ha esaurito gli inode. La procedura di risoluzione dei problemi suggerita per il sistema di origine raccomandava di controllare entrambi. In questo caso, il log indica fortemente un normale esaurimento della capacità, ma controllare entrambi i valori resta un'utile diagnostica in sola lettura.
Quando la reinstallazione diventa ragionevole
Se il disco di sistema è stato pieno al 100%, i metadati dello storage Docker sono danneggiati, il daemon non si avvia e la pulizia sicura non riesce a creare spazio di lavoro sufficiente, un ripristino controllato del sistema può essere più rapido e sicuro della modifica manuale dei metadati overlay di Docker.
Proteggi prima AppData e i dati dell'utente, verifica quali dischi verranno interessati dal ripristino ed evita di eliminare l'unica copia dei database delle applicazioni.
FAQ di Docker dopo la migrazione
overlay2 non era effettivamente supportato sull'hardware di origine?
I log mostrano innanzitutto che Docker non riusciva a creare i file di test di overlay2 perché il disco era pieno. Il messaggio del driver è comparso dopo quel fallimento.
La cancellazione dei file temporanei di Docker ha risolto il problema del sistema di origine?
No. L'autore originale ha detto che l'unità del sistema era rimasta piena al 100%.
L'attuale ZimaOS consente di spostare separatamente le immagini Docker e AppData?
Sì. L'attuale funzione Migrazione dati elenca le immagini Docker e i dati delle applicazioni Docker come categorie trasferibili separate.
Il ripristino alle impostazioni di fabbrica è stato confermato come riuscito nel thread?
No. L'utente ha detto che avrebbe proceduto, ma il thread pubblico termina prima di un risultato post-ripristino.
