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

Hi, it's BlueByte. When docker ps or docker build stops with Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?, the Docker CLI is working fine — it just couldn't reach the background service (the daemon) it hands every command to. The symptom is any docker command failing instantly with that line, or its close cousin permission denied while trying to connect to the Docker daemon socket. We'll walk through what the socket is, the three reasons the CLI can't reach it, how to confirm which one you hit, fix each, and keep it from coming back.

What the message — and its permission-denied variant — is telling you

The docker command you type is only a client. It talks to a long-running daemon over a Unix socket at /var/run/docker.sock, and every build, run, or ps is really a request across that socket. Two error strings mean the request never landed:

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

permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock

They look similar but point at different causes. The first means nothing answered — the daemon is down or the CLI is aimed at the wrong endpoint. The second means the daemon is up and answered, but the kernel refused you access to the socket file. Read which one you got before you change anything.

The three reasons the CLI can't reach the socket

Both variants come down to one of these:

• The daemon isn't running — the docker service is stopped or failed, so the socket has no listener.
• Your user isn't in the docker group — the daemon is up, but the socket is owned by root:docker and your account can't open it, so you get permission denied.
• The CLI is pointed at the wrong endpoint — a Docker context or a stray DOCKER_HOST sends your commands to a remote or rootless socket that isn't there.

First, check whether the daemon is actually running

Don't guess — ask systemd:

sudo systemctl status docker

● docker.service - Docker Application Container Engine
     Loaded: loaded (/lib/systemd/system/docker.service; enabled)
     Active: inactive (dead) since Mon 2026-09-15 09:02:11 KST

Active: inactive (dead) or failed means the daemon is down — that's your Cannot connect. If it says active (running), the daemon is fine and your problem is permissions or the context, covered below.

Fix a stopped daemon: start it and enable it on boot

Start the service, then set it to come up automatically so a reboot doesn't strand you:

sudo systemctl start docker
sudo systemctl enable docker.service

Active: active (running) since Mon 2026-09-15 09:05:40 KST

If start fails, read the logs with journalctl -u docker --no-pager -n 50 — a bad /etc/docker/daemon.json is the usual reason the daemon won't come up.

Fix "permission denied": add your user to the docker group

If the daemon is running but you get permission denied, your account can't open the root-owned socket. Add yourself to the docker group, then reload your group membership:

sudo usermod -aG docker $USER
newgrp docker

newgrp docker applies the new group in the current shell without a full logout. One caveat worth stating plainly: the docker group grants root-level privileges — anyone in it can start a container that mounts the whole host, so only add trusted users.

Fix a CLI pointed at the wrong context or DOCKER_HOST

If the daemon is up and you're in the group but it still can't connect, the CLI may be aimed elsewhere. List the contexts and see which is active:

docker context ls

NAME       DESCRIPTION   DOCKER ENDPOINT               ERROR
default *                unix:///var/run/docker.sock
remote                   tcp://10.0.0.9:2375

The * marks the active context. If it's on a remote or rootless one that isn't reachable, switch back:

docker context use default

Also check for a leftover override — echo $DOCKER_HOST. If it prints a tcp:// or a rootless unix://.../docker.sock you didn't mean to set, unset DOCKER_HOST and try again.

A real case: docker works with sudo but not without

You install Docker, run docker ps, and get permission denied while trying to connect to the Docker daemon socket. sudo docker ps works, which tells you the daemon is running — only your user lacks access. Rather than prefixing every command with sudo, you run sudo usermod -aG docker $USER and newgrp docker. Now docker ps works with no sudo, because your shell finally carries the docker group and can open the socket.

Confirm the socket answers end to end

Prove the whole path works — client, socket, daemon:

docker run hello-world

Hello from Docker!
This message shows that your installation appears to be working correctly.

docker version is the quieter check: if it prints a Server section and not just a Client section, the CLI reached the daemon. A missing Server block means you're still not connected.

Keep it from coming back — and how this differs from "Error response from daemon"

Enable the service (systemctl enable docker.service) so it survives reboots, keep your everyday user in the docker group, and avoid setting DOCKER_HOST globally in your shell profile where it silently redirects every project. Finally, don't confuse this with docker: Error response from daemon: .... That message means the CLI did reach the daemon — the connection worked and the daemon rejected the specific request (a bad image name, a port conflict). If you see Error response from daemon, stop looking at the socket; the connection is fine and the problem is the command itself.