Cannot connect to the Docker daemon
Why the Docker CLI reports it can't connect to the daemon, how to tell 'not running' apart from a permissions problem, and how to fix each.
Last updated
Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?
What it means: The `docker` CLI can't reach the Docker daemon — the background service that actually runs containers — through its socket; the CLI itself works fine, but nothing is listening on the other end.
Likely causes
Most probable first — with how to confirm.
- 1.Docker Desktop (macOS/Windows) or the `dockerd` service (Linux) simply isn't running — check for the Docker Desktop app, or on Linux, `systemctl status docker`.
- 2.On Linux, your user isn't in the `docker` group, so you lack permission to talk to the socket even though the daemon is running — this usually surfaces as a 'permission denied' variant of this same message rather than 'is it running'; check `groups $USER` and `ls -l /var/run/docker.sock`.
- 3.The daemon crashed or is still starting up, common right after a reboot or a Docker Desktop update — give it a few seconds and retry.
- 4.You're targeting a non-default Docker context (the `DOCKER_HOST` env var, or `docker context`) that points at a daemon that isn't actually reachable from here.
Fixes
Safest first; destructive ones are called out.
- →Start Docker: open Docker Desktop and wait for it to report 'running' (macOS/Windows), or run `sudo systemctl start docker` (Linux) — then retry the command.
- →On Linux, if it's a permissions issue rather than 'not running', add your user to the docker group (`sudo usermod -aG docker $USER`) and log out and back in (or run `newgrp docker`). Know what you're trading: docker-group membership is effectively passwordless root on that host, since any member can mount the host filesystem into a container. On a shared or production machine, prefer rootless Docker.
- →Check `docker context ls` and `echo $DOCKER_HOST` if you suspect it's pointed at the wrong daemon, and switch back with `docker context use default` if so.
- →If Docker Desktop itself won't start, restarting the app (or the host machine) resolves most transient daemon crashes; a persistent failure is worth checking Docker Desktop's own diagnostic logs for.
Part by part
- Cannot connect to the Docker daemon
- The CLI is a client that talks to a background service. This message means the client works and found nothing to talk to.
- unix:///var/run/docker.sock
- The socket it tried. A Unix socket rather than a network address, which is why permissions on that file matter as much as whether the service is running.
- Is the docker daemon running?
- The suggestion, and the right first check — but not the only cause, since a running daemon with an unreadable socket produces the identical message.
Common mistakes
sudo docker psConfirms the daemon is running and papers over a permissions problem. Every subsequent command then needs sudo, and files created by containers end up owned by root in your project.
sudo chmod 666 /var/run/docker.sockGrants every user on the machine full control of Docker, which is equivalent to root — a container can mount the host filesystem. Add yourself to the docker group instead, understanding that group has the same power.
Reinstalling DockerA long way round for a service that is usually just stopped. Check the service status and the socket permissions first; both take seconds and cover most cases.
Questions
How do I tell whether it is stopped or a permissions problem?
Run the same command with sudo. If it works, the daemon is running and your user cannot reach the socket; if it still fails, the daemon is not running.
What is the fix on macOS or Windows?
Start Docker Desktop — the daemon runs inside its virtual machine and the CLI cannot reach it until the app is up. There is no service to start separately as there is on Linux.
Is adding myself to the docker group safe?
It grants root-equivalent access, since a container can mount the host filesystem. That is acceptable on a personal machine and worth considering carefully on a shared one; rootless Docker exists for the latter.
Why does it work in one terminal and not another?
Group membership is applied at login, so a shell opened before you were added to the docker group does not have it. Log out and back in, or start a new session, rather than debugging further.