Como Corrigir o Erro “OCI runtime create failed” do Docker [Guia Atualizado 2026]

Você já encontrou o erro “Error response from daemon: OCI runtime create failed” ao tentar iniciar um container Docker? Este erro indica que o runtime de baixo nível do Docker (runc) falhou ao iniciar o container. Neste artigo, explicaremos detalhadamente as causas e soluções específicas para este erro com base nas informações mais recentes de 2026.

O que é este erro? Sintomas que você pode experimentar
Causas deste erro
Solução 1: Verificar executáveis e caminhos (Recomendado)
Solução 2: Tratando problemas de SELinux/AppArmor
Solução 3: Atualização do Docker/runc e mudanças de configuração (Avançado)
Como prevenir este erro
Resumo
Referências

O que é este erro? Sintomas que você pode experimentar

O erro “OCI runtime create failed” ocorre quando o Docker tenta criar e iniciar um container usando um runtime compatível com OCI (Open Container Initiative). OCI é uma organização que define padrões da indústria para formatos de container e runtimes, e o Docker usa o runc, que está em conformidade com esses padrões, para gerenciar containers.

Quando este erro ocorre, você pode experimentar os seguintes sintomas:

Containers não iniciam com o comando docker run
Serviços falham ao iniciar com docker-compose up
Logs do container exibem a mensagem “OCI runtime create failed”
Mensagens de erro como “runc create failed: unable to start container process” aparecem

O formato da mensagem de erro geralmente se parece com isso:

Error response from daemon: OCI runtime create failed: container_linux.go:380: starting container process caused: exec: "python": executable file not found in $PATH: unknown

Este erro pode ocorrer em qualquer ambiente Docker, incluindo ambientes de desenvolvimento, pipelines de CI/CD e ambientes de produção, impactando significativamente o desenvolvimento e implantação de aplicações baseadas em containers.

Causas deste erro

Existem múltiplas causas potenciais para o erro OCI runtime create failed. A dica chave está contida na parte após “caused:” na mensagem de erro, então é importante verificar a mensagem de erro completa primeiro.

Causa 1: Executável não encontrado

Uma das causas mais comuns é que o executável ou comando especificado não existe dentro do container. Este erro ocorre quando o comando especificado no ENTRYPOINT ou CMD do Dockerfile não existe na imagem do container.

Por exemplo, se você tentar executar o comando python em uma imagem base que não tem Python instalado, você verá o seguinte erro:

exec: "python": executable file not found in $PATH

Isso ocorre frequentemente ao usar imagens leves como Alpine Linux.

Causa 2: Controle de acesso SELinux/AppArmor

Este erro também pode ocorrer quando módulos de segurança como SELinux (Security-Enhanced Linux) ou AppArmor bloqueiam processos do container ou operações de montagem. Isso é particularmente problemático nas seguintes situações:

Ao montar diretórios do host como volumes
Ao acessar arquivos de dispositivo específicos
Ao executar containers que requerem operações privilegiadas

Em ambientes com SELinux habilitado, você pode ver mensagens de erro como:

write /proc/self/attr/keycreate: permission denied

Causa 3: Problemas com script de entrypoint

Erros também podem ocorrer quando há problemas com arquivos de script como entrypoint.sh especificados no Dockerfile. As causas principais incluem:

Arquivo não copiado para a imagem
Caminho do arquivo incorreto
Permissão de execução não concedida
Finais de linha (CRLF) de scripts criados no Windows não reconhecidos no Linux

Causa 4: Problemas de versão do Docker ou runc

Este erro pode ocorrer quando as versões do Docker ou runc são incompatíveis com o kernel do SO host. Problemas têm sido particularmente relatados após atualizações no Proxmox VE e outros ambientes de virtualização. Muitos casos são resolvidos atualizando para Docker 25 ou superior.

Causa 5: Problemas de configuração do cgroup

Erros também ocorrem quando a configuração do cgroup (Control Groups) do container é incompatível com o sistema host. Este problema é frequentemente relatado, especialmente durante o período de transição do cgroupsv1 para cgroupsv2.

Solução 1: Verificar executáveis e caminhos (Recomendado)

A solução mais eficaz para tentar primeiro é verificar os executáveis e caminhos dentro do container.

Passo 1: Verificar o conteúdo da imagem

Primeiro, verifique se os comandos necessários existem na imagem problemática:

# Verificar o sistema de arquivos na imagem
docker run --rm --entrypoint ls myapp:latest /usr/bin/

# Verificar se um comando específico existe
docker run --rm --entrypoint which myapp:latest python

Passo 2: Modificar o Dockerfile

Se o executável não existe, modifique o Dockerfile para instalar os pacotes necessários:

# Para Alpine Linux
FROM alpine:latest
RUN apk add --no-cache python3 py3-pip

# Para Debian/Ubuntu
FROM ubuntu:22.04
RUN apt-get update && apt-get install -y python3 python3-pip

Passo 3: Verificar ENTRYPOINT e CMD

Verifique se ENTRYPOINT e CMD estão corretamente configurados no Dockerfile:

# Exemplo correto
ENTRYPOINT ["/app/entrypoint.sh"]
CMD ["python3", "app.py"]

