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

Linux에서 Docker 명령이 daemon socket에 연결하려다 permission denied를 반환하면 먼저 현재 클라이언트가 어느 데몬에 연결하는지, 소켓을 누가 소유하는지 확인한다. 일반적인 rootful Docker Engine에서는 docker 그룹 접근을 부여할 수 있지만, 이는 사실상 호스트 root 권한과 같으므로 신뢰할 수 있는 사용자에게만 허용해야 한다.

Linux 서버의 Docker 소켓 접근을 표현한 개념 이미지다. 실제 화면은 아니다.

이 글은 Linux의 로컬 Docker Engine을 중심으로 한다. Docker Desktop, rootless 모드, 원격 데몬은 소켓 경로와 권한 경계가 다르다. 명령은 공식 문서 기반 진단 예시이며 실제 Docker 데몬에서 실행하지 않았다. 기준일은 2026-11-08이다.

1. 먼저 연결 대상과 오류를 구분한다

context와 DOCKER_HOST가 가리키는 대상부터 확인한다. 위 소켓 경로는 기본 rootful Linux 설정의 예이며, 다른 context나 환경변수가 선택한 원격·rootless 소켓에 그대로 적용하면 안 된다. docker version에서 Client만 보이고 Server에 오류가 생긴다면 클라이언트 자체의 설치 여부와 서버 접근을 나누어 확인한다. Docker contexts

permission denied는 소켓 접근 권한 문제를 시사하지만, cannot connect는 데몬 중지, 잘못된 경로 등 다른 원인일 수도 있다. systemd를 사용하는 로컬 Engine이라면 systemctl status docker로 서비스를 확인한다. 시스템에 따라 서비스 관리 방식이 다르므로 무조건 systemctl로 고치려 하지 않는다. 데몬 시작

2. rootful 소켓의 그룹 권한을 확인한다

Docker의 기본 Unix 소켓은 root가 소유하고 일반적으로 docker 그룹에 접근을 허용한다. ls -l에 표시된 실제 그룹과 id에 표시된 현재 세션의 그룹을 비교한다. docker 그룹에 추가할지는 관리자와 보안 정책에 따라 결정한다. Linux 설치 후 설정

그룹 변경은 기존 로그인 세션에 자동 반영되지 않을 수 있다. SSH 세션을 포함해 다시 로그인한 후 확인한다. 문서는 newgrp docker도 제시하지만 현재 셸의 그룹 상태를 바꾸는 방식이므로 필요한 범위에서 사용한다. VM에서는 재시작이 필요할 수도 있다.

docker 그룹은 제한된 일반 사용자 권한이 아니다. rootful 데몬을 제어하는 사용자는 호스트에 대한 root 수준 권한을 얻을 수 있다. 공용 서버에서는 임의로 그룹을 확대하지 말고 관리자에게 필요한 작업을 요청하거나 별도 격리 환경을 사용한다. chmod 666 /var/run/docker.sock으로 모든 사용자에게 접근을 열지 않는다. Docker 보안

3. rootless와 Desktop은 별도로 확인한다

rootless Docker는 데몬과 컨테이너를 일반 사용자 권한의 사용자 네임스페이스에서 실행한다. 전용 사용자 서비스와 소켓을 사용하므로 rootful의 /var/run/docker.sock 그룹을 변경해도 해결되지 않을 수 있다. 설치 도구가 구성한 context와 systemctl --user status docker를 확인하고, 환경변수로 다른 데몬을 가리키는지 점검한다. rootless 설정에는 subordinate UID/GID 등 전제 조건과 기능상 제한이 있다. Rootless mode · 문제 해결

Docker Desktop이나 WSL 통합을 사용한다면 선택한 context와 Desktop 실행 상태, 해당 배포판의 통합 설정을 확인한다. 운영체제별 설치 방식은 서로 다르므로 rootful Linux Engine의 소켓 권한 명령을 그대로 복사하지 않는다. Docker Desktop WSL

4. 변경 후 다시 확인한다

새 세션에서 id와 docker context show, docker version을 다시 실행한다. 예상한 그룹이 보이고 Server 정보가 반환되는지 확인한다. 여전히 실패하면 오류에 나온 실제 소켓 경로, 소유권, 선택된 context, 데몬 상태를 함께 확인한다. rootful에서 sudo docker version만 성공한다면 권한 문제의 단서가 되지만, sudo는 다른 환경변수나 context를 사용할 수 있으므로 같은 데몬인지 확인해야 한다.

과거에 sudo로 CLI를 실행해 ~/.docker/config.json의 소유자가 root가 된 경우에는 별도의 설정 파일 권한 오류가 나타날 수 있다. 해당 경로의 소유권을 먼저 살펴보고 Docker 문서의 수정 절차를 따른다. 설정 디렉터리를 무작정 삭제하면 기존 설정이 사라진다. 설정 파일 권한

English version: Docker Daemon Socket Permission Denied: Check Linux Permissions and Context