Tecnología · GUÍA PRÁCTICA
¿Docker dice ‘no queda espacio’ aunque df muestre espacio libre? Audita primero la ruta real
Docker puede escribir en otro montaje, agotar inodos o llenar el constructor Buildx seleccionado. Mapea la ruta antes de podar o mover datos.
Un resumen global de df puede parecer sano mientras está lleno el sistema de archivos que recibe la escritura de Docker. El pull, build o contenedor puede usar otro montaje, quedarse sin inodos o pertenecer a un constructor Buildx que no revisaste.
Conserva el comando y el error completos. Identifica el daemon activo, sus rutas y el constructor seleccionado; mapea cada ruta a un sistema de archivos y limpia solo cuando coincidan el propietario y el recurso agotado.
Conserva la operación fallida y el contexto
Anota si ENOSPC apareció durante pull, BuildKit, inicio, escritura de la aplicación o logs, y conserva la ruta completa del error. Una limpieza de caché no arregla necesariamente un directorio bind-mounted. La capa escribible del contenedor tampoco comparte necesariamente propietario con cada ruta del host que puede alcanzar.
Confirma docker context show, Docker Root Dir y el driver en docker info, y el constructor en docker buildx ls. Un contexto remoto o Docker Desktop cambia el límite de almacenamiento; no supongas /var/lib/docker local. En esos casos, detén este procedimiento local y utiliza la vista de almacenamiento documentada para ese daemon real.
Mapea cada ruta real a su sistema de archivos
Usa findmnt --target PATH --output SOURCE,FSTYPE,SIZE,USED,AVAIL,USE%,TARGET. Comprueba Docker Root Dir y, con Engine 29 y el almacén de containerd, también /var/lib/containerd. Esta comprobación adicional corresponde a instalaciones nuevas que usan el almacén de imágenes de containerd. La documentación actual de Docker confirma que data-root no traslada ese contenido ni sus snapshots.
No deduzcas el montaje por el nombre de la ruta. Un subdirectorio puede estar en otro volumen o sistema de red; mapea también cualquier bind mount o ruta de aplicación señalada por el error. Guarda el origen y el punto de montaje para que las mediciones antes y después de limpiar se refieran al mismo sistema de archivos.
Separa agotamiento de bloques e inodos
Ejecuta df -h PATH y df -i PATH. Pueden quedar gigabytes pero no inodos para otro archivo, o inodos pero ningún bloque. Cuotas, solo lectura y errores de E/S son ramas distintas. El espacio reservado también merece una rama separada; ENOSPC por sí solo no demuestra que los objetos Docker sean la causa.
Si faltan bytes, identifica al propietario grande; si faltan inodos, mide poblaciones de archivos. No borres un árbol desconocido hasta relacionarlo con Docker, containerd, un constructor, un bind mount o logs. Evita cruzar por accidente a montajes ajenos al buscar grandes consumos y conserva todos los datos con estado.
Mide la propiedad antes de podar
Usa docker system df -v para objetos del daemon y docker buildx du --builder NAME para el constructor del build fallido. Distingue registros recuperables, compartidos, mutables y activos. Docker especifica que los registros activos no se eliminan ni con --all. Las marcas de compartido o mutable tampoco autorizan una eliminación incondicional.
Empieza por un contenedor parado, imagen sin uso o caché acotada confirmados. system prune tiene un alcance mayor y los volúmenes exigen una opción explícita porque pueden contener datos persistentes. Antes de destruir nada, revisa proyectos Compose, volúmenes con nombre, propietario, copias y requisitos de reversión.
Migra solo el almacén demostrado como lleno
Si la retención supera la capacidad del sistema de archivos, programa mantenimiento y detén escrituras. Conserva configuración y copias, verifica permisos y propiedad, y sigue la documentación actual del daemon o containerd que posee ese almacén. Cambiar data-root no mueve el almacén de imágenes de containerd de Engine 29.
Después de limpiar o migrar, repite findmnt y ambos df sobre la misma ruta y vuelve a ejecutar el pull, build o write exacto que falló. Confirma también imágenes, contenedores, volúmenes y datos de la aplicación. Ni el reinicio ni la desaparición del error bastan: la operación original y el sistema de archivos elegido deben mostrar el resultado previsto.
