Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running? — the client found no engine behind the socket. Start it: sudo systemctl start docker where systemd runs, sudo service docker start in a WSL distribution without systemd.

In WSL without systemd nothing starts the engine when the distribution starts, so either start it each time or switch systemd on in /etc/wsl.conf. Docker 29.9.2 also printed a second wording for the same problem when the socket file was missing altogether, shown below.

The error

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

And in the same distribution with systemd switched off and restarted:

$ ps -p 1 -o comm=
init(fix7-dk)
$ docker ps
failed to connect to the docker API at unix:///var/run/docker.sock; check if the path is correct and if the daemon is running: dial unix /var/run/docker.sock: connect: no such file or directory

Why it happens

The docker command sends every request to the engine, dockerd, through /var/run/docker.sock. When no process listens there, the client cannot tell why, so it asks whether the daemon is running. Which wording you get depends on the socket file: after systemd stopped both units the file stayed behind with nothing listening, and the client printed the classic line; in a freshly started distribution without systemd the file did not exist, and Docker 29.9.2 printed the failed to connect to the docker API line ending in no such file or directory.

Two traps make this confusing. With systemd, sudo systemctl stop docker alone does not keep the engine down: it warned Stopping 'docker.service', but its triggering units are still active: docker.socket, and the next docker ps started the engine again through socket activation. Without systemd, PID 1 is WSL's own init, systemctl refuses to work, and the engine runs only when someone starts it.

The fix

$ sudo systemctl start docker
$ systemctl is-active docker.service docker.socket
active
active
$ docker ps
CONTAINER ID   IMAGE     COMMAND   CREATED   STATUS    PORTS     NAMES

Without systemd, the package's init script does the same job:

$ systemctl start docker
System has not been booted with systemd as init system (PID 1). Can't operate.
Failed to connect to bus: Host is down
$ sudo service docker start
 * Starting Docker: docker
   ...done.
$ docker ps
CONTAINER ID   IMAGE     COMMAND   CREATED   STATUS    PORTS     NAMES

To make it permanent in WSL, write systemd=true under [boot] in /etc/wsl.conf (as root), stop that one distribution from Windows and open it again. The engine was then active with nothing started by hand, because the package enables docker.service: 

PS> wsl --terminate fix7-dk
The operation completed successfully.
$ cat /etc/wsl.conf
[boot]
systemd=true
$ ps -p 1 -o comm=
systemd
$ systemctl is-active docker.service docker.socket
active
active

wsl --terminate with a name stops that distribution alone, which was enough here. You do not need wsl --shutdown: its own help says it terminates all running distributions and the WSL 2 virtual machine, and on a PC with Docker Desktop that list includes docker-desktop.

How it was reproduced

A throwaway WSL distribution made with wsl --install Ubuntu-24.04 --name fix7-dk --no-launch on WSL 2.7.10 (Ubuntu 24.04.5 LTS, shipped with systemd=true), with docker-ce 29.9.2 and containerd.io 2.4.2 from Docker's own apt repository. The first error came from stopping both systemd units; the second from writing systemd=false into /etc/wsl.conf and terminating the distribution. The test engine ran with bridge networking and iptables off, which the socket does not depend on. fix7-dk and the user maria are the test's own; the distribution was unregistered afterwards.

Frequently asked

How do I start the Docker daemon in WSL?
With systemd on, run sudo systemctl start docker; without it, run sudo service docker start. To have the engine start with the distribution, set systemd=true under [boot] in /etc/wsl.conf and restart the distribution with wsl --terminate and its name.
Why does Docker start again after systemctl stop docker?
docker.socket is still listening and starts docker.service on the next connection. systemctl prints a warning that names docker.socket. Stop both units to keep the engine down.
What does 'failed to connect to the docker API ... no such file or directory' mean?
It is how Docker 29 reported a missing socket file in the test, in a WSL distribution without systemd where nothing had started the engine. Start the engine and the message goes away.

More decoded errors in the Fixes category. Setting up a WSL distribution for development, systemd included: WSL for .NET developers. If the engine runs but your user is refused, see permission denied on /var/run/docker.sock.