8 errores comunes de Docker (y el fix real de cada uno)

En pocas palabras: Un relevamiento de dev.to del 5 de noviembre de 2026 identificó ocho errores de Docker que bloquean builds y deploys, entre ellos el daemon caído, permisos del socket, arquitectura ARM/amd64, puertos ocupados y falta de espacio en disco. Cada uno se soluciona con un comando puntual en minutos, sin necesidad de reinstalar ni reconstruir desde cero.

Docker sigue generando los mismos ocho errores que le comen la tarde a cualquier equipo que lo usa a diario, según un relevamiento publicado el 5 de noviembre de 2026 en dev.to. La buena noticia es que cada uno tiene una causa raíz identificable y un fix que se resuelve en minutos, no en horas.

Docker es la plataforma de contenedores que empaqueta una aplicación con sus dependencias para que corra igual en tu notebook y en un servidor de producción. Los errores comunes de Docker son fallas recurrentes del daemon, los permisos, la arquitectura de la imagen o el espacio en disco que bloquean un build o un deploy, pero que se resuelven con comandos puntuales y bien documentados.

¿Cuáles son los errores comunes de Docker y por qué los mensajes son tan poco claros?

Los errores comunes de Docker son casi siempre los mismos ocho: daemon caído, permisos, arquitectura, rutas del build, puertos ocupados, disco lleno, intérpretes faltantes y Compose desactualizado. El problema no es que sean raros, sino que Docker los reporta con mensajes de bajo nivel que no explican la causa real.

Buildeás la imagen en local, te anda perfecto, la subís al registry, la bajás en el servidor y ahí explota con un mensaje que no te dice nada sobre arquitectura, permisos ni rutas, así que terminás googleando el texto exacto del error en vez de buscar la causa de fondo. Es el patrón que describe el posteo original: un puñado de causas repetidas, disfrazadas con nombres técnicos distintos cada vez.

Dato curioso: el posteo lo escribió Hollis, un agente de IA que también mantiene la base de errores errorfix.surge.sh, algo que el propio texto aclara en una nota de transparencia al final del artículo. Tomalo con pinzas en cuanto a matices, pero los comandos son los de siempre y funcionan.

¿Qué significa el error “Cannot connect to the Docker daemon”?

“Cannot connect to the Docker daemon at unix:///var/run/docker.sock” significa que el daemon no está corriendo o que tu terminal no llega al socket donde escucha. Es el error número uno de la lista y el fix cambia según el sistema operativo.

En Linux lo arrancás con sudo systemctl start docker y lo dejás habilitado para el boot con sudo systemctl enable docker. En Mac y Windows el problema casi siempre es que Docker Desktop no terminó de iniciar: esperá a que el ícono de la ballena se quede quieto antes de correr cualquier comando. Si trabajás con WSL2, el error suele venir de que tu distro no está habilitada en Settings → Resources → WSL integration, que es el paso que más gente se salta. Sobre eso hablamos en errores comunes al configurar GPO en Azure AD.

¿Qué significa “permission denied” al conectar con el socket de Docker?

“permission denied while trying to connect to the Docker daemon socket” aparece cuando el daemon ya está corriendo pero tu usuario no tiene permiso para hablarle. Se arregla sumando tu usuario al grupo docker con sudo usermod -aG docker $USER y después corriendo newgrp docker (o cerrando sesión y volviendo a entrar).

Ojo con esto: el grupo docker equivale a acceso root en la máquina. No es joda. Cualquier usuario que esté ahí puede montar el filesystem completo del host dentro de un contenedor privilegiado. ¿Alguien audita quién está en ese grupo en tu servidor? Probablemente no, hasta que ya es tarde.

¿Por qué aparece “exec format error” o “no matching manifest”?

“exec format error” y “no matching manifest for linux/arm64/v8” aparecen cuando hay un mismatch de arquitectura entre la imagen y la máquina que la corre, típicamente Apple Silicon (ARM) contra un servidor amd64, o al revés.

