How to Fix "Cannot Connect to the Docker Daemon"

You ran a Docker command and got back Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?Copy. Every Docker command is now dead in the water, which is what makes this one so annoying.

The Docker CLI is just a thin client. It does nothing on its own; it forwards every request to a background daemon (dockerdCopy) over a Unix socket, usually /var/run/docker.sockCopy. This error means the CLI reached for that socket and found nothing listening, either because the daemon genuinely isn't running, because you don't have permission to talk to the socket, or because your CLI is pointed at the wrong socket entirely.

This article walks through the three causes in the order you should check them, then covers the two setups that trip people up most: Docker Desktop on Linux, and Docker inside Windows Subsystem for Linux 2 (WSL2) on Windows.

First, is the daemon actually running?

Start here, because it's the most common cause and the fastest to rule out. On any Linux system with systemd, check the service status:

1
systemctl status docker

If it's stopped, you'll see Active: inactive (dead)Copy or failedCopy. A healthy daemon looks like this:

123
● docker.service - Docker Application Container Engine
     Loaded: loaded (/usr/lib/systemd/system/docker.service; enabled; preset: enabled)
     Active: active (running) since Tue 2026-06-09 09:14:22 UTC; 12min ago

If it's not running, start it, and enable it so it survives a reboot:

1
sudo systemctl enable --now docker

Then confirm the CLI can reach it:

1
docker info

If docker infoCopy returns engine details instead of the connection error, you're done. If systemctl startCopy itself fails, the daemon is crashing on startup rather than simply being stopped, which is a different problem. Run it in the foreground to see why:

1
sudo dockerd

Watch the output for the actual error. Common ones are a storage driver failure, a corrupted /var/lib/dockerCopy, or a port conflict on a configured TCP listener. Fix the cause it reports rather than restarting blindly.

Fix socket permissions and the docker group

If the daemon is running but you still get a permission error like dial unix /var/run/docker.sock: connect: permission deniedCopy, the daemon is fine and your user simply isn't allowed to talk to the socket.

Check who owns it:

1
ls -l /var/run/docker.sock

1
srw-rw---- 1 root docker 0 Jun  9 09:14 /var/run/docker.sock

The socket is owned by rootCopy and the dockerCopy group, with read and write granted to that group. So any user in the dockerCopy group can use it. Check whether you're in that group:

1
groups

If dockerCopy isn't in the list, add yourself:

1
sudo usermod -aG docker $USER

Group membership is only evaluated at login, so this won't take effect in your current shell. Either log out and back in, or load the new group into your current session:

1
newgrp docker

A quick warning: adding yourself to the dockerCopy group is effectively root-equivalent, because anyone who can talk to the daemon can mount the host filesystem into a container and escalate. That's expected and fine on a personal dev machine, but on shared or production hosts, prefer rootless mode instead.

Check which daemon your CLI is targeting

If the daemon is running and your permissions are correct but the error persists, the CLI is probably looking in the wrong place. Two things control this: the DOCKER_HOSTCopy environment variable and your active Docker context.

DOCKER_HOSTCopy overrides everything else when it's set. Check it:

1
echo $DOCKER_HOST

If it prints something like tcp://localhost:2375Copy or an ssh://Copy endpoint you don't recognize, that's your problem. The CLI is dialing that address instead of the local socket. Unset it:

1
unset DOCKER_HOST

If DOCKER_HOSTCopy is empty, check your context:

1
docker context ls

123
NAME            DESCRIPTION                               DOCKER ENDPOINT
default *       Current DOCKER_HOST based configuration   unix:///var/run/docker.sock
desktop-linux   Docker Desktop                            unix:///home/you/.docker/desktop/docker.sock

The asterisk marks the active context. If it's on a context whose endpoint points at a daemon that isn't running, switch back to the one you want with docker context use defaultCopy. This matters a lot once Docker Desktop is in the picture.

Docker Desktop vs Docker Engine on Linux

This is the case that produces the most confusing version of the error, where sudo docker psCopy works but plain docker psCopy doesn't, or containers vanish depending on which command you run.

