Conteúdo

Guia de mensagens de erro comuns do Docker: causas e soluções (com saída real)

Esta página reúne mensagens de erro comuns do Docker. O título de cada seção é a palavra-chave da mensagem de erro, então você pode usar a busca do navegador (Ctrl+F) para encontrá-la diretamente. Cada erro inclui uma saída reproduzida no Docker 29, sua causa e a solução.

Se você não encontrar seu erro, siga estes passos básicos para investigá-lo:

  1. Observe a palavra-chave no trecho final da mensagem de erro.
  2. Execute docker ps -a para ver o estado do contêiner e o código de saída.
  3. Execute docker logs nome-do-contêiner para ver a saída do próprio programa.
  4. Consulte métodos detalhados de depuração em Como visualizar logs e depurar.

Conexão e permissões

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

A mensagem antiga era Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?. O significado é o mesmo: o comando docker (cliente) não consegue encontrar o Docker Engine (servidor).

Solução:

  • Windows / macOS: confirme se o Docker Desktop está em execução. O ícone de baleia na bandeja do sistema deve parar de girar e o status deve ser Engine running.
  • Linux: inicie o serviço do Docker com sudo systemctl start docker e configure-o para iniciar com o sistema usando sudo systemctl enable docker.
  • Verifique se a variável de ambiente DOCKER_HOST está configurada ou se você mudou para outro 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

No Linux, somente o root e o grupo docker podem acessar /var/run/docker.sock. Esse erro aparece quando um usuário comum executa docker.

Solução: adicione o usuário ao grupo docker e, em seguida, faça login novamente (ou execute newgrp docker) para que a alteração entre em vigor:

sudo usermod -aG docker $USER

Adicionar alguém ao grupo docker equivale a conceder privilégios de root. Veja o motivo em Práticas recomendadas de segurança. Para evitar isso, você pode usar o modo Rootless.

Portas e nomes

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

A porta 8080 do host já está sendo usada por outro contêiner (neste caso, web1). Atenção: quando o erro ocorre, o web2 já foi criado, mas não foi iniciado (o estado é Created). Por isso, se você corrigir o problema e executar o mesmo comando novamente, encontrará o próximo erro: “o nome já está em uso”.

Solução:

  • Escolha outra porta do host: -p 8081:80.
  • Ou pare o contêiner que está usando a porta: execute docker ps para descobrir quem está usando a 8080 e, em seguida, docker stop.
  • Remova o contêiner cuja criação falhou: 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

É parecido com o erro anterior, mas quem está usando a porta é outro programa no host (não um contêiner), como uma instalação local do Nginx ou MySQL, ou um servidor de desenvolvimento em execução.

Solução: descubra qual programa está usando a porta e feche-o, ou escolha outra porta.

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

O nome do contêiner "/web1" já está em uso

$ 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

Os nomes dos contêineres não podem se repetir, inclusive os de contêineres parados.

Solução:

  • Remova o contêiner antigo: docker rm -f web1.
  • Ou escolha outro nome.
  • Para contêineres de uso único, adicione --rm; eles serão removidos automaticamente ao terminar e não deixarão um contêiner com o mesmo nome.

Imagens

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

Imagem não encontrada. Causas comuns:

  • Tag incorreta ou inexistente: a versão nginx:9.99 não existe. Confira a página Tags no Docker Hub ou consulte com docker buildx imagetools inspect imagem.
  • Nome incorreto: ngnix. Os nomes das imagens oficiais não têm prefixo, por exemplo nginx e postgres.
  • Você não fez login para acessar uma imagem privada: primeiro execute docker login.

Dependendo da versão do Docker e do Registry, o mesmo problema também pode aparecer como manifest unknown ou 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

Os nomes de imagem só podem usar letras minúsculas, números e -, _, . e /. Altere MyApp para myapp. Se o nome tiver espaços ou dois-pontos extras (por exemplo, myapp::1.0), será exibido invalid reference format.

toomanyrequests: You have reached your pull rate limit

