Introduction
Rootless Docker shifts the daemon and socket into the user’s session space. That improves security, but it also means the client now depends on the user service model, runtime directory, and per-user socket ownership being correct. When those assumptions break, Docker commands fail with socket permission errors even though “Docker is installed” and may have worked earlier.
Symptoms
docker psreports permission denied against the rootless socket- The client points at
/run/user/<uid>/docker.sockbut cannot connect - Rootless Docker worked before logout, reboot, or system update and now fails
systemctl --user status dockershows the user daemon missing or inactive
Common Causes
- The rootless Docker daemon is not running
DOCKER_HOSTorXDG_RUNTIME_DIRpoints at the wrong socket location- The socket is owned by another user or stale runtime state
- Rootless dependencies or user session behavior changed after an update
Step-by-Step Fix
- 1.Check the user-level Docker service
- 2.Rootless Docker should normally run as a user service, not as a system-wide daemon with guessed environment variables.
systemctl --user status docker- 1.Verify socket path and ownership
- 2.The socket should live under the current user’s runtime directory and be owned by that user.
echo $DOCKER_HOST
echo $XDG_RUNTIME_DIR
ls -la /run/user/$(id -u)/docker.sock- 1.Restart the rootless daemon in the correct session context
- 2.If the user service is down, bring it back in the current session instead of trying to use the root daemon path by accident.
systemctl --user restart docker- 1.Reinstall or reinitialize rootless mode only if the setup is actually broken
- 2.Many incidents are environment or service-state issues rather than installation defects.
Prevention
- Enable the rootless daemon as a persistent user service
- Keep
DOCKER_HOSTandXDG_RUNTIME_DIRconsistent in shells and CI - Monitor rootless service health after reboots and user-session changes
- Document the expected socket path for operators using rootless Docker