Como corrigir erro de permissão negada do Docker ao executar comandos

O erropermissão negada ao tentar conectar-se ao soquete daemon do Docker significa que seu usuário não tem permissão para conversar com o Docker. Também existem problemas de permissão dentro de contêineres e volumes. Veja como consertar cada um.

Erro 1: Permissão negada ao conectar-se ao Docker Daemon

# The error
docker ps
# Got permission denied while trying to connect to the Docker daemon
# socket at unix:///var/run/docker.sock

# Cause: your user isn't in the 'docker' group, so it can't
# access the Docker socket (which is root-owned)

Correção 1: adicione seu usuário ao grupo docker

# Add your user to the docker group
sudo usermod -aG docker $USER

# Apply the change - log out and back in, OR:
newgrp docker

# Verify
docker ps   # should work now without sudo

# Check group membership
groups   # should include 'docker'

Nota de segurança: Os membros do grupo docker têm efetivamente acesso root (o Docker pode montar o sistema de arquivos host). Adicione apenas usuários confiáveis e considere o Docker sem root para melhor segurança.

Correção 2: Docker sem root (mais seguro)

# Rootless Docker runs the daemon as your user, avoiding the group issue
dockerd-rootless-setuptool.sh install

# Set the socket for your user
export DOCKER_HOST=unix:///run/user/$(id -u)/docker.sock

# Add to your shell config to persist
echo 'export DOCKER_HOST=unix:///run/user/$(id -u)/docker.sock' >> ~/.bashrc

Erro 2: permissão negada dentro de um contêiner

# Files created by a root-running container are owned by root,
# causing permission issues on mounted volumes

# 🐛 Container runs as root, creates root-owned files in your volume
docker run -v $(pwd):/app myimage
# Files in ./app are now owned by root - you can't edit them

# ✅ Run the container as your user
docker run -u $(id -u):$(id -g) -v $(pwd):/app myimage

# ✅ Or set a non-root user in the Dockerfile
FROM node:20-alpine
RUN adduser -D appuser
USER appuser

Erro 3: Problemas de permissão de montagem de volume

# 🐛 Container can't write to a mounted volume

# ✅ Match the container user to the host file owner
docker run -u $(id -u):$(id -g) -v $(pwd)/data:/data myimage

# ✅ Or fix ownership on the host
sudo chown -R $(id -u):$(id -g) ./data

# ✅ For named volumes, initialize permissions in an entrypoint
# entrypoint.sh
chown -R appuser:appuser /data
exec "$@"

Erro 4: Problemas de permissão do Docker Compose

# docker-compose.yml - set the user for a service
services:
  app:
    image: myimage
    user: "${UID}:${GID}"   # pass host user/group
    volumes:
      - ./app:/app

# Run with your IDs
UID=$(id -u) GID=$(id -g) docker compose up

Diagnosticando problemas de permissão

# Check who owns the Docker socket
ls -l /var/run/docker.sock
# srw-rw---- 1 root docker ... /var/run/docker.sock
# Owned by root:docker - you need to be in the docker group

# Check the docker service is running
sudo systemctl status docker

# Inside a container, check what user you're running as
docker run myimage whoami

Perguntas Frequentes

P: Por que preciso sair depois de me adicionar ao grupo docker?
R: A associação ao grupo é carregada no login. Depoisusermod -aG docker $USER, sua sessão atual ainda não possui o novo grupo. Saia e entre novamente ou executenewgrp docker para aplicá-lo no shell atual.

P: Adicionar meu usuário ao grupo docker é seguro?
R: Ele concede efetivamente acesso no nível raiz (o Docker pode montar caminhos de host como raiz). É conveniente, mas é uma consideração de segurança – adicione apenas usuários confiáveis. Para melhor segurança, use o Docker sem root, que executa o daemon como seu usuário.

P: Por que os arquivos criados pelo meu contêiner são de propriedade do root?
R: Por padrão, os contêineres são executados como root, portanto, os arquivos criados em volumes montados são de propriedade do root. Execute o contêiner como seu usuário com-u $(id -u):$(id -g)ou defina um USUÁRIO não root no Dockerfile.

P: Devo usar o sudo com o docker?
R: Evite isso – prefixar cada comando com sudo é inconveniente e pode criar arquivos de propriedade do root. Corrija o problema subjacente adicionando seu usuário ao grupo docker (ou usando o Docker sem root) para que os comandos do docker funcionem sem sudo.

P: Como evito totalmente problemas de permissão de volume?
R: Execute contêineres como um usuário não root correspondente ao seu usuário host (-u $(id -u):$(id -g)), defina um USER em seu Dockerfile e administre a propriedade em um script de ponto de entrada. IDs de usuário consistentes entre host e contêiner evitam a maioria dos problemas.

Conclusão

Os erros de permissão do Docker vêm em alguns tipos. A clássica “permissão negada para conexão ao soquete daemon” é corrigida poradicionando seu usuário ao grupo docker (sudo usermod -aG docker $USER) e efetuando logout/entrada — ou melhor, usando Docker sem root para maior segurança. Problemas de permissão dentro de contêineres e com volumes vêm de contêineres executados como root: corrija-osexecutando contêineres como seu usuário (-u $(id -u):$(id -g)) ou definindo um USUÁRIO não root em seu Dockerfile. Entender que o soquete do Docker é de propriedade do root e que os contêineres são padronizados como root explica quase todos os problemas de permissão do Docker.