Huny's Dev Blog
huny.dev

Docker Daemon Socket Permission Denied: Check Linux Permissions and Context

Diagnose Docker socket permission errors by checking context and daemon status, docker group security, and rootless or Desktop setups.

Hun Jang
Hun Jang Nov 8, 2026

When a Docker command on Linux reports permission denied while connecting to the daemon socket, first identify the daemon selected by the client and inspect the socket's ownership. On a typical rootful Docker Engine, access can be granted through the docker group, but that access is effectively root-level access to the host and should be limited to trusted users.

Concept illustration of Docker socket access on a Linux server, not a product screenshot.

This article focuses on a local Docker Engine on Linux. Docker Desktop, rootless mode, and remote daemons have different socket paths and security boundaries. The commands are diagnostic examples based on official documentation; they were not run against a Docker daemon. Documentation checked on 2026-11-08.

1. Identify the target and distinguish the error

Check the target selected by the context and DOCKER_HOST first. The socket path above is an example of the default rootful Linux configuration; do not assume it applies to a remote or rootless socket selected by a different context or environment variable. If docker version displays Client information but reports a Server error, distinguish client installation from server access. Docker contexts

Permission denied suggests a socket access problem. Cannot connect can also mean the daemon is stopped or the path is wrong. On a local Engine managed by systemd, inspect the service with systemctl status docker. Service management differs across systems, so do not assume systemctl is always the fix. Start the daemon

2. Check group access to the rootful socket

Docker's default Unix socket is owned by root and is normally accessible to the docker group. Compare the actual group shown by ls -l with the groups in the current session shown by id. Decide whether group membership is appropriate with the administrator and according to the security policy. Linux post-installation steps

A group change may not apply automatically to existing login sessions. Log in again, including SSH sessions, before checking. The documentation also describes newgrp docker, which changes the group state of the current shell; use it only within the intended scope. A virtual machine may need a restart.

Membership in the docker group is not a limited unprivileged permission. A user controlling a rootful daemon can obtain root-level host access. On a shared server, do not expand membership casually: ask an administrator to perform the required work or use a separate isolated environment. Do not open the socket to everyone with chmod 666 /var/run/docker.sock. Docker security

3. Treat rootless and Desktop setups separately

Rootless Docker runs both daemon and containers in a user namespace without root privileges. It uses a dedicated user service and socket, so changing the group on the rootful /var/run/docker.sock may not help. Check the context configured by the setup tool and systemctl --user status docker, and verify that environment variables do not select another daemon. Rootless setup has prerequisites, including subordinate UID/GID mappings, and functional limitations. Rootless mode · Troubleshooting

For Docker Desktop or WSL integration, check the selected context, whether Desktop is running, and integration settings for the distribution. Installation differs by operating system; do not copy socket permission commands for a rootful Linux Engine without checking the setup. Docker Desktop WSL

4. Verify after the change

In a new session, rerun id, docker context show, and docker version. Check that the expected group appears and Server information is returned. If it still fails, inspect the actual socket path in the error, its ownership, the selected context, and daemon status together. If only sudo docker version works on a rootful setup, it is a clue about permissions, but sudo may use different environment variables or a different context; confirm that both commands target the same daemon.

If previous sudo CLI use made root the owner of ~/.docker/config.json, a separate configuration file permission error can occur. Inspect the ownership first and follow Docker's documented repair. Deleting the configuration directory indiscriminately also removes existing settings. Configuration file permissions

한국어 버전: Docker daemon socket permission denied 해결: Linux 권한과 context 확인하기Docker daemon socket permission denied 해결: Linux 권한과 context 확인하기

추천 글