¿Has intentado ejecutar Docker y te has encontrado con el mensaje "Cannot connect to the Docker daemon"? ("No se puede conectar al demonio de Docker"). Este es uno de los errores más frustrantes porque bloquea todo desde el inicio.
El daemon de Docker es el servicio que funciona en segundo plano y gestiona absolutamente todo: iniciar y detener contenedores, administrar imágenes, construir capas y procesar comandos como docker run, docker ps, entre otros.
Si la terminal no puede comunicarse con él, Docker simplemente deja de funcionar.
En esta guía, se explica por qué ocurre este error y cómo solucionarlo paso a paso con métodos prácticos y efectivos.
¿Qué hace realmente el demonio de Docker?
El Docker daemon (dockerd) es el servicio principal que administra:
- Contenedores
- Imágenes
- Redes
- Volúmenes
- Recursos del sistema
Cuando se ejecuta un comando en la CLI de Docker, este no realiza la acción directamente, sino que envía una solicitud al daemon.
En sistemas Linux, esta comunicación ocurre a través de un socket Unix ubicado en:
/var/run/docker.sock
En entornos como Docker Desktop o WSL, la comunicación se realiza mediante un socket o un canal administrado por una máquina virtual interna.
Si la CLI no puede comunicarse con el daemon, aparece el error:
Cannot connect to the Docker daemon at unix:///var/run/docker.sock.
Is the docker daemon running?
Causas Más Comunes del Error
El problema suele deberse a una interrupción en la cadena de comunicación entre la CLI y el daemon.
Las causas más frecuentes son:
- El servicio Docker no está en ejecución.
- El usuario no tiene permisos sobre el socket.
- El contexto activo de Docker es incorrecto.
- El socket
/var/run/docker.sockno existe o tiene permisos erróneos. - Variables de entorno como
DOCKER_HOSTestán mal configuradas. - Problemas específicos de plataforma (Docker Desktop, WSL, daemon remoto).
Identificar cuál de estos puntos falla es la clave para resolver el error correctamente.
Quizás te interesen Más tutoriales de Docker, más información sobre Docker y Contenedores
1. Verificar permisos de usuario
En sistemas Linux, el socket de Docker pertenece al usuario root. Para poder ejecutar Docker sin sudo, el usuario debe pertenecer al grupo docker.
Comprobar permisos del socket
ls -l /var/run/docker.sock
El resultado mostrará algo similar a:
srw-rw---- 1 root docker ...
Esto significa que solo root y los usuarios del grupo docker pueden acceder.
Añadir el usuario al grupo Docker
sudo usermod -aG docker $USER
Después de ejecutar este comando, es necesario cerrar sesión y volver a entrar para que los cambios surtan efecto.
Si el grupo docker no existe:
sudo groupadd docker
2. Verificar que el Servicio Docker este activo
Una causa extremadamente común es que Docker simplemente no esté ejecutándose.
Comprobar el estado del servicio
systemctl status docker
Si aparece como:
inactive (dead)failed
Significa que el daemon está detenido.
Iniciar el servicio manualmente
sudo systemctl start docker
Habilitar inicio automático al arrancar el sistema
sudo systemctl enable docker
3. Iniciar el Daemon manualmente (dockerd)
En servidores minimalistas o configuraciones personalizadas de Linux, Docker puede no estar gestionado por systemd.
En ese caso, se puede probar iniciar el daemon manualmente:
sudo dockerd
Observar cuidadosamente los mensajes que aparecen en pantalla. Docker suele mostrar errores claros si hay:
- Problemas con el driver de almacenamiento
- Conflictos de red
- Errores de permisos
- Configuraciones corruptas
Este método es especialmente útil para diagnóstico avanzado.
4. Revisar y reparar el Socket de Docker
La CLI depende completamente del archivo:
/var/run/docker.sock
Si este archivo no existe o tiene permisos incorrectos, la conexión falla.
Comprobar si el socket existe
ls /var/run/docker.sock
Si no existe, normalmente significa que el daemon no está corriendo.
Reiniciar Docker para recrear el socket
sudo systemctl restart docker
Corregir permisos del socket
Si el archivo existe pero los permisos son incorrectos:
sudo chown root:docker /var/run/docker.sock
sudo chmod 660 /var/run/docker.sock
Esto asegura que solo root y el grupo docker puedan acceder.
5. Revisar variables de Entorno y contextos Docker
A veces el problema no es el daemon… sino que Docker está intentando conectarse al lugar equivocado.
Verificar variables de entorno
env | grep DOCKER
Si aparece algo como:
DOCKER_HOST=tcp://localhost:2375
Docker está intentando conectarse a un daemon remoto que puede no existir.
Eliminar variable temporalmente
unset DOCKER_HOST
Para eliminarla de forma permanente, revisar y limpiar archivos como:
~/.bashrc~/.zshrc/etc/environment
Revisar el contexto activo de Docker
Los contextos determinan a qué daemon se conecta la CLI.
Listar contextos:
docker context ls
Un asterisco (*) indica el contexto activo.
Si está apuntando a un entorno remoto no disponible, cambiar al local:
docker context use default
6. Problemas específicos en Windows, macOS o WSL
En Docker Desktop, el daemon corre dentro de una máquina virtual ligera. Si la VM no arranca correctamente, la CLI no puede conectarse.
Solución rápida:
Reiniciar Docker Desktop.
Problemas en WSL
Si se usa Docker con WSL, comprobar que la distribución esté activa:
wsl --list --running
Si el daemon no responde:
- Reiniciar Docker Desktop
- Reiniciar la distribución WSL
- Ejecutar
wsl --shutdowny volver a abrir
7. Consejos para evitar el error en el futuro
Para reducir la probabilidad de que vuelva a aparecer:
✔ Verificar que Docker esté activo tras actualizaciones del sistema
✔ Añadir el usuario al grupo docker
✔ Revisar el contexto activo antes de trabajar en entornos remotos
✔ Evitar configurar DOCKER_HOST sin necesidad
✔ Supervisar logs regularmente
Consultar logs del daemon:
journalctl -u docker.service
Esto permite detectar problemas antes de que escalen.
Conclusión
El error “No se puede conectar al demonio de Docker” no suele indicar un problema grave. En la mayoría de los casos se debe a:
- Servicio detenido
- Permisos incorrectos
- Contexto equivocado
- Variables mal configuradas
Comprender cómo se comunica la CLI con el daemon facilita resolver el problema en minutos.
Cuando se entiende la arquitectura interna de Docker, este tipo de errores deja de ser frustrante y se convierte simplemente en una verificación técnica más.