How to Fix Docker Permission Denied Error When Running Commands

The error permission denied while trying to connect to the Docker daemon socket means your user doesn’t have permission to talk to Docker. There are also permission issues inside containers and with volumes. Here’s how to fix each.

Error 1: Permission Denied Connecting to 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)

Fix 1: Add Your User to the docker Group

# 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'

Security note: Members of the docker group have effectively root access (Docker can mount the host filesystem). Only add trusted users, and consider rootless Docker for better security.

Fix 2: Rootless Docker (More Secure)

# 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

Error 2: Permission Denied Inside a Container

# 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

Error 3: Volume Mount Permission Issues

# 🐛 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 "$@"

Error 4: Docker Compose Permission Issues

# 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

Diagnosing Permission Problems

# 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

Frequently Asked Questions

Q: Why do I need to log out after adding myself to the docker group?
A: Group membership is loaded at login. After usermod -aG docker $USER, your current session doesn’t have the new group yet. Log out and back in, or run newgrp docker to apply it in the current shell.

Q: Is adding my user to the docker group safe?
A: It grants effectively root-level access (Docker can mount host paths as root). It’s convenient but a security consideration — only add trusted users. For better security, use rootless Docker, which runs the daemon as your user.

Q: Why are files created by my container owned by root?
A: By default, containers run as root, so files they create on mounted volumes are root-owned. Run the container as your user with -u $(id -u):$(id -g), or define a non-root USER in the Dockerfile.

Q: Should I use sudo with docker?
A: Avoid it — prefixing every command with sudo is inconvenient and can create root-owned files. Fix the underlying issue by adding your user to the docker group (or using rootless Docker) so docker commands work without sudo.

Q: How do I avoid volume permission issues entirely?
A: Run containers as a non-root user matching your host user (-u $(id -u):$(id -g)), define a USER in your Dockerfile, and handle ownership in an entrypoint script. Consistent user IDs between host and container prevent most problems.

Conclusion

Docker permission errors come in a few flavors. The classic “permission denied connecting to the daemon socket” is fixed by adding your user to the docker group (sudo usermod -aG docker $USER) and logging out/in — or better, using rootless Docker for improved security. Permission issues inside containers and with volumes come from containers running as root: fix them by running containers as your user (-u $(id -u):$(id -g)) or defining a non-root USER in your Dockerfile. Understanding that the Docker socket is root-owned and containers default to root explains nearly every Docker permission problem.