Contenido

Mensajes de error de Docker: causas y soluciones (con salida real)

Esta página reúne los mensajes de error más comunes de Docker. Cada encabezado es una palabra clave del mensaje de error, así que puedes buscarlo directamente con la búsqueda del navegador (Ctrl+F). Cada error incluye la salida reproducida en Docker 29, la causa y la solución.

Si no encuentras tu error, sigue estos pasos básicos:

  1. Mira la palabra clave de la última parte del mensaje de error.
  2. Usa docker ps -a para ver el estado del contenedor y su código de salida.
  3. Usa docker logs nombre-del-contenedor para ver la salida del propio programa.
  4. Consulta los pasos detallados de depuración en Ver registros y depurar.

Conexión y permisos

failed to connect to the docker API / Cannot connect to the Docker daemon

$ docker run --rm --entrypoint docker docker:29.9-cli -H unix:///var/run/docker.sock ps
failed to connect to the docker API at unix:///var/run/docker.sock; check if the path is correct and if the daemon is running: dial unix /var/run/docker.sock: connect: no such file or directory

Las versiones antiguas mostraban Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?. El significado es el mismo: el comando docker (cliente) no encuentra Docker Engine (servidor).

Solución:

  • Windows / macOS: comprueba que Docker Desktop está abierto. La ballena de la bandeja del sistema debe dejar de moverse y el estado debe indicar Engine running.
  • Linux: inicia el servicio de Docker con sudo systemctl start docker y actívalo al arrancar con sudo systemctl enable docker.
  • Comprueba si está definida la variable de entorno DOCKER_HOST o si cambiaste a otro context: docker context ls.

permission denied while trying to connect to the docker API

$ docker run --rm -u 1000:1000 -v /var/run/docker.sock:/var/run/docker.sock docker:29.9-cli docker ps
permission denied while trying to connect to the docker API at unix:///var/run/docker.sock

En Linux, solo root y los miembros del grupo docker pueden acceder a /var/run/docker.sock. Los usuarios normales ven este error al ejecutar docker.

Solución: añade tu usuario al grupo docker y cierra sesión y vuelve a entrar (o ejecuta newgrp docker) para que el cambio surta efecto:

sudo usermod -aG docker $USER

Pertenecer al grupo docker equivale a tener permisos de root; el motivo está en Buenas prácticas de seguridad. Para evitarlo, puedes usar el modo Rootless.

Puertos y nombres

port is already allocated

$ docker run -d --name web1 -p 8080:80 nginx:1.30-alpine
7a72d42f052dfebded509314b1975c72fbb1fcbf0c97099d6d60c9dedbcad8a1

$ docker run -d --name web2 -p 8080:80 nginx:1.30-alpine
6bcca59a67e5a5adbab1da7b2dbb7ef92f1df1f6e7680462a22541fd96f0ac9f
docker: Error response from daemon: failed to set up container networking: driver failed programming external connectivity on endpoint web2 (3a269ae1baae56a10b06552ba76fff69b3414885b2fa7a737344e081b4d5acd5): Bind for 0.0.0.0:8080 failed: port is already allocated

Run 'docker run --help' for more information

El puerto 8080 del host ya lo usa otro contenedor (en este ejemplo, web1). Fíjate en que, cuando se produce el error, web2 ya se creó pero no arrancó (su estado es Created). Si después de resolverlo vuelves a ejecutar el mismo comando sin más, aparecerá otro error: el nombre ya está en uso.

Solución:

  • Usa otro puerto del host: -p 8081:80.
  • O detén el contenedor que ocupa el puerto: busca con docker ps quién usa el 8080 y ejecuta docker stop.
  • Elimina el contenedor que no llegó a arrancar: docker rm web2.

address already in use

