Docker Cannot Connect to the Docker Daemon — How to Fix It

What you're seeing

The most common variant:

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

Variants:

• permission denied while trying to connect to the Docker daemon socket — daemon is running, you can't read the socket
• error during connect: Get "http://%2F%2F.%2Fpipe%2Fdocker_engine/..." — Windows variant, same root cause
• Cannot connect to the Docker daemon at tcp://... — you have DOCKER_HOST set to a remote daemon that's unreachable

What's causing this error

Docker is two pieces: the daemon (the long-running process that actually runs containers) and the CLI (the docker command you type). The CLI talks to the daemon over a Unix socket on Linux (/var/run/docker.sock) or a named pipe on Windows. If the CLI can't reach the daemon, every command fails with this error.

The three real causes:

1. The daemon isn't running. On Linux, the docker systemd service is stopped. On macOS/Windows, Docker Desktop isn't open.
2. Your user can't access the socket. The daemon is running, but /var/run/docker.sock is owned by root:docker (mode 660). If your user isn't in the docker group, you can't read it.
3. DOCKER_HOST points at a daemon that doesn't exist. Common when an old SSH context or remote daemon URL is set in your environment.

How to fix it

Step 1: Find out what the CLI is trying to reach

docker context ls

This shows which Docker context (and thus which daemon) the CLI is currently using. Default is default → local socket. If you see a context with a remote URL active, that's likely the problem — switch back to default:

docker context use default

Also check for stray environment variables:

env | grep -i docker

If DOCKER_HOST is set to something stale, unset it:

unset DOCKER_HOST

Step 2: Make sure the daemon is running

$ sudo systemctl status docker
# If inactive:
$ sudo systemctl start docker
$ sudo systemctl enable docker      # start on boot
# Verify:
$ docker info

If docker info works, you're done. If it still fails with the permission variant, go to step 3.

Step 3: Fix socket permissions (Linux only)

If you're seeing permission denied while trying to connect to the Docker daemon socket, the daemon is fine — your user just can't read the socket.

Check whether the docker group exists and you're in it:

getent group docker
groups

If docker exists but your user isn't listed, add yourself:

sudo usermod -aG docker $USER

You must log out and back in for the new group membership to take effect. In a pinch, you can run newgrp docker to start a new shell with the updated groups, but it only affects that shell — a fresh login is cleaner.

After re-login:

docker ps

Should work without sudo.

Step 4: Daemon won't start (Linux)

If systemctl start docker fails, check the logs:

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

Common causes from the log output:

• Storage driver mismatch after kernel upgrade — usually fixed by removing /var/lib/docker/buildkit and restarting
• Port already in use — another process is on port 2375/2376
• /var/run/docker.sock exists as a stale file — sudo rm /var/run/docker.sock then restart
• Out of disk — df -h /var/lib/docker to confirm

Step 5: Docker Desktop specific (macOS / Windows)

If Docker Desktop is "running" but docker info still fails:

• macOS: Click the whale icon → Troubleshoot → Reset to factory defaults (saves a lot of time vs manual diagnosis)
• Windows: Right-click whale icon → Switch to Linux containers (or vice versa — the engine you're targeting must match the container type)
• WSL2 backend on Windows: make sure your WSL2 distro is integrated — Settings → Resources → WSL Integration → enable for your distro

Common edge cases