# Usar caminhos absolutos é recomendado
ENTRYPOINT ["/usr/local/bin/python3"]

Notas importantes

Ao usar scripts de shell, sempre conceda permissões de execução: RUN chmod +x /app/entrypoint.sh
Para scripts criados no Windows, converta os finais de linha usando o comando dos2unix ou trate isso dentro do Dockerfile

Solução 2: Tratando problemas de SELinux/AppArmor

Aqui está como tratar erros causados pelo SELinux ou AppArmor.

Verificar o status do SELinux

# Verificar status do SELinux
sestatus

# Verificar logs recentes de negação do SELinux
ausearch -m avc -ts recent

Configuração de labels para montagem de volumes

Ao montar volumes em ambientes SELinux, configure os labels apropriados:

# Opção :z (para volumes compartilhados)
docker run -v /host/path:/container/path:z myapp:latest

# Opção :Z (para volumes privados)
docker run -v /host/path:/container/path:Z myapp:latest

Configuração de labels persistentes

Para diretórios de uso frequente, você pode configurar labels SELinux persistentes:

# Configurar contexto SELinux para containers
chcon -Rt svirt_sandbox_file_t /path/to/volume

Desabilitar labels SELinux para testes

Para fins de troubleshooting, você pode desabilitar temporariamente os labels SELinux:

docker run --security-opt label=disable myapp:latest

Importante: Desabilitar permanentemente o SELinux não é recomendado em ambientes de produção. Configure políticas apropriadas após entender completamente os riscos de segurança.

Solução 3: Atualização do Docker/runc e mudanças de configuração (Avançado)

Soluções para problemas de versão ou quando configuração avançada é necessária.

Atualizar o Docker

Se você está usando uma versão antiga do Docker, atualize para a versão mais recente:

# Para Ubuntu/Debian
sudo apt-get update
sudo apt-get install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

# Para CentOS/RHEL
sudo yum update docker-ce docker-ce-cli containerd.io

Verificar e atualizar a versão do runc

# Verificar versão do runc
runc --version

# Atualizar runc separadamente se necessário
sudo apt-get install runc

Modificar a configuração do systemd

Em alguns ambientes, você pode precisar modificar a configuração do systemd do Docker:

# Editar arquivo de serviço do Docker
sudo systemctl edit docker.service

# Adicionar a seguinte configuração (resolve problemas de MountFlags)
[Service]
MountFlags=shared

# Aplicar mudanças
sudo systemctl daemon-reload
sudo systemctl restart docker

Configurar o driver do cgroup

Se houver problemas de compatibilidade do driver do cgroup, modifique a configuração do daemon do Docker:

# Editar /etc/docker/daemon.json
sudo nano /etc/docker/daemon.json

Adicione o seguinte conteúdo:

{
  "exec-opts": ["native.cgroupdriver=systemd"],
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "100m"
  },
  "storage-driver": "overlay2"
}

Após a configuração, reinicie o Docker:

sudo systemctl restart docker

Como prevenir este erro

Aqui estão as melhores práticas para prevenir erros de OCI runtime create failed.

Melhores práticas de Dockerfile

Use imagens base confiáveis: Use imagens oficiais ou verificadas e garanta que contenham as dependências necessárias.
Utilize builds de múltiplos estágios: Evite incluir ferramentas ou arquivos desnecessários na imagem final.
Configure explicitamente permissões de execução: Sempre execute chmod +x em arquivos de script.
Use caminhos absolutos: Use caminhos absolutos em vez de relativos em ENTRYPOINT e CMD.

Manutenção regular

Mantenha Docker e runc atualizados: Realize atualizações regulares para patches de segurança e melhorias de compatibilidade.
Remova imagens e containers não utilizados: Execute docker system prune regularmente para liberar espaço em disco.
Monitore os logs: Verifique regularmente os logs do sistema Docker com journalctl -u docker.

Testes pré-implantação

Sempre verifique se os containers iniciam corretamente em ambientes locais ou de staging antes de implantar em produção. Também é eficaz incorporar testes de inicialização de containers no seu pipeline de CI/CD.

Resumo

O erro “OCI runtime create failed” do Docker é um erro comum que indica que o runtime do container não conseguiu iniciar o container. As causas principais incluem executáveis ausentes, controle de acesso SELinux/AppArmor, erros de configuração de entrypoint, problemas de versão do Docker/runc e inconsistências na configuração do cgroup.

Ao fazer troubleshooting, é importante verificar primeiro a parte após “caused:” na mensagem de erro para identificar a causa específica. Em muitos casos, o problema pode ser resolvido modificando o Dockerfile ou adicionando opções de montagem de volume.

Se o problema persistir, tente os seguintes passos:

Verifique informações de erro mais detalhadas com docker logs ou journalctl
Pesquise problemas similares nos fóruns oficiais do Docker ou Stack Overflow
Considere atualizar sua versão do Docker
Verifique a compatibilidade entre o kernel do SO host e o Docker

A tecnologia de containers evolui diariamente, e muitos problemas são resolvidos em versões mais novas. Mantenha um ambiente de containers estável através de atualizações regulares e gerenciamento adequado de configuração.