$ docker run -d --name web3 -p 9090:80 nginx:1.30-alpine
2c4649bbf85211d1ef6852c95fad52075b63d8d77e3fcd7c74db0bc7d15fbd8f
docker: Error response from daemon: failed to set up container networking: driver failed programming external connectivity on endpoint web3 (38386ef2562f999706b1d2b00eac0e48125eb006916dc857832ce18d36fe44d6): failed to bind host port 0.0.0.0:9090/tcp: address already in use

Run 'docker run --help' for more information

Es parecido al error anterior, pero el puerto lo usa otro programa del host, no un contenedor. Por ejemplo, puede haber un Nginx o un MySQL instalado en local, o un servidor de desarrollo en marcha.

Solución: busca y detén el programa que usa el puerto, o elige otro puerto.

sudo lsof -i :9090          # Linux / macOS
netstat -ano | findstr 9090 # Windows

The container name "/web1" is already in use

$ docker run -d --name web1 -p 8081:80 nginx:1.30-alpine
docker: Error response from daemon: Conflict. The container name "/web1" is already in use by container "7a72d42f052dfebded509314b1975c72fbb1fcbf0c97099d6d60c9dedbcad8a1". You have to remove (or rename) that container to be able to reuse that name.

Run 'docker run --help' for more information

Los nombres de los contenedores deben ser únicos, incluidos los de los contenedores detenidos.

Solución:

  • Elimina el contenedor antiguo: docker rm -f web1.
  • O elige otro nombre.
  • Añade --rm a los contenedores de un solo uso para que se eliminen al terminar y no dejen un contenedor con el mismo nombre.

Imágenes

not found / manifest unknown / pull access denied

$ docker pull nginx:9.99
Error response from daemon: failed to resolve reference "docker.io/library/nginx:9.99": docker.io/library/nginx:9.99: not found

$ docker pull ngnix-official-not-real
Using default tag: latest
Error response from daemon: failed to resolve reference "docker.io/library/ngnix-official-not-real:latest": docker.io/library/ngnix-official-not-real:latest: not found

No se encuentra la imagen. Causas habituales:

  • La etiqueta está mal escrita o no existe: no hay una versión nginx:9.99. Revisa la página Tags en Docker Hub o ejecuta docker buildx imagetools inspect nombre-de-imagen.
  • El nombre está mal escrito: ngnix. Los nombres de las imágenes oficiales no llevan prefijo, por ejemplo nginx y postgres.
  • No iniciaste sesión en el registry privado: ejecuta antes docker login.

Según la versión de Docker y el registry, el mismo problema puede aparecer como manifest unknown o pull access denied for ..., repository does not exist or may require 'docker login'.

repository name must be lowercase / invalid reference format

$ docker build -t MyApp .
ERROR: failed to build: invalid tag "MyApp": repository name must be lowercase

Los nombres de imagen solo pueden contener letras minúsculas, números y -, _, . y /. Cambia MyApp por myapp. Si el nombre contiene espacios o dos puntos de más (por ejemplo, myapp::1.0), Docker muestra invalid reference format.

toomanyrequests: You have reached your pull rate limit

Docker Hub limita las descargas de imágenes cuando no has iniciado sesión. Llegarás al límite si descargas muchas imágenes en poco tiempo, por ejemplo cuando el CI las vuelve a descargar en cada ejecución. Este error no se reprodujo en el entorno del tutorial, así que el texto del error se basa en la documentación oficial.

Solución:

  • Inicia sesión en Docker Hub con docker login para tener un límite más alto.
  • Usa caché en el CI o un espejo de la imagen en otro registry.
  • No hace falta descargar las imágenes que ya tienes en tu máquina. No añadas --pull always a los comandos sin necesidad.

exec format error

La arquitectura de CPU de la imagen no coincide con la del host. Por ejemplo, una imagen arm64 construida en un Mac con Apple Silicon se ejecuta en un servidor amd64. La salida real y las soluciones están en Imágenes multiplataforma.

Fallos al iniciar el contenedor

exec /entrypoint.sh: no such file or directory (aunque el archivo existe)