Há um limite para baixar imagens do Docker Hub sem fazer login. Você pode atingir esse limite ao fazer muitos downloads em pouco tempo (por exemplo, quando o CI baixa tudo novamente a cada execução). Não foi possível reproduzir esse erro neste ambiente de tutorial; a mensagem de erro segue a documentação oficial.

Solução:

  • Faça login na sua conta do Docker Hub com docker login para aumentar o limite.
  • Use cache no CI ou imagens espelhadas de outro Registry.
  • Não é necessário baixar novamente imagens que já estão na máquina local. Evite adicionar --pull always ao comando sem necessidade.

exec format error

A arquitetura da CPU da imagem é diferente da do host, por exemplo, quando você executa em um servidor amd64 uma imagem arm64 criada em um Mac com Apple Silicon. Veja a saída real e as soluções em Imagens multiplataforma.

Falha ao iniciar o contêiner

exec /entrypoint.sh: no such file or directory (o arquivo está claramente presente)

O caso mais comum ocorre com usuários do Windows: o script de shell foi salvo com as quebras de linha do 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 mostra que a primeira linha termina com \r \n. O Linux lê o interpretador como /bin/sh\r (com um \r invisível a mais). Como esse programa não existe, aparece o erro no such file or directory, que é bem enganoso.

Solução:

  • No editor, altere a quebra de linha para LF (no canto inferior direito do VS Code, clique em CRLF e mude para LF).

  • O Git converte as quebras de linha para CRLF por padrão no Windows. Adicione .gitattributes à raiz do projeto para que os scripts usem sempre LF:

    *.sh text eol=lf
  • Ou converta no 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

O script não tem permissão de execução. O sistema de arquivos do Windows não tem permissões de execução do Linux, então esse problema é especialmente comum ao fazer o build no Windows.

Solução: adicione a permissão de execução no Dockerfile:

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

Ou execute chmod +x entrypoint.sh no Linux / macOS antes de fazer o build.

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

Esse programa não está no contêiner. A imagem alpine não tem bash, apenas sh.

Solução: use sh ou instale bash no Dockerfile (RUN apk add --no-cache bash). Isso também acontece com frequência quando o nome do programa em CMD está incorreto ou quando o programa não foi copiado para a imagem.

