When docker ps spits out "Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?", your first instinct is probably to curse at your screen. This error message is Docker's equivalent of Windows' "Something went wrong" - technically accurate but completely fucking useless when you need to actually fix something.
Look, the Docker CLI (docker command) is just a client that talks to the Docker daemon (dockerd) through a Unix socket or network connection. When that connection fails, the CLI has no clue if the daemon crashed, never started, or if there's a permission problem. So it asks the dumbest possible question: "Is the daemon running?" Thanks Docker, super helpful.
The permission thing is simple: Docker creates a socket file that only root and the docker group can access. If you're not in that group, you get the "permission denied" bullshit.
The Real Reasons Your Docker Daemon Won't Connect
It's not just "is the daemon running." Here are the actual problems you're dealing with:
Socket Permission Issues (Most Linux Cases)
Docker creates a Unix socket at /var/run/docker.sock that only root and the docker group can touch. If you're not in that group, you get "permission denied" on every fucking command.
I've fixed this exact issue dozens of times for new team members. The Docker docs have the official steps, but here's the reality: everyone skips the post-install setup and then spends hours wondering why Docker doesn't work.
Check if you're in the docker group:
groups $USER
If you don't see docker in the output, that's your problem. The socket exists, the daemon is running, but you can't talk to it.
Docker Desktop Lies About Running (Windows/macOS)
Docker Desktop is a VM wrapper around the real Docker daemon. The cute whale icon in your taskbar can say "running" while the VM inside is completely fucked.
Windows 11 22H2 update broke WSL2 integration for like half our team. I spent 2 hours last month helping someone whose Docker Desktop showed the green whale like everything was fine, but WSL2 couldn't connect because Microsoft changed something in the networking stack and didn't tell anyone.
The CLI has no idea Docker Desktop is a wrapper around a VM. It just knows the socket doesn't exist or won't respond.
Systemd Fails Silently (Linux Servers)
Docker runs as a systemd service on Linux servers. When systemctl start docker shits the bed, you get the useless "cannot connect" error instead of the actual problem.
Network bridge conflicts are the absolute worst because they're invisible until they fuck you. Docker tries to create its docker0 bridge but it conflicts with existing networks. Ubuntu 22.04 does this shit out of the box - NetworkManager and Docker fight over who controls networking and the user gets screwed.
WSL2 Integration Failures (Windows Development Hell)
Docker Desktop on Windows uses WSL2 integration that's fragile as hell. The Docker daemon runs in a hidden WSL2 VM, and the Windows Docker CLI connects through networking magic. When WSL2 updates, network configuration changes, or Docker Desktop restarts incorrectly, this integration breaks spectacularly.
This GitHub issue shows the typical problem - Docker Desktop appears running but WSL2 can't connect to the daemon. The socket exists in the Windows world but not in the Linux world, or vice versa.
Diagnosing the Real Problem (Not Just Guessing)
Step 1: Confirm daemon existence
## Linux/macOS
sudo ps aux | grep dockerd
## Windows
Get-Process | Where-Object {$_.ProcessName -eq "dockerd"}
If you see a dockerd process, the daemon is running. The problem is communication, not startup.
Step 2: Check socket connectivity
## Linux/macOS
ls -la /var/run/docker.sock
## Should show: srw-rw---- 1 root docker
If the socket doesn't exist, the daemon isn't running or is configured to use a different socket. If it exists but has wrong permissions, you found your problem.
Step 3: Test socket directly
## Bypass CLI and test socket directly
sudo docker version
If sudo docker version works but docker version doesn't, it's definitely a permission issue, not a daemon problem.
Step 4: Check daemon logs
## Linux with systemd
journalctl -u docker.service -f
## macOS Docker Desktop
tail -f ~/Library/Containers/com.docker.docker/Data/log/vm/dockerd.log
## Windows Docker Desktop
## Check Docker Desktop → Troubleshoot → Get Support Info
The logs tell you what's actually wrong instead of the generic "daemon not running" nonsense.
Platform-Specific Diagnostic Commands
Linux Server Diagnosis
## Service status
systemctl status docker
## Manual daemon start with debug
sudo dockerd --debug
## Check for conflicting services
netstat -tulnp | grep :2376
Docker Desktop (Windows/macOS)
## Check Docker Desktop status
docker version --format '{{.Server.Os}}/{{.Server.Arch}}'
## Reset Docker Desktop
## Windows: Docker Desktop → Troubleshoot → Reset to factory defaults
## macOS: Docker Desktop → Bug report and diagnostics → Reset to factory defaults
WSL2 Specific (Windows)
## Check WSL integration
wsl -l -v
## Verify Docker Desktop integration
docker version --format json | jq .Server
The Environment Variable Trap
Docker respects the DOCKER_HOST environment variable, which overrides the default socket location. If someone set this in your shell profile and pointed it to a non-existent host, every Docker command will fail with "cannot connect" errors.
Check for toxic environment variables:
env | grep -i docker
If you see DOCKER_HOST=tcp://some.dead.server:2376, that's why your local daemon "isn't running." The CLI is trying to connect to a remote daemon that doesn't exist. This forum thread has multiple examples of this exact problem.
Memory Limits Fuck You Over
Docker Desktop defaults to 2GB memory, which is a joke for modern development. When containers try to use more memory, the daemon doesn't gracefully fail - it just becomes unresponsive and the CLI thinks it's dead.
I learned this the hard way during a Friday deploy when our Next.js build kept "failing to connect to daemon" - spent an hour thinking the daemon was broken before realizing it needed 3GB memory but Docker Desktop was still at the default 2GB limit. The build was just hanging and timing out silently.
Network Configuration Conflicts
Docker creates bridge networks that can conflict with existing VPNs, corporate network policies, or other virtualization software. When the daemon can't create its default bridge network, it fails to start but logs cryptic networking errors instead of clear "network conflict" messages.
Common conflicts:
- Cisco AnyConnect VPN: Blocks Docker's default
172.17.0.0/16network - VirtualBox: Uses the same network ranges as Docker
- Corporate firewalls: Block Docker's bridge creation
The daemon starts, tries to create networks, fails, and dies. From the CLI's perspective, it looks like the daemon never started.
This diagnostic process helps you understand what's actually broken instead of randomly restarting services and hoping for the best. Once you know if it's a permission issue, service failure, or network conflict, you can fix the root cause instead of applying cargo cult solutions from Stack Overflow.
Now that you understand what causes these problems, let's move on to platform-specific solutions that actually work in practice.