Es lo más habitual entre usuarios de Windows: el script de shell se guardó con finales de línea de Windows (CRLF).

$ docker build -q -t crlf-demo .
sha256:194d0a73ff66c601a1e7b1bf80417ae47c5de6e5e076415f17b483e642929fc2

$ docker run --rm crlf-demo
exec /entrypoint.sh: no such file or directory

$ od -c entrypoint.sh | head -n 2
0000000   #   !   /   b   i   n   /   s   h  \r  \n   e   c   h   o    
0000020   "   h   e   l   l   o       f   r   o   m       e   n   t   r

od -c muestra que la primera línea termina en \r \n. Linux lee el intérprete como /bin/sh\r (con un \r invisible de más). Ese programa no existe, así que Docker muestra no such file or directory, un mensaje muy engañoso.

Solución:

  • Cambia los finales de línea a LF en el editor (en VS Code, haz clic en CRLF en la esquina inferior derecha y cámbialo a LF).

  • En Windows, Git convierte por defecto los finales de línea a CRLF. Añade un .gitattributes en la raíz del proyecto para que los scripts usen siempre LF:

    *.sh text eol=lf
  • O convierte el archivo en el Dockerfile: RUN sed -i 's/\r$//' /entrypoint.sh.

exec: "/entrypoint.sh": permission denied

$ docker build -q -t noexec-demo .
sha256:4f37fec89287104ccf6b509fef5c1836d2a1a65b36d858ff63b95fecc3340a0e

$ docker run --rm noexec-demo
docker: Error response from daemon: failed to create task for container: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: error during container init: exec: "/entrypoint.sh": permission denied

Run 'docker run --help' for more information

El script no tiene permiso de ejecución. Los sistemas de archivos de Windows no tienen los permisos de ejecución de Linux, así que es especialmente habitual al construir desde Windows.

Solución: añade el permiso de ejecución en el Dockerfile:

COPY --chmod=755 entrypoint.sh /entrypoint.sh

O ejecuta chmod +x entrypoint.sh en Linux / macOS antes de construir.

executable file not found in $PATH

$ docker run --rm alpine:3.23 bash
docker: Error response from daemon: failed to create task for container: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: error during container init: exec: "bash": executable file not found in $PATH

Run 'docker run --help' for more information

El programa no está en el contenedor. La imagen alpine no incluye bash, solo sh.

Solución: usa sh, o instala bash en el Dockerfile con RUN apk add --no-cache bash. También pasa a menudo cuando el nombre del programa en CMD está mal escrito o el programa no se copió a la imagen.

El contenedor arranca y termina de inmediato con Exited (0)

$ docker run -d --name u1 ubuntu:26.04
9ff7034514a469602b48cc1bb3758514b32af8de6c602ce1bee11cd85813671c

$ docker ps -a --filter name=u1 --format "table {{.Names}}\t{{.Status}}"
NAMES     STATUS
u1        Exited (0) 2 seconds ago

$ docker rm u1
u1

No es un error: el contenedor se detiene cuando termina su proceso principal. El comando por defecto de la imagen ubuntu es bash. Al ejecutarse en segundo plano (-d) sin terminal, bash no puede leer entrada y termina.

Solución:

  • Para interactuar con él: docker run -it ubuntu:26.04 bash.
  • Para que siga en marcha: dale un programa que no termine, como un servidor web. Para pruebas puedes usar sleep infinity.
  • Si el código de salida no es 0, revisa en docker logs el mensaje de error del programa.

Exited (137) u OOMKilled

El código de salida 137 indica que el contenedor se detuvo a la fuerza con SIGKILL (128 + 9). Causas habituales:

  • Falta de memoria: el contenedor superó su límite de --memory o el host se quedó sin memoria, y el sistema lo detuvo. Compruébalo con docker inspect -f "{{.State.OOMKilled}}" contenedor; true significa que se quedó sin memoria.
  • El programa no terminó tras los 10 segundos de espera de docker stop, así que se detuvo a la fuerza. Consulta la prueba de PID 1 en Aplicaciones Node.js.
  • docker kill o docker rm -f.