O contêiner é encerrado logo após iniciar (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

Isso não é um erro: o contêiner para quando o processo principal termina. O comando padrão da imagem ubuntu é bash. Quando executado em segundo plano (-d) sem um terminal, o bash termina porque não consegue ler a entrada.

Solução:

  • Para entrar e operar: docker run -it ubuntu:26.04 bash.
  • Para mantê-lo em execução: forneça um programa que não termine, como um servidor web; para testes, você pode usar sleep infinity.
  • Se o código de saída não for 0, procure a mensagem de erro do programa em docker logs.

Exited (137) ou OOMKilled

O código de saída 137 significa que o contêiner foi encerrado à força por SIGKILL (128 + 9). Causas comuns:

  • Memória insuficiente: o limite de --memory foi ultrapassado ou não havia memória suficiente no host, e o sistema encerrou o processo. Confirme com docker inspect -f "{{.State.OOMKilled}}" contêiner; se o resultado for true, significa que faltou memória.
  • O programa não terminou depois de 10 segundos aguardando docker stop e foi encerrado à força. Veja os testes com PID 1 em Aplicação Node.js.
  • docker kill ou docker rm -f.

O host de teste deste tutorial não tem o limite de swap habilitado. Por isso, não é possível reproduzir de forma consistente a falta de memória, e não incluímos uma saída real para esse caso.

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 solicita um terminal, mas a entrada atual não é um terminal. Isso costuma acontecer quando você usa docker exec -it em scripts, CI ou cron, ou envia um arquivo ao contêiner usando < ou |.

Solução: em situações não interativas, remova -t e mantenha apenas -i (quando precisar enviar entrada) ou não use nenhuma das opções. Por exemplo, para restaurar um banco de dados, use docker exec -i.

Build (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

A pasta atual não contém um Dockerfile.

Solução:

  • Confirme que você está executando o comando na pasta correta. O . no final indica o caminho do contexto de build.
  • O nome do arquivo deve ser Dockerfile (com as mesmas letras maiúsculas e minúsculas e sem extensão). O Bloco de Notas do Windows pode adicionar .txt automaticamente, transformando o nome em Dockerfile.txt.
  • Se o arquivo tiver outro nome, especifique-o com -f: docker build -f Dockerfile.dev ..

failed to calculate checksum ... not found (COPY não encontra o arquivo)

$ 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

O arquivo usado em COPY não está no contexto de build. O WARN: CopyIgnoredFile no início já explica o motivo: config.json foi excluído pelo .dockerignore.

Causas comuns:

  • O arquivo foi excluído pelo .dockerignore (o Docker 29 exibe um aviso antes).
  • O caminho está errado ou o arquivo está fora do contexto de build (o . no final de docker build). COPY ../file não pode acessar a pasta pai.
  • Há diferença entre letras maiúsculas e minúsculas: Windows e macOS não diferenciam maiúsculas de minúsculas; Linux diferencia.

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

Um comando RUN falhou durante o build. Consulte a saída entre ------; ela contém a mensagem de erro do próprio comando. Por exemplo, em aplicações Python, o collectstatic do Django falha quando STATIC_ROOT não está configurado. Se a saída completa não estiver visível, adicione --progress plain.

Volume, rede

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

O Volume ainda está sendo usado por um contêiner (incluindo contêineres parados), então não pode ser removido. O ID na mensagem de erro identifica o contêiner que o está usando. Remova o contêiner primeiro e, em seguida, o 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

A rede especificada não existe. Crie-a com docker network create appnet ou confirme o nome com docker network ls. Os nomes das redes de projetos Compose recebem o prefixo do nome do projeto, por exemplo, shop_default.

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

Isso acontece quando você monta um caminho inexistente do host usando --mount type=bind. Veja a diferença na saída real entre -v e essa opção em Volumes e persistência de dados.

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

Há um erro de indentação no YAML. Neste exemplo, environment: está indentado um espaço a mais. L3.C5-L6.C6 na mensagem de erro indica que há um problema no bloco entre a linha 3, coluna 5 e a linha 6, coluna 6.

Solução:

  • Use apenas espaços para indentar; não use Tab.
  • Alinhe as chaves no mesmo nível.
  • Verifique com docker compose config. Se não houver erros, o comando exibirá a configuração completa formatada.

depends on undefined service

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

depends_on referencia um nome de serviço inexistente. Geralmente, isso acontece por um erro de digitação ou porque o serviço foi colocado em profiles sem que o perfil tenha sido ativado.

A variável "DB_PASSWORD" não está definida. Usando uma string vazia como padrão.

$ 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

Isso é um aviso, não um erro, mas é perigoso: compose.yaml usa ${DB_PASSWORD}, mas a variável não foi definida em .env nem nas variáveis de ambiente. Assim, ela é substituída por uma string vazia, e o banco de dados pode ser inicializado sem senha.

Solução: defina a variável em .env ou escreva ${DB_PASSWORD:?DB_PASSWORD is required} para interromper com um erro caso ela não esteja definida. Consulte Variáveis de ambiente e arquivo .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 define condition: service_healthy, mas a verificação de integridade do serviço do qual há dependência está falhando continuamente. Neste exemplo, a verificação de integridade executa false de propósito.

Diagnóstico:

  • Use docker inspect --format "{{json .State.Health}}" contêiner para ver a saída de cada verificação de integridade.
  • Confira se o próprio comando de verificação está correto, por exemplo, a senha e o nome do host. Veja como configurar a verificação de integridade do banco de dados em MySQL e PostgreSQL.
  • Para serviços que demoram a iniciar, aumente start_period e retries.

Espaço em 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

Não há espaço suficiente no local de gravação. Este exemplo usa um tmpfs de 1 MB para demonstrar a situação dentro do contêiner; na prática, é mais comum o diretório de dados do Docker no host ficar cheio, causando o mesmo erro durante a criação ou o download de imagens.

Solução:

  • Execute docker system df para ver o que está ocupando espaço e faça a limpeza conforme Liberar espaço em disco.
  • Confira se os logs dos contêineres estão grandes demais e defina um limite para eles.
  • No Docker Desktop, aumente o limite do disco virtual em Settings → Resources.

Erros específicos do Windows

Os comandos abaixo foram executados com PowerShell 7.4 (para testar no mesmo ambiente, usamos a imagem oficial do PowerShell em um contêiner para executar pwsh; por isso, os comandos começam com docker run ... pwsh -Command). As mensagens do Windows PowerShell 5.1 são um pouco diferentes, mas as causas são as mesmas.

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.

No PowerShell, escrever "$PWD:/app" causa um erro: o PowerShell interpreta $PWD: como uma sintaxe especial de variável. Se você mudar para "${PWD}:/app", funciona. A forma "$(pwd)/site:/app" também funciona no PowerShell (as duas linhas de saída do primeiro comando são iguais).

Veja a comparação completa dos comandos para Windows em Seu primeiro contêiner.

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.

O PowerShell não dá suporte ao uso de < para redirecionar um arquivo para um comando. Por isso, o comando docker exec -i ... < backup.sql da seção do tutorial sobre restauração do banco de dados não funciona no PowerShell.

Solução: primeiro, use docker cp para copiar o arquivo para o contêiner; em seguida, importe-o dentro do contêiner. Esse método funciona em todos os sistemas e também evita o problema do PowerShell 5.1 salvar arquivos com codificação UTF-16 ao usar >. Veja o exemplo com 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)

Veja como fazer no MySQL na seção de backup de MySQL.

Resumo

  • Primeiro, confira as palavras-chave no fim da mensagem de erro e, em seguida, use docker ps -a e docker logs para verificar o estado.
  • Quando uma porta estiver ocupada ou houver conflito de nomes, o contêiner que falhou pode já ter sido criado. Lembre-se de executar docker rm.
  • No Windows, os scripts devem usar quebras de linha LF e ter permissão de execução. Caso contrário, você pode ver mensagens enganosas como no such file or directory ou permission denied.
  • Para problemas com Compose, execute primeiro docker compose config.
  • No PowerShell, use ${PWD} e evite usar < para redirecionar arquivos.

Perguntas frequentes

A mensagem de erro é muito longa. Qual parte devo observar?

Comece pelo texto depois do último sinal de dois-pontos; geralmente é a causa real, como port is already allocated ou no such file or directory. As partes anteriores, como Error response from daemon e failed to create task, apenas indicam em que camada o erro ocorreu.

Por que a mensagem de erro que encontro na internet é diferente da que aparece para mim?

As mensagens de erro do Docker mudam entre versões. Por exemplo, a mensagem antiga Cannot connect to the Docker daemon at unix:///var/run/docker.sock virou failed to connect to the docker API at unix:///var/run/docker.sock no Docker 29. Pesquisar pela palavra-chave final costuma facilitar encontrar a resposta.

Por que, depois que docker run falha, recebo um erro de nome já em uso quando executo o comando novamente?

Quando muitos erros acontecem (por exemplo, uma porta ocupada), o contêiner já foi criado, mas não conseguiu iniciar. Você pode vê-lo com docker ps -a, no estado Created. Primeiro, remova-o com docker rm e execute o comando novamente.

Como descubro por que um contêiner foi encerrado?

Execute, nesta ordem: docker ps -a para ver o código de saída em STATUS, docker logs nome-do-contêiner para ver a saída do programa e docker inspect -f "{{.State.ExitCode}} {{.State.OOMKilled}}" nome-do-contêiner. O código de saída 137 indica encerramento forçado (SIGKILL ou falta de memória); 1 geralmente indica um erro no próprio programa.

Atualizado 13 de outubro de 2026