You type a docker command and get some version of this:
Cannot connect to the Docker daemon at unix:///var/run/docker.sock.
Is the docker daemon running?The message is asking the right question, but it’s only one of three things that can be wrong. The docker command you type is a client. It doesn’t run containers itself — it sends every request to a separate background process, the daemon, over a socket. That error appears whenever the client can’t reach the daemon, which happens for three reasons: the daemon isn’t running, you don’t have permission to use the socket, or the client is pointed at the wrong place.
This guide works through all three, in the order you should check them. Most of it is Linux-focused because that’s where the socket and service live; the Docker Desktop case (Windows and Mac) is simpler and covered near the end.
Understand the client–daemon split
One picture clears up most of the confusion. When you run docker ps, the CLI connects to the daemon at /var/run/docker.sock (on Linux) and asks it for the list of containers. The daemon does the work and sends back the answer.
So “cannot connect to the daemon” is never about a broken image or a bad container. It’s about that connection between client and daemon. Three things break it:
- The daemon isn’t running. Nothing is listening on the socket.
- You lack permission. The daemon is up, but the socket is owned by root and your user can’t open it.
- The client is aimed elsewhere. A
DOCKER_HOSTvariable or a Docker context is sending the CLI to the wrong daemon.
Check them in that order.
Step 1: Is the daemon running? (Linux)
Start with the obvious. On a Linux host with Docker Engine, the daemon runs as a systemd service. Check its state:
systemctl status dockerIf you see active (running), the daemon is up — skip to the permission check. If it’s inactive (dead) or failed, start it:
sudo systemctl start dockerThen make sure it comes back after a reboot:
sudo systemctl enable dockerIf the service refuses to start, don’t guess — read why. The journal almost always names the cause:
sudo journalctl -u docker --no-pager -n 50Common culprits there are a malformed /etc/docker/daemon.json (a single misplaced comma will stop the daemon cold) or a storage/driver problem. Fix what the log points at and start the service again.
Step 2: Fix socket permissions (the permission denied case)
If the daemon is running but you still can’t connect, look at the exact wording. This variant is a permission problem, not a “not running” problem:
permission denied while trying to connect to the Docker daemon socket
at unix:///var/run/docker.sockThe socket is owned by root and the docker group. If your user isn’t in that group, the kernel refuses the connection. Add yourself:
sudo usermod -aG docker $USERThis is the step people get wrong: the new group membership does not apply to your current shell. You have to start a fresh login session. Log out and back in (or reconnect your SSH session), or for the current shell only:
newgrp dockerConfirm the group took effect — docker should appear in the list:
groupsA quick way to confirm it’s purely a permission issue: if sudo docker ps works but docker ps doesn’t, the daemon is fine and the only problem is your group membership.
Which symptom points to which cause
| "Is the docker daemon running?" | Daemon is stopped — start the service (Step 1). |
|---|---|
| "permission denied ... docker.sock" | Group/permission issue — add to docker group, re-login (Step 2). |
| sudo docker works, plain docker doesn't | Confirms a permission problem, not a stopped daemon. |
| Error on Windows/Mac | Docker Desktop isn't started, or wrong context (Step 4). |
| Tries a remote/odd address | DOCKER_HOST or context misconfigured (Step 3). |
Step 3: Check DOCKER_HOST and the active context
If the daemon is running and permissions are fine but the CLI still can’t connect — especially if the error mentions an address that isn’t the local socket — the client is being pointed somewhere else. Two settings do that.
First, the DOCKER_HOST environment variable. It overrides where the CLI looks for the daemon. Check whether it’s set:
echo $DOCKER_HOSTIf that prints a remote address (like tcp://something:2375) and you didn’t set it on purpose — it’s often left behind by a tutorial or a docker-machine setup — clear it:
unset DOCKER_HOSTSecond, the Docker context. A context is a saved connection target. The active one might point at a daemon that isn’t reachable. List your contexts and see which is active:
docker context lsThe active context has an asterisk next to it. To go back to the local daemon:
docker context use defaultStep 4: Docker Desktop on Windows and Mac
On Docker Desktop there’s no systemd service and no socket to chmod. The daemon runs inside the Docker Desktop application, so the connection error almost always means one thing: Docker Desktop isn’t running.
Start Docker Desktop from the Start menu (Windows) or Applications (Mac), and wait. The whale icon animates while it boots, and the dashboard shows Engine starting. Only once it reads Engine running will the CLI connect. Trying commands before then gives you the exact “cannot connect” error.
If Docker Desktop is running and you still can’t connect:
- Check the active context. Docker Desktop uses a context (often
desktop-linux); if you switched away from it, switch back withdocker context use desktop-linux. - On Windows with the WSL2 backend, a stale WSL state can wedge the engine. Quit Docker Desktop, run
wsl --shutdownin PowerShell, then start Docker Desktop again. - Make sure Docker Desktop actually finished its first-run setup. A fresh install that hasn’t been launched yet has no engine to connect to. If you just installed it, see installing Docker Desktop on Windows for the full first-start sequence.
Quick checklist
Clearing 'cannot connect to the Docker daemon'
- Linux: systemctl status docker — start it with sudo systemctl start docker if it's down
- If it won't start: journalctl -u docker to find why (often a bad daemon.json)
- permission denied? Add your user to the docker group, then log out and back in
- Confirm with: sudo docker ps works but plain docker ps doesn't = permission issue
- Check echo $DOCKER_HOST and docker context ls — point the CLI at the right daemon
- Windows/Mac: start Docker Desktop and wait for 'Engine running'
A note on rootless Docker
If you’re running rootless Docker (the daemon as your own user rather than root), the socket lives somewhere else — typically under $XDG_RUNTIME_DIR/docker.sock — and DOCKER_HOST is expected to point at it. In that setup, an unset or wrong DOCKER_HOST is a real cause of the connection error, the opposite of the normal advice. If you deliberately set up rootless mode, make sure the environment variables from its setup are loaded in your shell. If you didn’t, you’re on the standard root daemon and Steps 1–3 apply.
Wrapping up
“Cannot connect to the Docker daemon” is really three problems wearing one message. Walk it in order: confirm the daemon is running (systemctl status docker), then confirm you have permission to reach the socket (the docker group, with a re-login), then confirm the client is aimed at the right daemon (DOCKER_HOST and docker context). On Docker Desktop, it nearly always comes down to starting the app and waiting for the engine.
The fastest diagnostic is still the simplest: if sudo docker ps works and docker ps doesn’t, it’s permissions; if neither works, the daemon is down or unreachable. For more day-to-day container fixes, browse the Docker & Containers guides, and if you’re setting up a fresh host, the Ubuntu Server install guide covers the group and service setup from the start.