Si necesitás levantar una imagen ajena que no tiene tu arquitectura, podés emular con docker run --platform linux/amd64 some/image (más lento, pero zafa). El caso más común es al revés: buildeaste tu propia imagen en una Mac M1 o M2 y la mandaste a un servidor x86, y ahí explota solo en producción. La solución es buildear con docker buildx build --platform linux/amd64,linux/arm64 -t vos/app --push, así generás ambas arquitecturas de una.

¿Te pasó que local andaba perfecto y en el servidor rompía todo? Exacto, es el caso más común de este tipo de error. Lo explicamos a fondo en soporte Linux para el chip T1 de Apple.

¿Por qué falla “COPY failed: file not found in build context”?

“COPY failed: file not found in build context” pasa porque las rutas de COPY en el Dockerfile son relativas al build context (el punto de docker build .), no al Dockerfile, y no pueden subir niveles con ../.

El otro sospechoso habitual es el .dockerignore: un patrón suelto como * o config/ borra archivos del contexto sin avisarte nada, y vos seguís pensando que el problema es el Dockerfile. Si tu Dockerfile vive en una subcarpeta, buildeá desde la carpeta padre con docker build -f app/Dockerfile . en vez de moverte con rutas relativas raras.

¿Cómo soluciono “port is already allocated” en Docker?

“Bind for 0.0.0.0:5432 failed: port is already allocated” se soluciona identificando qué proceso ya usa ese puerto con docker ps --filter "publish=5432" o sudo lsof -i :5432, y después parando ese proceso o mapeando un puerto distinto con -p 5433:5432.

El culpable suele ser un Postgres local corriendo aparte o un contenedor viejo que nunca bajaste. Revisalo antes de reiniciar la compu entera.

¿Qué hago cuando Docker dice “no space left on device”?

“no space left on device” aparece porque Docker nunca limpia solo lo que va dejando atrás: imágenes intermedias, contenedores parados, cache de build. Con el tiempo se come el disco entero. Más contexto en las limitaciones de Omarchy Linux en Mac.

Revisá qué ocupa espacio con docker system df, y después limpiá con docker system prune para contenedores parados, imágenes sin usar y redes huérfanas. El builder cache suele ser el mayor culpable, así que docker builder prune libera más espacio del que esperás. Usá las flags -a y --volumes solo si entendés que borran imágenes y datos de volúmenes que todavía no usás activamente, porque ahí sí podés perder algo que necesitabas (sí, en serio, lee la flag dos veces antes de apretar enter).

¿Qué son “standard_init_linux.go” y “docker-compose: command not found”?

“standard_init_linux.go: exec user process caused: no such file or directory” no significa que falte el archivo, sino que falta su intérprete: casi siempre un entrypoint.sh con finales de línea de Windows (\r) o un binario compilado contra glibc metido en una imagen Alpine basada en musl. Mirá también los errores típicos al usar Patchstack.

Para lo primero, corré sed -i 's/\r$//' entrypoint.sh o agregá una regla .gitattributes con *.sh text eol=lf para que no vuelva a pasar. Para lo segundo, compilá con CGO_ENABLED=0 o cambiá a una imagen base Debian en vez de Alpine.

El octavo de la lista es más simple: “docker-compose: command not found” aparece porque Compose v1 está retirado. A noviembre de 2026, el comando correcto es un plugin con espacio, docker compose up -d, sin guion. Más simple, imposible. Si tampoco funciona, instalá docker-compose-plugin.

Error	Causa real	Fix rápido
Cannot connect to the Docker daemon	Daemon no está corriendo	sudo systemctl start docker o abrir Docker Desktop
permission denied (socket)	Usuario fuera del grupo docker	usermod -aG docker $USER + relogueo
exec format error	Mismatch ARM vs amd64	docker buildx build --platform linux/amd64,linux/arm64
COPY failed	Ruta fuera del build context o .dockerignore	docker build -f app/Dockerfile .
port is already allocated	Otro proceso usa el puerto	lsof -i :puerto + remapear con -p
no space left on device	Cache e imágenes sin limpiar	docker builder prune
standard_init_linux.go	Entrypoint con \r o glibc en Alpine	sed -i 's/\r$//' o base Debian
docker-compose: command not found	Compose v1 retirado	docker compose up -d

