The ErrorYou are ready to start coding, but when you run docker ps or docker-compose up, you hit a wall. Instead of a list of containers, you see this frustrating message:
docker: Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?
Docker doesn't run natively on macOS because the engine relies on Linux-specific kernel features. To bridge this gap, Docker Desktop runs a lightweight Linux virtual machine in the background. This error usually means your CLI tool is trying to talk to that machine, but nobody is answering.
TL;DR: Quick Fixes- Launch the App: Open Docker Desktop from your Applications folder and wait for the whale icon to stay steady.- Verify the Socket: Run ls -l /var/run/docker.sock. If it is missing, Docker isn't fully initialized.- Reset your Context: Run docker context use default to ensure you aren't pointing to a dead service.## Common Causes and Solutions### 1. Docker Desktop isn't actually runningMost of the time, the fix is boring: Docker simply isn't active. Unlike Linux, where Docker often starts automatically as a system service, macOS requires the Docker Desktop app to be open to provide the virtualization layer.
Fire it up from the terminal with this command:
open /Applications/Docker.app
Give it some time. On an M2 MacBook Pro, the engine typically takes 20 to 30 seconds to boot. Older Intel Macs might need a full minute. You will know it is ready when docker info returns a block of text instead of an error.
2. The 'Advanced' Socket Setting (macOS Ventura & Sonoma)Since version 4.13, Docker Desktop changed how it handles the /var/run/docker.sock file to improve security. If this file is missing, your terminal won't know how to reach the engine.
Navigate to Settings > Advanced in Docker Desktop. Look for "Allow the default Docker socket to be used". If it is unchecked, check it and click "Apply & Restart." If it is already checked but failing, try toggling it off and back on to force Docker to recreate the symlink.
3. The Context MismatchIf you have experimented with alternatives like Colima, OrbStack, or Minikube, your Docker CLI might be looking at the wrong place. Think of a context as a phone contact; your CLI is calling 'Colima' when it should be calling 'Docker Desktop.'
Check your active connections:
docker context ls
If the asterisk (*) is next to anything other than default (and you aren't actively using that tool), switch back:
docker context use default
4. Colima Users: The VM is AsleepDevs often use Colima to save RAM, as it typically uses about 2GB compared to Docker Desktop's heavier footprint. However, you must start it manually after every reboot:
colima start
If it hangs or the socket remains unresponsive, a hard restart usually clears the cache:
colima stop
colima start --force
5. Ghost Environment VariablesOld setup scripts sometimes leave a DOCKER_HOST variable in your shell profile. This forces Docker to look for a network address instead of the local Unix socket. Check for any hidden settings by running:
echo $DOCKER_HOST
If it returns a value like tcp://localhost:2375, you need to clear it. Run unset DOCKER_HOST. To make this permanent, open your .zshrc or .bash_profile and delete any lines that export that variable.
Verification: Confirming the FixOnce you have applied a fix, run a quick connectivity test:
docker ps
Success looks like a clean table header. Even if you have no containers running, seeing the column titles means the communication bridge is restored:
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
For a deeper look, docker version should now list both a "Client" and a "Server" section. If the "Server" section appears, you are officially back in business.