기술 · 실용 가이드

Docker daemon socket 권한이 거부되나요? 클라이언트·소켓·데몬 경계를 먼저 증명하세요

docker.sock을 666/777로 만들지 마세요. 클라이언트 신원, Docker context와 실제 소켓을 보존하고 rootful·rootless·컨테이너 마운트를 구분한 뒤 필요한 주체만 승인하세요.

작성 Watch at Ease News · 3 분 읽기발행 2026. 10. 17. 오후 10:36 UTC

Docker Unix 소켓의 permission denied는 클라이언트 프로세스가 pathname 경계를 넘지 못했다는 뜻입니다. 데몬 중지나 /var/run/docker.sock 선택을 증명하지 않습니다.

클라이언트 신원, context, DOCKER_HOST, 소켓 메타데이터를 보존하세요. rootful host daemon, rootless user daemon, 컨테이너의 마운트 소켓을 분류한 뒤 접근을 바꿉니다.

클라이언트 신원과 선택 endpoint 보존

전체 오류, command, UID와 보조 group을 기록합니다. sudo나 group 변경 전 docker context show, DOCKER_HOST와 해결된 endpoint를 저장합니다.

정확한 pathname의 owner, group, mode와 상위 directory를 이름과 숫자로 확인합니다. 경로 없음은 다른 분기입니다.

rootful Linux daemon은 root 소유 socket을 docker group에 열 수 있습니다. 이 group은 일반 편의 group이 아니라 특권 관리입니다.

rootless는 user socket과 context를 확인합니다. CI나 application container에서는 mount된 host socket과 namespace를 분리합니다.

socket 숫자 GID와 실제 Docker를 실행하는 process group을 비교합니다. /etc/group 변경은 기존 shell, IDE, agent, daemon 자격을 바꾸지 않습니다.

mount socket 양쪽의 docker 이름이 같아도 번호는 다를 수 있습니다. host socket 소유자를 application account로 바꾸지 말고 caller 경계에서 GID를 매핑합니다.

rootful group 접근이 승인됐다면 필요한 사람이나 service만 추가하고 해당 session을 새로 만듭니다. 영구 root 동등 접근이 넓다면 rootless나 격리 환경을 검토합니다.

chmod 666/777을 영구 해결책으로 쓰지 마세요. world-write는 무관한 local process에 강력한 API를 열고 daemon restart가 socket을 다시 만들 수 있습니다.

같은 caller에서 docker context show와 docker info 또는 docker version을 실행해 context, server와 rootless option을 확인합니다. sudo만 성공하면 자격 차이만 증명됩니다.

승인된 workload 하나를 실행합니다. non-world-write socket이 의도한 주체에만 작동하고 무관한 비특권 주체는 거부해야 완료입니다.