On Linux, Docker Desktop and Docker Engine are two separate daemons. Docker Engine (the docker-ceCopy package you install from the apt repo) runs natively on the host and listens on /var/run/docker.sockCopy. Docker Desktop, by contrast, runs the engine inside its own virtual machine and exposes a per-user socket under your home directory. When Desktop starts, it creates and switches to a desktop-linuxCopy context automatically; when it stops, it resets the context back to defaultCopy.

So the error shows up when your context points at one daemon while only the other is running. If you use Docker Desktop, make sure it's actually started (the GUI should say the engine is running), then confirm your context:

1
docker context use desktop-linux

If you use the native engine instead, switch to defaultCopy and make sure Desktop isn't hijacking the context. Running both daemons at once wastes resources and invites exactly this kind of confusion, so if you've settled on Desktop, stop the native engine (Docker's install docs cover switching between the two):

1
sudo systemctl disable --now docker docker.socket containerd

Leave containerdCopy out of that command if anything else on the host depends on it directly, such as k3s, a standalone Kubernetes node, or nerdctlCopy. Docker Desktop runs its own containerd inside its VM, so disabling the host one is only safe when nothing else is using it.

One sharp edge worth knowing: Docker Desktop on Linux does not bind /var/run/docker.sockCopy. The CLI works because the desktop-linuxCopy context points elsewhere, but any SDK or other tool that hardcodes /var/run/docker.sockCopy will hit the connection error even though dockerCopy commands succeed. If a tool breaks while your CLI works, that mismatch is usually why.

The WSL2 case on Windows

Inside a WSL2 distro, there's no Linux daemon running by default. Docker Desktop on Windows runs the daemon and bridges the socket into your distro, but only if you've turned that bridge on. Open Docker Desktop, go to Settings, then Resources, then WSL Integration, and toggle on your distro (for example, Ubuntu). Apply and restart. Docker Desktop itself also has to be running on Windows; if the whale icon isn't in your taskbar, nothing in WSL can connect.

There's also a classic leftover that breaks WSL2 specifically. Older WSL1 setups exported DOCKER_HOST=tcp://localhost:2375Copy to reach the daemon over TCP, and that line often survives an upgrade to WSL2, where it no longer points at anything. The symptom is Cannot connect to the Docker daemon at tcp://localhost:2375Copy. The fix is to remove it:

1
unset DOCKER_HOST

If that resolves it, delete the matching export DOCKER_HOST=...Copy line from your ~/.bashrcCopy or ~/.profileCopy so it doesn't return on your next login.

Common pitfalls

The biggest trap is reaching for sudo dockerCopy the moment you hit a permission error. It works, so it feels like a fix, but all it does is run the CLI as root and mask the real problem: your user isn't in the dockerCopy group. You'll then create files and containers owned by root, and the moment you forget the sudoCopy, you're back to the same error. Fix the group membership instead of papering over it.

The second is the non-Bourne shell quirk in WSL2. If your default shell is fishCopy, cshCopy, or tcshCopy, Docker Desktop's integration script can fail to create the socket symlink, so docker psCopy fails even with integration enabled and Desktop running. If you've ruled out everything else, check whether switching your default shell back to bashCopy makes the socket reappear.

Final thoughts

The error message always means the same thing (the CLI couldn't reach a daemon) but the cause splits cleanly: the daemon is down, your permissions are wrong, or your CLI is pointed at the wrong endpoint. Work through them in that order and you'll land on the fix without guessing. Once Docker is talking again, it's worth running docker infoCopy after any reboot or Docker Desktop update, since context resets and integration toggles are the usual culprits behind a recurrence.

The failures that actually take workloads down are quieter than this one. A container that keeps getting OOM-killed, a restart loop, a daemon slowly filling the disk: none of them print a message as clear as the connection error you just fixed. Dash0's infrastructure monitoring tracks container and host health alongside live logs and distributed traces, so those surface before they page you. If you're new to wrangling container output, the guide on mastering Docker logs is a good next stop. Start a free trial to see your containers, hosts, and traces in one view. No credit card required.