Cannot Connect to the Docker Daemon: 4 Causes and Fixes

You run any docker command and get:

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

The message is asking a real question, and there are only four possible answers: the daemon is stopped, your user lacks permission to talk to it, the Docker CLI is pointed at the wrong context, or the socket path itself is non-standard. Each has a distinct check that takes seconds.

systemctl status docker

Cause 1: The Docker Daemon Is Not Running

Start here, because it is the most common cause on servers and freshly rebooted machines. Ask systemd:

systemctl status docker

If you see inactive (dead), start it:

sudo systemctl start docker

Then confirm it stays up and enable it at boot so a reboot does not resurrect the problem:

sudo systemctl enable --now docker

If the status instead says failed, the daemon is trying to start and dying. Read its journal:

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

The two failures you are most likely to find are a malformed /etc/docker/daemon.json — a stray comma is enough — and a storage driver mismatch after an upgrade. If you recently edited that file, validate it:

sudo python3 -m json.tool /etc/docker/daemon.json

A parse error here tells you exactly which line broke the daemon.

Cause 2: Your User Is Not in the docker Group

If the daemon is running but you still cannot connect, this is nearly always the reason. The tell is that the same command works with sudo:

sudo docker ps

If that succeeds while docker ps fails, it is a permissions issue. The socket at /var/run/docker.sock is owned by root and readable by the docker group:

ls -l /var/run/docker.sock

Check whether you are in that group:

groups $USER

If docker is missing from the list, add yourself:

sudo usermod -aG docker $USER

This change does not apply to your current shell. Group membership is read when a session starts, so you must log out and back in — this is why the fix so often appears to do nothing. To test immediately without logging out:

newgrp docker

That opens a subshell with the new group applied. Verify:

docker ps

Understand what you granted. Anyone in the docker group can mount the host filesystem into a container and gain root. Treat docker group membership as equivalent to passwordless sudo, and do not add service accounts to it casually.

Cause 3: The CLI Is Pointed at the Wrong Context

Docker contexts let one CLI talk to several daemons — a local one, a remote server, Docker Desktop. If your context points somewhere unreachable, you get this exact error even though a perfectly healthy daemon is running locally.

List your contexts and see which is selected:

docker context ls

The active context is marked with an asterisk. If it is not the one you want, switch:

docker context use default

Also check for a DOCKER_HOST environment variable, which overrides the context entirely and is easy to forget after experimenting with a remote daemon:

echo $DOCKER_HOST

If it prints an address you no longer use, unset it and check your shell profile for a line that sets it on every login:

unset DOCKER_HOST
grep -r DOCKER_HOST ~/.bashrc ~/.zshrc ~/.profile 2>/dev/null

Cause 4: Docker Desktop on macOS or Windows

On macOS and Windows there is no docker systemd service — the daemon runs inside a virtual machine managed by Docker Desktop. Running systemctl start docker will simply fail, which sends people down the wrong path.

The fix is to make sure Docker Desktop itself is running and has finished starting. Its whale icon shows a settled state rather than an animated one when the daemon is ready. From a terminal you can confirm the CLI can reach it:

docker version

If the Client section prints but the Server section shows an error, Desktop is still booting or has crashed. Quit and reopen it, and check its dashboard for a resource warning — on machines low on disk space Desktop will refuse to start the VM.

Under WSL2 on Windows, also confirm integration is enabled for your distribution in Docker Desktop’s Settings under Resources, then WSL Integration. Without it, the Linux-side CLI has no socket to reach.

Verify the Fix

Confirm the CLI and daemon are both talking:

docker version

You want both a Client and a Server block with version numbers. A Server block is proof the daemon answered. Then run something real:

docker run --rm hello-world

If that pulls and prints its greeting, the connection is fully working.

Prevent It From Recurring

Two settings cover the repeat offenders. Make sure the daemon starts on boot:

sudo systemctl enable docker

And whenever you provision a new machine or user, add the group membership as part of setup rather than after the first confusing error. If you manage servers with a configuration tool, put both the enable and the group membership in that configuration so a rebuilt host never lands in this state.

Finally, if you use remote contexts, get in the habit of running docker context ls as your first diagnostic step. It takes a second and immediately rules out the least obvious of the four causes.

Frequently Asked Questions