El host de pruebas de este tutorial no tiene activado el límite de swap, así que la falta de memoria no se pudo reproducir de forma fiable. Por eso este caso no incluye salida real.

cannot attach stdin to a TTY-enabled container because stdin is not a terminal / the input device is not a TTY

$ docker run -d --name a1 alpine:3.23 sleep 300
55637ca715821720e55fa1366d8df8813915bf12b7520f65b9e85922ea7c475c

$ docker exec -it a1 bash
cannot attach stdin to a TTY-enabled container because stdin is not a terminal

-t pide una terminal, pero la entrada actual no es una terminal. Pasa a menudo al usar docker exec -it en un script, en CI o en cron, o al pasar un archivo al contenedor con < o |.

Solución: en uso no interactivo, quita -t. Deja solo -i si necesitas pasar entrada, o no uses ninguna de las dos. Por ejemplo, usa docker exec -i para restaurar una base de datos.

Compilación (docker build)

failed to read dockerfile: open Dockerfile: no such file or directory

$ docker build -t x .
#0 building with "default" instance using docker driver

#1 [internal] load build definition from Dockerfile
#1 transferring dockerfile: 2B done
#1 DONE 0.0s
ERROR: failed to build: failed to solve: failed to read dockerfile: open Dockerfile: no such file or directory

No hay ningún Dockerfile en el directorio actual.

Solución:

  • Comprueba que estás en el directorio correcto. El . final es la ruta del contexto de compilación.
  • El archivo debe llamarse Dockerfile (con las mismas mayúsculas y sin extensión). El Bloc de notas de Windows puede añadir .txt automáticamente, y el archivo queda como Dockerfile.txt.
  • Si el archivo tiene otro nombre, indícalo con -f: docker build -f Dockerfile.dev ..

failed to calculate checksum ... not found (COPY no encuentra el archivo)

$ docker build -t copy-demo .

[+] Building 0.1s (6/6) FINISHED                                                                                                       docker:default
 => [internal] load build definition from Dockerfile                                                                                             0.0s
 => => transferring dockerfile: 88B                                                                                                              0.0s
 => WARN: CopyIgnoredFile: Attempting to Copy file "config.json" that is excluded by .dockerignore (line 2)                                      0.0s
 => [internal] load metadata for docker.io/library/alpine:3.23                                                                                   0.0s
 => [internal] load .dockerignore                                                                                                                0.0s
 => => transferring context: 52B                                                                                                                 0.0s
 => [internal] load build context                                                                                                                0.0s
 => => transferring context: 2B                                                                                                                  0.0s
 => CACHED [1/2] FROM docker.io/library/alpine:3.23@sha256:85fe1e81d6758c208f3e1eed4338a1997e19d4be002d4dd32d3100c9a8c010a0                      0.0s
 => => resolve docker.io/library/alpine:3.23@sha256:85fe1e81d6758c208f3e1eed4338a1997e19d4be002d4dd32d3100c9a8c010a0                             0.0s
 => ERROR [2/2] COPY config.json /app/config.json                                                                                                0.0s
------
 > [2/2] COPY config.json /app/config.json:
------

 1 warning found (use docker --debug to expand):
 - CopyIgnoredFile: Attempting to Copy file "config.json" that is excluded by .dockerignore (line 2)
Dockerfile:2
--------------------
   1 |     FROM alpine:3.23
   2 | >>> COPY config.json /app/config.json
   3 |
--------------------
ERROR: failed to build: failed to solve: failed to compute cache key: failed to calculate checksum of ref v1wocdfz4uxsgxp2q2kukkuqp::jww9anqv7tl0n3ksy
1tlwp8fv: "/config.json": not found

El archivo que usa COPY no está en el contexto de compilación. El WARN: CopyIgnoredFile del principio ya explica el motivo: .dockerignore excluyó config.json.

