Docker permission denied: cómo solucionarlo

Docker permission denied aparece normalmente cuando tu usuario no puede hablar con el socket del daemon Docker. El error no significa siempre que Docker esté mal instalado: muchas veces es un problema de permisos, sesión de usuario, grupo docker o contexto equivocado.

En esta lección vas a diagnosticarlo sin aplicar comandos a ciegas. Verás qué comprobar, cómo corregirlo en Linux, cuándo usar sudo de forma temporal y por qué meter un usuario en el grupo docker tiene implicaciones de seguridad importantes.

👉 Y recuerda, si quieres aprender más de Linux, visita el curso de Linux gratis.

🐳 Si quieres aprender más de Docker, visita el curso de Docker gratis.

Docker permission denied: cómo solucionarlo

El mensaje típico suele apuntar al socket de Docker. Ese socket es la puerta local para pedirle al daemon que cree contenedores, descargue imágenes, monte volúmenes o publique puertos. Por eso Docker protege ese acceso con permisos del sistema.

permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock

permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock

Causa probable	Qué ocurre	Solución habitual
Usuario fuera del grupo docker	La CLI existe, pero no puede acceder al socket.	Añadir el usuario al grupo y abrir una sesión nueva.
Sesión antigua	Ya añadiste el grupo, pero tu terminal no lo ve.	Cerrar sesión o usar newgrp para probar.
Daemon parado	No hay servicio Docker atendiendo peticiones.	Arrancar el servicio y revisar estado.
Contexto equivocado	La CLI apunta a otro endpoint o Docker rootless.	Revisar docker context y DOCKER_HOST.
Permisos tocados a mano	El socket tiene propietario o grupo inesperado.	No hacer chmod 666; restaurar configuración correcta.

Antes de tocar permisos

No empieces con chmod ni con soluciones copiadas. Primero identifica si el problema es de usuario, daemon o contexto. Estos comandos solo consultan información y no cambian la configuración.

id
getent group docker
stat -c '%A %U %G %n' /var/run/docker.sock
docker context ls
docker version

id
getent group docker
stat -c '%A %U %G %n' /var/run/docker.sock
docker context ls
docker version

id muestra los grupos activos de tu sesión actual.
getent group docker confirma si existe el grupo docker y qué usuarios pertenecen a él.
stat permite ver propietario, grupo y permisos del socket.
docker context ls indica a qué endpoint apunta tu CLI.
docker version separa cliente y servidor; si falla la parte Server, el problema está en la conexión con el daemon.

Solución segura con grupo docker

En una instalación típica de Docker Engine en Linux, el socket suele pertenecer a root y al grupo docker. Si confías en ese usuario para administrar Docker, puedes añadirlo al grupo y abrir una sesión nueva.

sudo usermod -aG docker $USER
newgrp docker
docker run --rm hello-world

sudo usermod -aG docker $USER
newgrp docker
docker run --rm hello-world

El paso importante es la sesión. Si ejecutas usermod y sigues en la misma terminal, puede que el grupo todavía no aparezca en id. Cierra sesión y vuelve a entrar, o usa newgrp docker para probar en una shell nueva.

Advertencia de seguridad

Pertenecer al grupo docker equivale en la práctica a tener privilegios muy altos sobre la máquina. Un usuario con acceso a Docker puede montar rutas del host o ejecutar contenedores privilegiados. No añadas usuarios al grupo docker si no deben administrar el sistema.

Cuando el daemon no está activo

A veces el mensaje se mezcla con errores de conexión porque el servicio no está arrancado. En sistemas con systemd, revisa el estado antes de culpar a los permisos.

sudo systemctl status docker --no-pager
sudo systemctl enable --now docker
docker version

sudo systemctl status docker --no-pager
sudo systemctl enable --now docker
docker version

Si el servicio falla al arrancar, no lo tapes con permisos más abiertos. Revisa logs del servicio, configuración del daemon y cambios recientes. En esta lección nos centramos en el caso básico; el diagnóstico profundo pertenece a una lección de troubleshooting.

Sudo, rootless y errores que debes evitar

Usar sudo delante de docker puede servir como prueba temporal: si con sudo funciona y sin sudo falla, probablemente el problema sea de permisos del usuario. Pero no conviene convertir sudo en la solución permanente sin entender el motivo.

docker context ls
systemctl --user status docker --no-pager
printenv DOCKER_HOST

docker context ls
systemctl --user status docker --no-pager
printenv DOCKER_HOST

No uses chmod 666 /var/run/docker.sock. Abre el socket a cualquier usuario local y aumenta mucho el riesgo.
No mezcles Docker rootless y Docker Engine clásico sin revisar contextos.
No cambies propietario o grupo del socket a mano como solución permanente.
No añadas usuarios al grupo docker en servidores compartidos sin política clara.
Si estás en WSL, Docker Desktop o un entorno remoto, revisa el contexto antes de aplicar pasos de Linux clásico.

Errores comunes

Añadir el usuario al grupo docker y no cerrar sesión.
Comprobar grupos con una terminal antigua y creer que usermod no funcionó.
Dar permisos globales al socket para salir del paso.
Confundir daemon parado con problema de permisos.
Copiar comandos de rootless Docker en una instalación clásica, o al revés.
No leer el error completo: socket local, contexto remoto y Docker Desktop pueden requerir soluciones distintas.

La regla práctica es: primero observa, después cambia. Si sabes qué usuario ejecuta Docker, a qué socket apunta y qué permisos tiene ese socket, la solución deja de ser una apuesta.