Lorsque Docker refuse de démarrer après une migration des données de ZimaOS, la dernière ligne du journal peut être trompeuse. Dans ce cas source de février 2026, Docker a finalement indiqué que le pilote de stockage overlay2 n'était pas pris en charge. Quelques lignes plus haut, on découvre la véritable cause de l'échec : Docker ne pouvait pas créer de fichiers temporaires ni tester le stockage overlay, car le système n'avait plus d'espace disponible sur le périphérique.
L'utilisateur disposait d'un SSD ZimaOS de 180 Go et avait accidentellement laissé une base de données Immich en pleine croissance sur celui-ci. Lorsqu'il a tenté la migration, l'espace libre était insuffisant pour effectuer un déplacement propre. Après plusieurs tentatives et la suppression manuelle des journaux, AppData semblait avoir été migré, mais le disque système a tout de même atteint 100 % de remplissage et Docker ne pouvait plus s'initialiser après le redémarrage.
Immich a rempli le petit SSD système avant la migration
L'utilisateur source avait installé Immich sans déplacer sa base de données du disque système. À mesure que la photothèque s'est développée, le disque s'est rempli et ZimaOS a commencé à signaler des erreurs.
Cela correspond aux recommandations actuelles d'IceWhale : les données des applications doivent être placées sur l'espace de stockage principal plutôt que sur un petit disque système, car les bibliothèques photo, les métadonnées multimédias, les index de documents, les bases de données et les caches peuvent rapidement prendre de l'ampleur.
La migration elle-même nécessitait de l'espace de travail
L'utilisateur n'a essayé le processus de migration de ZimaOS qu'une fois le disque système déjà dangereusement rempli. Il a indiqué que les premières tentatives de migration avaient échoué faute d'espace libre suffisant pour mettre l'opération en mémoire tampon.
Il s'agit d'une leçon opérationnelle importante : déplacez AppData avant que le disque système n'atteigne ses derniers gigaoctets disponibles, et non après que Docker et les services de migration ont déjà épuisé leur espace de travail.
Le message concernant le socket Docker n'était qu'un symptôme
Les applications ont signalé :
Impossible de se connecter au démon Docker à l'adresse unix:///var/run/docker.sock.
Le démon Docker est-il en cours d'exécution ?Ce message signifie que le démon Docker est indisponible. Il n'indique pas pourquoi le démon a échoué.
Le journal a révélé la véritable cause racine
Les lignes importantes étaient les suivantes :
espace insuffisant sur le périphérique
Échec du chargement du profil AppArmor par défaut
mkdir /var/lib/docker/overlay2/check-overlayfs-support... : aucun espace disponible sur le périphérique
échec du démarrage du démon : erreur lors de l’initialisation de graphdriverDocker a d’abord échoué parce qu’il ne pouvait pas écrire de données temporaires. Plus tard, pilote non pris en charge le message était la conséquence de l’échec de l’initialisation du pilote de stockage, et non la preuve que le noyau en cours d’exécution avait soudainement perdu la prise en charge d’overlay2 après la migration.
Pourquoi le redémarrage de Docker n’a pas résolu le problème
L’utilisateur a essayé de redémarrer docker.service et docker.socket manuellement et a reçu le message « Accès refusé ». Une réponse de la communauté a établi un lien avec les contrôles de service de type appliance de ZimaOS.
Même si le redémarrage du service avait été autorisé, il n’aurait pas libéré d’espace disque. Le démon aurait simplement rencontré de nouveau la même erreur d’écriture.
La suppression des fichiers Docker temporaires n’a pas libéré suffisamment d’espace
La communauté a suggéré de supprimer les fichiers Docker temporaires après avoir d’abord vérifié l’espace disque. L’utilisateur d’origine a essayé cette méthode et a répondu que le disque système était toujours plein à 100 % et que Docker ne démarrerait toujours pas.
Ce résultat négatif est utile : un petit nettoyage temporaire ne peut pas corriger une conception de stockage où le disque système reste complètement saturé.
L’utilisateur source a choisi la sauvegarde et la restauration d’usine
Après l’échec de la tentative de nettoyage, l’utilisateur a décidé de sauvegarder /DATA/AppData et de réinstaller/restaurer ZimaOS. Le membre de la communauté a recommandé de noter les applications installées, d’utiliser la restauration du système d’usine, puis de migrer le stockage lié aux applications vers le grand disque avant de réinstaller les applications.
Le fil public s’arrête après que l’utilisateur a indiqué qu’il le ferait. Il ne contient aucune confirmation après la restauration ; la page ne doit donc pas présenter la réinstallation comme une solution finale vérifiée pour cet utilisateur en particulier.
La migration des données de ZimaOS actuelle précise davantage les éléments pouvant être déplacés
La version actuelle de ZimaOS propose des catégories de migration distinctes pour :
- Images Docker ;
- Données d’application Docker ;
- bases de données utilisateur telles que Galerie, Téléchargements, Documents, Médias et Sauvegarde.
Il s’agit d’une mise à jour importante de l’ancien fil de discussion, où l’on traitait parfois la « migration d’AppData » comme si elle couvrait automatiquement tout le stockage Docker.
Utilisez les catégories actuelles de migration des données de ZimaOS avant qu’un petit disque système ne soit dangereusement saturé.
Éviter le problème en définissant rapidement l’emplacement des données des applications
La version actuelle de ZimaOS propose également un emplacement pour les données des applications dans Réglages > Applications. IceWhale recommande de le définir dès le départ sur la baie de stockage plutôt que de laisser toute la croissance persistante des applications s’accumuler sur le périphérique système.
L’explication actuelle de l’emplacement où les applications ZimaOS stockent leurs données persistantes est la meilleure référence préventive.
Vérifier la capacité et les inodes
Un système de fichiers peut refuser les nouveaux fichiers parce qu’il n’a plus de blocs libres ou parce qu’il a épuisé les inodes. Le dépannage du système source recommandait de vérifier les deux. Dans ce cas, le journal indique fortement une saturation normale de la capacité, mais la vérification de ces deux valeurs reste un diagnostic en lecture seule utile.
Quand une réinstallation devient raisonnable
Si le disque système a été rempli à 100 %, que les métadonnées de stockage Docker sont endommagées, que le daemon ne peut pas démarrer et qu’un nettoyage sécurisé ne permet pas de libérer suffisamment d’espace de travail, une restauration contrôlée du système peut être plus rapide et plus sûre que la modification manuelle des métadonnées overlay de Docker.
Protégez d’abord AppData et les données utilisateur, vérifiez quels disques la restauration modifiera et évitez de supprimer l’unique copie des bases de données des applications.
FAQ sur Docker après la migration
overlay2 n’était-il réellement pas pris en charge sur le matériel source ?
Les journaux montrent d’abord que Docker ne pouvait pas créer les fichiers de test overlay2, car le disque était plein. Le message du pilote est apparu après cet échec.
La suppression des fichiers temporaires de Docker a-t-elle résolu le problème du système source ?
Non. L’auteur du message original a indiqué que le disque du système était resté rempli à 100 %.
La version actuelle de ZimaOS permet-elle de déplacer les images Docker séparément d’AppData ?
Oui. La migration actuelle des données répertorie les images Docker et les données des applications Docker comme catégories déplaçables distinctes.
La restauration d’usine a-t-elle été confirmée comme réussie dans le fil de discussion ?
Non. L’utilisateur a indiqué qu’il poursuivrait la procédure, mais le fil public s’arrête avant l’affichage d’un résultat après restauration.