Causas habituales:

  • .dockerignore excluye el archivo (Docker 29 muestra antes una advertencia).
  • La ruta es incorrecta o el archivo está fuera del contexto de compilación (el . final de docker build). COPY ../archivo no puede acceder al directorio superior.
  • Las mayúsculas no coinciden. Windows y macOS no distinguen mayúsculas de minúsculas; Linux sí.

RUN ... did not complete successfully: exit code: 1

Falló un comando RUN durante la compilación. Mira la salida entre las líneas ------ de arriba: es el mensaje de error del propio comando. Por ejemplo, collectstatic de Django falla si no está definido STATIC_ROOT, como se explica en Aplicaciones Python. Añade --progress plain si no ves la salida completa.

Volúmenes y redes

volume is in use

$ docker volume create data
data

$ docker run -d --name holder -v data:/data alpine:3.23 sleep 300
38eb68e3f9c7020fdb86ded25f1e73dc0a9fdcb932dea1353d04c4474e0e50d7

$ docker volume rm data
Error response from daemon: remove data: volume is in use - [38eb68e3f9c7020fdb86ded25f1e73dc0a9fdcb932dea1353d04c4474e0e50d7]

$ docker rm -f holder
holder

$ docker volume rm data
data

Algún contenedor (incluidos los detenidos) sigue usando el Volume, así que no se puede eliminar. El ID del mensaje de error es el del contenedor que lo usa. Elimina primero el contenedor y después el Volume.

network ... not found

$ docker run --rm --network appnet alpine:3.23 true
docker: Error response from daemon: failed to set up container networking: network appnet not found

Run 'docker run --help' for more information

La red indicada no existe. Créala con docker network create appnet o comprueba el nombre con docker network ls. Las redes de un proyecto de Compose llevan delante el nombre del proyecto, por ejemplo shop_default.

invalid mount config for type "bind": bind source path does not exist

Ocurre cuando usas --mount type=bind para montar una ruta del host que no existe. La salida real y la diferencia con -v están en Volúmenes y persistencia de datos.

Docker Compose

yaml: ... did not find expected key / mapping values are not allowed

$ docker compose config
go-yaml load error in parser (while parsing a block mapping) at L3.C5-L6.C6: did not find expected key

Hay un error de sangría en el YAML. En este ejemplo, environment: tiene un espacio de sangría de más. El L3.C5-L6.C6 del mensaje de error indica que el problema está en el bloque entre la línea 3, columna 5, y la línea 6, columna 6.

Solución:

  • Usa espacios para la sangría, no tabuladores.
  • Alinea las claves del mismo nivel.
  • Ejecuta docker compose config para revisar el archivo. Si no hay errores, muestra la configuración completa en formato normalizado.

depends on undefined service

$ docker compose up -d
service "app" depends on undefined service "db": invalid compose project

depends_on hace referencia a un servicio que no existe. Normalmente el nombre está mal escrito o el servicio está en un profiles que no se activó.

The "DB_PASSWORD" variable is not set. Defaulting to a blank string.

$ docker compose config
time="2026-10-13T05:27:10Z" level=warning msg="The \"DB_PASSWORD\" variable is not set. Defaulting to a blank string."
name: c3
services:
  db:
    environment:
      POSTGRES_PASSWORD: ""
    image: postgres:18
    networks:
      default: null
networks:
  default:
    name: c3_default

Es una advertencia, no un error, pero puede ser peligrosa: compose.yaml usa ${DB_PASSWORD}, pero la variable no está definida en .env ni en el entorno, así que se sustituye por una cadena vacía. La base de datos podría inicializarse sin contraseña.

Solución: define la variable en .env o escribe ${DB_PASSWORD:?DB_PASSWORD is required} para que se detenga con un error si no está definida. Consulta Variables de entorno y .env.

dependency failed to start: container ... is unhealthy