¿Qué implica esto para equipos que deployan en Latinoamérica?

Para equipos que corren sus propios contenedores en un VPS o servidor cloud en Latinoamérica, estos ocho errores son los que más suelen complicar la migración de local a producción. Si estás por mover tu stack dockerizado, conviene verificar de entrada la arquitectura del host (amd64 en la mayoría de los VPS) y dejar documentado en el README cómo buildear con buildx. Para alojar contenedores en Argentina, donweb.com ofrece Docker Hosting Cloud con Docker y Docker Compose preinstalados, listo para producción.

Errores comunes al diagnosticar estos problemas

• Reinstalar Docker entero: mucha gente borra todo y reinstala cuando el problema real es un puerto ocupado o un permiso de grupo. Perdés tiempo por algo que se arregla con un comando.
• Ignorar el .dockerignore: asumir que el build context solo tiene lo que ves en el Dockerfile, cuando en realidad un patrón mal puesto te está borrando archivos sin avisar.
• Sumar usuarios al grupo docker sin pensarlo: dar ese acceso en un servidor compartido sin evaluar que equivale casi a root, y enterarse del problema recién después de un incidente.
• Mezclar arquitecturas sin querer: buildear en una Mac M1/M2 y asumir que la imagen va a correr igual en cualquier servidor, sin especificar --platform.

Preguntas Frecuentes

¿Qué es “exec format error” en Docker?

Es el error que tira Docker cuando intenta ejecutar un binario compilado para una arquitectura distinta a la del host, como una imagen armada en Apple Silicon corriendo en un servidor amd64. Se soluciona especificando la plataforma al buildear con docker buildx build --platform linux/amd64. Esto se conecta con lo que analizamos en montar tu propia alternativa a GitHub Gists.

¿Cómo arranco el daemon de Docker si no está corriendo?

En Linux con sudo systemctl start docker; en Mac y Windows, abriendo Docker Desktop y esperando a que termine de iniciar. En WSL2 hay que habilitar la distro en Settings → Resources → WSL integration.

¿Por qué me dice “port is already allocated” en Docker?

Porque otro proceso del host, muchas veces un Postgres local o un contenedor viejo, ya está usando ese puerto. Identificalo con docker ps --filter "publish=5432" o sudo lsof -i :puerto y parálo, o mapeá un puerto distinto con -p.

¿Cómo libero espacio cuando Docker dice “no space left on device”?

Corré docker system df para ver qué ocupa espacio y docker system prune para borrar contenedores parados e imágenes sin usar. El builder cache suele ser lo más pesado, así que docker builder prune libera la mayor parte.

¿docker-compose y docker compose son lo mismo?

No del todo: docker-compose (con guion) era el binario de Compose v1, que quedó retirado. A noviembre de 2026, el comando correcto es docker compose (con espacio), que viene como plugin, y si no funciona hay que instalar docker-compose-plugin.

Conclusión

Los ocho errores que lista el relevamiento de dev.to no son nuevos ni exóticos: son los mismos que cualquier equipo que usa Docker hace tiempo se cruzó más de una vez. Lo que cambia es si los reconocés en 30 segundos o si les dedicás una tarde entera googleando el mensaje textual.

Guardate los comandos de esta nota. La próxima vez que Docker te tire un mensaje incomprensible, vas a saber por dónde empezar a buscar antes de asumir que hay que reinstalar todo.

Fuentes

• 8 Docker errors that waste an afternoon (and the actual fix) – dev.to, publicado el 5 de noviembre de 2026
• errorfix.surge.sh/docker – base de errores de Docker y Kubernetes documentada por error exacto