'Cannot connect to the Docker daemon' — reach dockerd
Quick answer: the docker CLI could not reach the daemon. Either dockerd is not running (start it), your user is not in the docker group so the socket gives permission denied (add the user and log in again), or DOCKER_HOST points somewhere wrong. In CI, make sure a Docker socket or a docker service is available. Note: the docker group is effectively root - grant it deliberately.
What the error looks like
Two forms - one for a stopped daemon, one for a permission problem:
Cannot connect to the Docker daemon at unix:///var/run/docker.sock.
Is the docker daemon running?
# or, the daemon is up but you cannot reach the socket:
permission denied while trying to connect to the Docker daemon socket
at unix:///var/run/docker.sock“Is the docker daemon running?” usually means dockerd is stopped. permission denied means the daemon is up but your user lacks access to its socket.
Why it happens
Daemon not running
dockerd is stopped or failed to start - nothing is listening on the socket.
User not in the docker group
The daemon is up but your user cannot access /var/run/docker.sock - permission denied.
DOCKER_HOST misconfigured
An env var points the CLI at a daemon address that is wrong or unreachable.
CI without a daemon
The job has no Docker socket or docker service available to talk to.
Diagnose it in three steps
Is dockerd running?
systemctl status docker
# inactive/failed? that is your "is the daemon running" error.Are you in the docker group?
groups | grep docker
# missing? that is the permission-denied error.Is DOCKER_HOST set?
echo "$DOCKER_HOST"
# a stale value points the CLI at the wrong daemon - unset or fix it.Start the daemon, grant access deliberately
Start and enable dockerd, and give your user access to the socket - knowing that the docker group is effectively root. On shared or production hosts, prefer sudo per command or rootless Docker over broad group access.
# start and enable the daemon
sudo systemctl start docker
sudo systemctl enable docker
# grant your user access (re-login or newgrp for it to take effect)
sudo usermod -aG docker $USER
newgrp docker # or log out and back in
# fix a stale DOCKER_HOST
unset DOCKER_HOSTSecurity note: a user in the docker group can mount the host filesystem into a container and become root, so treat docker-group membership as root-equivalent and grant it only where that is acceptable.
Keep the daemon up, grant least privilege
A stopped daemon and over-broad docker-group access are both operational risks. On your own servers, Infraveil supervises the services your stack depends on and keeps least-privilege access in view - so the daemon stays running, access stays deliberate (docker group is root-equivalent), and changes are recorded and inspectable.
Frequently asked questions
Is the Docker daemon actually running?
Check systemctl status docker. If inactive, start it with sudo systemctl start docker and enable on boot with sudo systemctl enable docker. The "is the docker daemon running?" message almost always means it is stopped or unreachable.
Why permission denied on /var/run/docker.sock?
Your user is not in the docker group, so it cannot access the daemon socket. Add it with sudo usermod -aG docker $USER, then log out and back in (or run newgrp docker) for the membership to take effect.
Is adding my user to the docker group safe?
Be deliberate - the docker group is effectively root, because you can run a container that mounts the host filesystem. On shared or production machines, prefer sudo per command or rootless Docker over broad group access.
How do I fix this in CI?
The job needs a Docker daemon - use the platform's Docker service, mount the host socket, or run Docker-in-Docker with a docker:dind service. If DOCKER_HOST is set, make sure it points at the daemon the job actually has.
Client-side, no signup — they run in your browser.