$ docker compose up -d
[+] up 3/3
 ✔ Network c4_default Created                                                                                                                     0.0s
 ✘ Container c4-db-1  Error dependency db failed to start                                                                                         2.8s
 ✔ Container c4-app-1 Created                                                                                                                     0.0s
dependency failed to start: container c4-db-1 is unhealthy

depends_on tiene condition: service_healthy, pero la comprobación de estado de la dependencia sigue fallando. En este ejemplo, la comprobación ejecuta false a propósito.

Diagnóstico:

  • Ejecuta docker inspect --format "{{json .State.Health}}" contenedor para ver la salida de cada comprobación.
  • Comprueba que el comando de la comprobación es correcto, incluidos la contraseña y el nombre de host. Hay ejemplos de comprobaciones de estado de bases de datos en MySQL y PostgreSQL.
  • Para los servicios que tardan en arrancar, aumenta start_period y retries.

Espacio en disco

No space left on device

$ docker run --rm --tmpfs /data:size=1m alpine:3.23 dd if=/dev/zero of=/data/big bs=1M count=2
dd: error writing '/data/big': No space left on device
2+0 records in
1+0 records out
1048576 bytes (1.0MB) copied, 0.001369 seconds, 730.5MB/s

No queda espacio donde se está escribiendo. Este ejemplo usa un tmpfs de 1 MB para mostrar el problema dentro de un contenedor. En la práctica, la causa más habitual es que se llene el directorio de datos de Docker en el host, lo que puede producir el mismo error al construir o descargar una imagen.

Solución:

  • Ejecuta docker system df para ver qué ocupa espacio y limpia como se explica en Limpiar espacio en disco.
  • Comprueba si los registros de los contenedores son demasiado grandes y limita su tamaño.
  • En Docker Desktop, ve a Settings → Resources y aumenta el límite del disco virtual.

Errores propios de Windows

Los siguientes ejemplos se ejecutaron con PowerShell 7.4. (Para probarlo todo en el mismo entorno, usan la imagen oficial de PowerShell para ejecutar pwsh en un contenedor, por eso cada comando empieza por docker run ... pwsh -Command). En Windows PowerShell 5.1 el texto del error es algo distinto, pero la causa es la misma.

Variable reference is not valid. ':' was not followed by a valid variable name character

$ docker run --rm -e NO_COLOR=1 -w /home/me/project mcr.microsoft.com/powershell:latest pwsh -NoProfile -Command '$PSStyle.OutputRendering="PlainText"; mkdir /home/me/project -Force | Out-Null; Set-Location /home/me/project; Write-Output "$(pwd)/site:/app"; Write-Output "${PWD}/site:/app"'

/home/me/project/site:/app
/home/me/project/site:/app

$ docker run --rm -e NO_COLOR=1 -w /home/me/project mcr.microsoft.com/powershell:latest pwsh -NoProfile -Command '$PSStyle.OutputRendering="PlainText"; Write-Output "$PWD:/app"'
ParserError:
Line |
   1 |  $PSStyle.OutputRendering="PlainText"; Write-Output "$PWD:/app"
     |                                                      ~~~~~
     | Variable reference is not valid. ':' was not followed by a valid
     | variable name character. Consider using ${} to delimit the name.

En PowerShell, "$PWD:/app" da error porque PowerShell interpreta $PWD: como una sintaxis especial de variable. Cámbialo por "${PWD}:/app". La forma "$(pwd)/site:/app" también funciona en PowerShell (el primer comando muestra las mismas dos líneas).

La comparación completa de los comandos de Windows está en Primer contenedor.

The '<' operator is reserved for future use

$ docker run --rm -e NO_COLOR=1 -w /home/me/project mcr.microsoft.com/powershell:latest pwsh -NoProfile -Command '$PSStyle.OutputRendering="PlainText"; docker exec -i mysql mysql app < app.sql'
ParserError:
Line |
   1 |  … OutputRendering="PlainText"; docker exec -i mysql mysql app < app.sql
     |                                                                ~
     | The '<' operator is reserved for future use.

