Docker 29 y el daemon.json heredado: por qué puedes quedarte sin imágenes
Docker 29 usa containerd snapshotter por defecto y ya no incluye el driver overlay2 clásico. Un daemon.json heredado puede dejar el daemon sin arrancar o sin imágenes visibles.
Docker 29.7.2 ha cambiado una pieza que muchos administradores dan por sentada: el almacenamiento de imágenes. La versión usa containerd snapshotter por defecto y el driver overlay2 clásico ya no está disponible. Un daemon.json copiado de un host antiguo puede romper el arranque o, peor, hacer que docker ps -a y docker images aparezcan vacíos aunque las imágenes sigan en el disco.
Dos fallos con el mismo archivo
El primer problema aparece si el archivo incluye "storage-driver": "overlay2". En Docker 29 ese driver no existe, así que el daemon no arranca. El error que reporta es configured driver "overlay2" not available: unavailable. La línea tenía sentido en hosts con versiones anteriores, y ese es justo el motivo por el que viaja en el archivo.
El segundo es más silencioso. Si el daemon.json lleva "features": {"containerd-snapshotter": false}, el daemon levanta sin quejarse. Pero docker ps -a y docker images devuelven listas vacías. No se ha borrado nada: con el snapshotter activo, las imágenes viven en el content store de containerd, y un daemon apuntando al almacén clásico lee un directorio vacío. docker volume ls sigue igual, los metadatos de contenedores siguen en /var/lib/docker/containers y sudo ctr -n moby images ls muestra todas las imágenes donde toca. Basta con volver a poner la feature en true y reiniciar para que reaparezcan.
Cómo comprobarlo antes de copiar
La comprobación que evita el primer fallo es sencilla: docker info | grep -iE "Storage Driver|driver-type". Si la salida dice overlayfs, el host está usando el snapshotter y storage-driver no debería estar en el daemon.json.
Hay un detalle aparte que también cuesta un reinicio: las opciones log-opts solo se aplican a contenedores creados después del cambio. Los que ya existían siguen escribiendo logs sin límite hasta que se fuerzan con un recreate.
El aviso no viene de una nota oficial de Docker, sino de un caso concreto en un host nuevo. Aun así, afecta a cualquier despliegue que reutilice configuraciones entre máquinas. Antes de copiar un daemon.json de un servidor antiguo, conviene revisar qué driver espera la versión instalada. El coste de no hacerlo no es una advertencia en el arranque: puede ser un docker images vacío que parece una pérdida de datos.
