Introduction

When Colima says it cannot find the Docker daemon, the problem is usually not that Docker has disappeared. The more common issue is that the Docker CLI is pointing at the wrong socket, the Colima VM is not running, or your active Docker context no longer matches the Colima-managed daemon.

Understand what Colima is wiring together

Colima runs a lightweight VM and starts a container runtime inside it. Your local docker command then talks to that runtime through a Unix socket and a Docker context.

That means there are several pieces that all have to line up:

• the Colima VM must be running
• the container runtime inside it must be healthy
• the Docker CLI must be targeting the Colima socket or context
• no stale DOCKER_HOST must be overriding that target

If any one of those breaks, the error often looks like "cannot connect to the Docker daemon" even though the real cause is configuration drift.

Check whether Colima is actually running

Start with the obvious state check:

colima status

If it is stopped, start it:

colima start

Then confirm Docker can talk to the daemon:

docker version
docker info

If Colima starts successfully and docker info still fails, the next suspect is usually the CLI target rather than the VM itself.

Verify the Docker context and host variables

Colima often works by creating or using a Docker context. If you switched contexts for another tool, the CLI may now be pointing somewhere else.

Check the current context:

docker context ls
docker context show

If needed, switch back:

docker context use colima

Also inspect DOCKER_HOST. A stale value here can override the context entirely:

echo "$DOCKER_HOST"

If it points to an old socket or TCP endpoint, unset it and try again:

unset DOCKER_HOST
docker info

This is one of the most common causes after shell-profile changes or switching between Docker tools.

Restart Colima when the socket looks stale

Sometimes the VM was upgraded, resumed poorly, or left behind a stale socket reference. In that case, a clean restart is often enough:

colima stop
colima start

If the issue persists, inspect the runtime directly:

colima ssh

From there you can confirm whether the daemon is healthy inside the VM. If it works inside Colima but not from your host shell, that strongly suggests a host-side CLI or socket problem.

Homebrew, shell startup, and multiple Docker tools can interfere

Colima problems are often environment problems in disguise. Common examples:

• Docker Desktop was previously installed and left a different context active
• shell startup files export DOCKER_HOST
• an old symlink still points at a removed socket
• 'docker CLI plugins were installed from a different source than Colima expects'

That is why checking the active context and DOCKER_HOST is usually more productive than reinstalling Colima immediately.

A practical recovery sequence

If you want a quick, low-risk recovery order, use this:

1. run colima status
2. run colima start if needed
3. run docker context show
4. switch to colima context if necessary
5. unset DOCKER_HOST if it is set unexpectedly
6. restart Colima if the socket still appears stale

That sequence fixes most host-side configuration failures without destroying any images or volumes.

Common Pitfalls

The most common mistake is assuming the Docker daemon itself is missing when the real issue is that the CLI is pointed at the wrong context or socket.

Another common issue is leaving DOCKER_HOST exported in a shell profile. That silently overrides the context you thought Docker was using.

People also bounce between Docker Desktop and Colima and forget that the active Docker context persists across sessions.

Finally, reinstalling Colima too early can waste time. State, socket, and context checks usually find the problem faster.

Summary

• Colima Docker-daemon errors usually come from VM state, context selection, or socket targeting.
• Check colima status, docker context show, and DOCKER_HOST first.
• Switch back to the colima context if the CLI is targeting something else.
• Restart Colima when the daemon socket looks stale.
• Treat the issue as a host-to-daemon wiring problem, not just a missing daemon.