TechEarl

Cannot Connect to the Docker Daemon — Fix the Permission and Socket Errors

Two errors that mean the same thing: the daemon isn't running, or you don't have permission to talk to its socket. How to start the daemon, add yourself to the docker group, refresh the group without rebooting, and handle the rootless case.

Ishan KarunaratneIshan Karunaratne⏱️ 7 min readUpdated
Share thisCopied

The classic Docker error on a fresh Linux install:

code
Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?

Or its cousin:

code
permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock

Both mean one of two things: the Docker daemon isn't running, or your user doesn't have permission to talk to its socket. This article covers both, in the order to check them.

Fast diagnosis

bash
# 1. Is the daemon running?
sudo systemctl status docker

# 2. Do I have permission to its socket?
ls -la /var/run/docker.sock

If systemctl status docker says "inactive (dead)," start it. If the socket is owned by root:docker and you're not in the docker group, add yourself.

Fix 1: Start the Docker daemon

On a fresh Linux install, Docker is sometimes installed but not running:

bash
sudo systemctl start docker

# Confirm
sudo systemctl status docker

# Enable on boot
sudo systemctl enable docker

If start fails, the daemon logs are the next stop:

bash
sudo journalctl -u docker -n 50 --no-pager

Common failure reasons:

  • Storage driver conflict. Docker switched between storage drivers (e.g., overlay2 to btrfs) and the existing /var/lib/docker data isn't compatible. Fix: clean install, or back up and wipe /var/lib/docker.
  • /var/run/docker.sock already in use. Another Docker (rootless, an old install) is running. Stop it: sudo pkill dockerd, or systemctl stop docker.service docker.socket.
  • iptables rules conflicting. Some firewall setups (firewalld with cgroup v2 quirks, certain SELinux configs) block Docker's iptables setup. The journalctl output will mention the specific module.

On Docker Desktop (Mac/Windows), the daemon runs inside Docker Desktop. If you see this error there, Docker Desktop isn't running — open the app.

Fix 2: Permission denied on the socket

The daemon is running, but you get:

code
permission denied while trying to connect to the Docker daemon socket

That's the socket permissions. By default /var/run/docker.sock is owned by root:docker with mode 660 — root can read/write, the docker group can read/write, anyone else gets denied.

Add your user to the docker group:

bash
sudo usermod -aG docker $USER

That changes membership but the change doesn't apply to your current shell session. Group membership is set at login. You need a fresh session.

Three ways to get a fresh session:

  1. Log out and back in. Cleanest.
  2. newgrp docker — starts a sub-shell with the new group membership.
  3. Reboot. Works but excessive.
bash
newgrp docker
docker version          # should work now

After re-login, the membership is permanent.

Security note: being in the docker group is functionally equivalent to root. The Docker daemon runs as root, and via the socket you can mount the host filesystem into a container and escape. That's fine on a personal workstation; do not casually add users on a multi-user server.

Fix 3: Rootless Docker

Rootless Docker runs the daemon as your user, not root. The socket path is different:

code
$XDG_RUNTIME_DIR/docker.sock

Which on most systems is:

code
/run/user/$(id -u)/docker.sock

If you see "cannot connect" with rootless, check that the env var is set so the CLI knows where to look:

bash
export DOCKER_HOST="unix:///run/user/$(id -u)/docker.sock"

Add to your shell's startup file (~/.bashrc, ~/.zshrc) so it persists.

Rootless daemons are managed with systemctl --user:

bash
systemctl --user status docker
systemctl --user start docker
systemctl --user enable docker

On Mac and Windows

Docker Desktop on Mac and Windows hides all of this. The CLI inside Docker Desktop is wired to the Desktop's daemon automatically. If you see "cannot connect" on Docker Desktop:

  • Docker Desktop isn't running. Open it; wait for the whale icon to settle.
  • Stale CLI configuration (rare). Quit Docker Desktop fully, restart it.
  • You're in a WSL2 distro and Docker Desktop integration is disabled for that distro. Open Docker Desktop → Settings → Resources → WSL Integration, and enable for your distro.

Quick troubleshooting checklist

If you're stuck, run through this in order:

bash
# 1. Is the daemon running?
sudo systemctl status docker        # Linux
                                     # On Mac/Windows: check Docker Desktop is open

# 2. What's the socket's permission?
ls -la /var/run/docker.sock

# 3. Am I in the docker group?
groups | grep docker

# 4. If the group membership is recent, get a fresh shell
newgrp docker

# 5. Does sudo docker work? (sanity check)
sudo docker version

# 6. Anything in the daemon log?
sudo journalctl -u docker -n 30 --no-pager

If sudo docker version works but docker version doesn't, it's definitely a group / socket permission issue. If neither works, the daemon is the problem.

Other variants of this error

  • "Cannot connect to the Docker daemon at tcp://..." — the CLI is configured to use a remote daemon (probably via DOCKER_HOST env var) that isn't reachable. Unset DOCKER_HOST or fix the connection.
  • "Got permission denied" inside CI — your CI runner is running Docker as a different user. Either run with sudo, ensure the runner user is in the docker group, or use rootless.
  • "http: server gave HTTP response to HTTPS client" — almost always pointing at an HTTPS-expecting DOCKER_HOST setting (e.g., for Docker Swarm) when the daemon only speaks HTTP. Mismatch between client and server TLS config.

Common pitfalls

  • Adding yourself to docker group and expecting it to work in the same shell. Doesn't. Log out / log back in, or newgrp docker.
  • sudo docker masking the underlying group issue. It works because root doesn't need group membership. But you've made sudo part of your workflow forever; better to fix the group once.
  • /var/run/docker.sock ownership wrong because of a manual install. Check with ls -la; should be root:docker. If not, sudo chown root:docker /var/run/docker.sock && sudo chmod 660 /var/run/docker.sock — but really, this should never need fixing manually. If it does, the install is broken.
  • Rootless and rootful daemons fighting. Only run one. Pick one and systemctl disable / systemctl --user disable the other.

What to do next

FAQ

Sources

Authoritative references this article was fact-checked against.

TagsDockerTroubleshootingPermissionsLinuxDevOps

Found this useful? Pass it on.

Copied
Ishan Karunaratne

Ishan Karunaratne

Tech Architect · Software Engineer · AI/DevOps

Tech architect and software engineer with 20+ years building software, Linux systems, and DevOps infrastructure, and lately working AI into the stack. Currently Chief Technology Officer at a healthcare tech startup, which is where most of these field notes come from.

Keep reading

Related posts