Cuando Docker se niega a iniciarse después de una migración de datos de ZimaOS, la última línea del registro puede resultar engañosa. En este caso de origen de febrero de 2026, Docker terminó informando que el controlador de almacenamiento overlay2 no era compatible. Leer unas líneas anteriores revela el fallo real: Docker no pudo crear archivos temporales ni probar el almacenamiento overlay porque al disco del sistema no le quedaba espacio.
El usuario tenía un SSD de ZimaOS de 180 GB y había dejado accidentalmente en él una base de datos de Immich que seguía creciendo. Cuando intentó realizar la migración, no había suficiente espacio libre para trasladarla correctamente. Después de varios intentos y de eliminar registros manualmente, AppData pareció migrarse, pero el disco del sistema siguió alcanzando el 100 % de uso y Docker ya no pudo inicializarse después del reinicio.
Immich llenó el pequeño SSD del sistema antes de la migración
El usuario de origen instaló Immich sin mover su base de datos fuera de la unidad del sistema. A medida que crecía la biblioteca de fotos, el disco se llenó y ZimaOS comenzó a informar de errores.
Esto coincide con las indicaciones actuales de IceWhale: los datos de las aplicaciones deben colocarse en el espacio de almacenamiento principal en lugar de en un disco del sistema pequeño, porque las bibliotecas de fotos, los metadatos multimedia, los índices de documentos, las bases de datos y las cachés pueden crecer rápidamente.
La migración en sí necesitaba espacio de trabajo
El usuario intentó usar el flujo de migración de ZimaOS solo después de que el disco del sistema ya estuviera críticamente lleno. Indicó que los primeros intentos de migración fallaron porque no había suficiente espacio libre para almacenar temporalmente la operación.
Esta es una lección operativa importante: mueve AppData antes de que el disco del sistema llegue a los últimos gigabytes disponibles, no después de que Docker y los servicios de migración ya se hayan quedado sin espacio de trabajo.
El mensaje del socket de Docker era solo un síntoma
Las aplicaciones informaron:
No se puede conectar con el demonio de Docker en unix:///var/run/docker.sock.
¿Está ejecutándose el demonio de Docker?Ese mensaje significa que el demonio de Docker no está disponible. No identifica por qué falló el demonio.
El registro reveló la causa raíz real
Las líneas importantes fueron:
no queda espacio en el dispositivo
No se pudo garantizar que el perfil predeterminado de AppArmor estuviera cargado
mkdir /var/lib/docker/overlay2/check-overlayfs-support...: no space left on device
failed to start daemon: error initializing graphdriverDocker falló primero porque no pudo escribir datos temporales. Después apareció el mensaje controlador no compatible el mensaje era consecuencia del fallo al inicializar el controlador de almacenamiento, no una prueba de que el kernel en ejecución hubiera perdido repentinamente la compatibilidad con overlay2 después de la migración.
Por qué reiniciar Docker no solucionó el problema
El usuario intentó reiniciar docker.service y docker.socket manualmente y recibió el mensaje «Acceso denegado». Una respuesta de la comunidad relacionó esto con los controles de servicio propios de un dispositivo de ZimaOS.
Incluso si se hubiera permitido reiniciar el servicio, no habría liberado espacio en disco. El demonio simplemente volvería a encontrarse con el mismo fallo de escritura.
Borrar los archivos temporales de Docker no recuperó suficiente espacio
La comunidad sugirió borrar los archivos temporales de Docker después de comprobar primero el espacio en disco. El usuario original lo intentó y respondió que la unidad del sistema seguía llena al 100 % y que Docker todavía no se iniciaba.
Este resultado negativo es útil: una limpieza temporal pequeña no puede solucionar un diseño de almacenamiento en el que el disco del sistema permanece completamente saturado.
El usuario original eligió hacer una copia de seguridad y restaurar los valores de fábrica
Tras fallar el intento de limpieza, el usuario decidió hacer una copia de seguridad /DATA/AppData y reinstalar/restaurar ZimaOS. El miembro de la comunidad recomendó anotar las aplicaciones instaladas, usar la restauración del sistema de fábrica y, después, migrar el almacenamiento relacionado con las aplicaciones al disco grande antes de reinstalar las aplicaciones.
El hilo público termina después de que el usuario dijera que lo haría. No contiene una confirmación posterior a la restauración, por lo que la página no debería presentar la reinstalación como una solución final verificada para este usuario específico.
La migración de datos de ZimaOS es ahora más explícita sobre lo que se puede mover
La versión actual de ZimaOS ofrece categorías de migración independientes para:
- Imágenes de Docker;
- Datos de aplicaciones de Docker;
- bases de datos de usuario, como Galería, Descargas, Documentos, Multimedia y Copia de seguridad.
Esta es una actualización importante del hilo anterior, en el que a veces se trataba la «migración de AppData» como si cubriera automáticamente todo el almacenamiento de Docker.
Usa las categorías actuales de Migración de datos de ZimaOS antes de que un disco del sistema pequeño se llene de forma crítica.
Prevén el problema configurando pronto la ubicación de los datos de las aplicaciones
El ZimaOS actual también muestra una ubicación para los datos de las aplicaciones en Ajustes > Aplicaciones. IceWhale recomienda configurarla desde el principio en el conjunto de almacenamiento, en lugar de dejar todo el crecimiento persistente de las aplicaciones en el dispositivo del sistema.
La explicación actual de dónde almacenan sus datos persistentes las aplicaciones de ZimaOS es la mejor referencia preventiva.
Comprueba tanto la capacidad como los inodos
Un sistema de archivos puede rechazar archivos nuevos porque no tiene bloques libres o porque ha agotado los inodos. La solución de problemas del sistema de origen sugería comprobar ambos. En este caso, el registro apunta claramente a un agotamiento normal de la capacidad, pero comprobar ambos valores sigue siendo un diagnóstico útil de solo lectura.
Cuándo resulta razonable reinstalar
Si el disco del sistema se ha llenado al 100 %, los metadatos de almacenamiento de Docker están dañados, el demonio no puede iniciarse y la limpieza segura no puede crear suficiente espacio de trabajo, una restauración controlada del sistema puede ser más rápida y segura que editar manualmente los metadatos de overlay de Docker.
Protege primero AppData y los datos del usuario, entiende qué discos afectará la restauración y evita eliminar la única copia de las bases de datos de las aplicaciones.
Preguntas frecuentes sobre Docker después de la migración
¿Realmente overlay2 no era compatible con el hardware de origen?
Los registros muestran primero que Docker no pudo crear archivos de prueba de overlay2 porque el disco estaba lleno. El mensaje del controlador apareció después de ese fallo.
¿Vaciar la carpeta temporal de Docker solucionó el sistema de origen?
No. El autor original indicó que la unidad del sistema seguía llena al 100 %.
¿El ZimaOS actual permite mover las imágenes de Docker por separado de AppData?
Sí. La Migración de datos actual muestra las imágenes de Docker y los datos de las aplicaciones Docker como categorías independientes que se pueden mover.
¿Se confirmó en el hilo que la restauración de fábrica se realizó correctamente?
No. El usuario dijo que procedería con ello, pero el hilo público termina antes de mostrar un resultado posterior a la restauración.