PowerShell no admite usar < para redirigir un archivo a un comando, así que el docker exec -i ... < backup.sql que usan los tutoriales para restaurar una base de datos no funciona en PowerShell.

Solución: copia el archivo al contenedor con docker cp e impórtalo desde dentro del contenedor. Funciona en todos los sistemas y evita el problema de PowerShell 5.1, donde > guarda los archivos en UTF-16. Este es un ejemplo con PostgreSQL:

$ docker compose exec db psql -U app -c 'CREATE TABLE t (id int); INSERT INTO t VALUES (1),(2);'
CREATE TABLE
INSERT 0 2

$ docker compose exec db pg_dump -U app -Fc -f /tmp/app.dump app

$ docker compose cp db:/tmp/app.dump app.dump
 pgwin-db-1 Copying pgwin-db-1:/tmp/app.dump to app.dump
 pgwin-db-1 Copied pgwin-db-1:/tmp/app.dump to app.dump

$ ls -l app.dump
-rw-rw-rw-    1 root     root          1251 Oct 13 05:30 app.dump

$ docker compose exec db psql -U app -c 'DROP TABLE t;'
DROP TABLE

$ docker compose cp app.dump db:/tmp/restore.dump
 pgwin-db-1 Copying app.dump to pgwin-db-1:/tmp/restore.dump
 pgwin-db-1 Copied app.dump to pgwin-db-1:/tmp/restore.dump

$ docker compose exec db pg_restore -U app -d app /tmp/restore.dump

$ docker compose exec db psql -U app -c 'SELECT count(*) FROM t;'
 count
-------
     2
(1 row)

El comando para MySQL está en la sección de copias de seguridad de MySQL.

Resumen

  • Empieza por la palabra clave del final del mensaje de error y después revisa el estado con docker ps -a y docker logs.
  • Cuando un puerto está ocupado o un nombre está repetido, el contenedor fallido puede haberse creado igualmente. Recuerda ejecutar docker rm.
  • En Windows, los scripts necesitan finales de línea LF y permiso de ejecución. Si no, Docker puede mostrar los engañosos errores no such file or directory o permission denied.
  • Para los problemas de Compose, empieza por docker compose config.
  • En PowerShell, usa ${PWD} y evita redirigir archivos con <.

Preguntas frecuentes

El mensaje de error es muy largo. ¿Qué parte debo mirar?

Empieza por el texto que sigue a los últimos dos puntos. Suele ser la causa real, como port is already allocated o no such file or directory. Las partes anteriores, como Error response from daemon y failed to create task, solo indican en qué capa se produjo el error.

¿Por qué el mensaje de error que encuentro en internet es distinto del mío?

Los mensajes de error de Docker cambian entre versiones. Por ejemplo, el antiguo Cannot connect to the Docker daemon at unix:///var/run/docker.sock pasó a ser failed to connect to the docker API at unix:///var/run/docker.sock en Docker 29. Busca por la última palabra clave para encontrar respuestas con más facilidad.

¿Por qué, tras un fallo de docker run, al ejecutarlo de nuevo dice que el nombre ya está en uso?

Con muchos errores (por ejemplo, un puerto ocupado), el contenedor ya se creó, solo que no llegó a arrancar. Lo ves con docker ps -a, en estado Created. Elimínalo con docker rm y vuelve a ejecutar el comando.

¿Cómo sé por qué se detuvo un contenedor?

Ejecuta docker ps -a para ver el código de salida en STATUS, docker logs nombre-del-contenedor para ver la salida del programa y docker inspect -f "{{.State.ExitCode}} {{.State.OOMKilled}}" nombre-del-contenedor. El código 137 indica que se detuvo a la fuerza (SIGKILL o falta de memoria); 1 suele indicar un error del propio programa.

Actualizado 13 de octubre de 2026