Docker permission denied 해결: daemon socket 에러 sudo 없이 끝내기

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

우분투에 Docker를 막 설치하고 신나게 docker ps를 쳤더니 이 빨간 에러가 떴나요? 축하합니다(?). 거의 모든 리눅스 입문자가 거쳐 가는 통과의례입니다. 일단 급한 분을 위해 결론부터 드리고, 그다음 "왜 이런지"를 차근차근 풀어드릴게요.

일단 복붙: 5분 만에 끝내는 정석 해결

터미널에 아래를 그대로 붙여 넣으세요.

sudo groupadd docker          # 그룹이 없을 때만 (이미 있으면 에러 나도 무시 OK)
sudo usermod -aG docker $USER # 현재 사용자를 docker 그룹에 추가
newgrp docker                 # 재로그인 없이 그룹을 즉시 적용
docker run hello-world        # 검증

hello-world 컨테이너가 정상적으로 인사 메시지를 띄우면 끝입니다. 더 이상 sudo를 붙일 필요가 없어요.

가장 확실한 방법은 로그아웃 후 다시 로그인입니다. newgrp docker는 현재 셸에만 그룹을 적용하는 임시 방편에 가깝고, 완전 로그아웃/재로그인을 해야 모든 새 셸·프로세스에 그룹이 반영됩니다. WSL2라면 wsl --shutdown 후 다시 진입하세요.

에러의 근본 원인: docker.sock의 소유권 구조

이 에러를 이해하려면 딱 한 가지만 알면 됩니다. Docker 데몬(dockerd)은 root 권한으로 백그라운드에서 돌아갑니다. 그리고 우리가 치는 docker 명령어(CLI)는 이 데몬과 직접 대화하지 않고, 유닉스 소켓 파일이라는 창구를 통해 통신합니다. 그 창구가 바로 /var/run/docker.sock입니다.

직접 눈으로 확인해 볼까요?

ls -l /var/run/docker.sock

srw-rw---- 1 root docker 0 Jun 12 09:00 /var/run/docker.sock

한 줄씩 뜯어봅시다.

• 맨 앞 s → 이 파일이 socket이라는 뜻
• rw-rw---- → 소유자(읽기/쓰기), 그룹(읽기/쓰기), 그 외 사용자(권한 없음)
• root → 소유자는 root
• docker → 소유 그룹이 docker

핵심은 마지막 ---- 부분입니다. 그룹에 속하지 않은 일반 사용자에게는 어떤 권한도 없습니다. 즉 여러분이 docker 그룹에 들어 있지 않으면 이 소켓에 접근할 수 없고, 그래서 "permission denied"가 뜨는 거예요. usermod -aG docker $USER가 하는 일이 바로 여러분을 이 docker 그룹에 넣어 주는 것이고, 그러면 그룹 권한 rw-가 적용되어 접근이 풀립니다.

sudo는 왜 임시방편인가

sudo docker ps를 치면 당장은 동작합니다. 하지만 이건 근본 해결이 아니라 매번 root로 우회하는 거예요. 문제점이 세 가지 있습니다.

1. 파일 소유권 꼬임: sudo로 컨테이너를 띄우면 컨테이너가 만든 볼륨 파일·로그가 root 소유로 생성됩니다. 나중에 일반 사용자로 그 파일을 지우거나 수정하려다 또 권한 에러를 만나는 악순환이 생겨요.
2. 보안 노출: root 권한으로 컨테이너를 돌리면 컨테이너 탈출 시 호스트 전체가 위험해집니다.
3. 단순 번거로움: 명령마다 비밀번호 입력은 생산성을 갉아먹죠.

다만 한 가지 꼭 짚고 넘어갈 게 있습니다. docker 그룹에 가입한다는 건 사실상 root급 권한을 갖는 것과 같습니다. Docker 데몬은 root로 돌고, 그룹 멤버는 그 데몬에 명령을 내릴 수 있으니까요. 마음만 먹으면 호스트의 어떤 파일이든 컨테이너로 마운트해 건드릴 수 있습니다. 그래서 신뢰할 수 있는 사용자에게만 docker 그룹을 부여해야 합니다. 공용 서버에서 아무에게나 추가하면 안 돼요.

더 안전한 대안: rootless Docker

보안이 중요한 멀티유저 서버라면 rootless Docker를 고려하세요. 데몬 자체를 일반 사용자 권한으로 돌리는 방식입니다.

dockerd-rootless-setuptool.sh install

2026년 현재는 보안 강화 흐름과 함께 rootless Docker나 Podman(데몬리스·rootless 기본) 채택이 눈에 띄게 늘고 있습니다. 컨테이너 탈출이 발생해도 root가 아닌 일반 사용자 권한으로 제한되니 피해 범위가 훨씬 작아지죠. 개인 개발 환경이라면 굳이 필요 없지만, 여러 사람이 쓰는 서버라면 진지하게 검토할 가치가 있습니다.

환경별 차이 한눈에 보기

이 에러는 사실 네이티브 Linux 고유의 문제에 가깝습니다. 환경별로 정리하면 이렇습니다.

macOS와 Windows의 Docker Desktop은 내부적으로 경량 VM 위에서 데몬을 돌리기 때문에 이 권한 에러를 만날 일이 거의 없습니다. 반면 WSL2는 두 갈래로 나뉩니다. Docker Desktop과 연동한다면 GUI 설정에서 WSL 통합 토글이 관건이고, Docker Desktop 없이 WSL 안에 직접 데몬을 깐다면 우분투와 똑같이 docker 그룹 설정이 필요합니다.

실무 팁 하나: 최근 Docker Desktop의 라이선스 정책 때문에 회사 환경에서 WSL2에 네이티브 데몬을 직접 구성하는 개발자가 부쩍 늘었습니다. 저도 사내 가이드를 그 방향으로 바꿨는데, 이때 가장 흔히 막히는 지점이 바로 이 권한 에러였습니다. WSL은 그룹을 추가해도 적용이 안 되는 경우가 많은데, 대부분 wsl --shutdown으로 인스턴스를 완전히 껐다 켜면 해결됩니다.

그래도 안 될 때: 체크리스트

위 명령을 다 했는데도 여전히 막힌다면 아래를 순서대로 확인하세요.

systemctl status docker        # 1. 데몬이 살아있는지 확인 (active 인지)
sudo systemctl start docker    # 2. 죽어 있으면 시작
sudo systemctl enable docker   # 3. 부팅 시 자동 시작 등록
ls -l /var/run/docker.sock     # 4. 소켓 퍼미션·소유권 확인 (root docker)
groups                         # 5. 출력에 docker가 보이는지 확인

• groups 출력에 docker가 안 보이면 → 그룹이 아직 셸에 반영되지 않은 것. 완전 로그아웃 후 재로그인하세요.
• WSL이라면 → PowerShell에서 wsl --shutdown 후 다시 진입.
• systemctl status docker에서 데몬이 죽어 있으면 → 권한 문제가 아니라 데몬 자체가 안 떠 있는 것이니 start부터.

결론: 핵심 3줄 요약

1. 원인: /var/run/docker.sock이 root:docker 소유라, docker 그룹에 없는 사용자는 접근 불가.
2. 해결: sudo usermod -aG docker $USER 후 재로그인(또는 newgrp docker).
3. 주의: sudo는 임시방편, docker 그룹은 root급 권한이니 신뢰된 사용자에게만. 보안이 중요하면 rootless Docker/Podman을 검토.

자주 묻는 질문 (FAQ)

Q. usermod -aG docker $USER를 했는데도 여전히 permission denied가 떠요. A. 그룹 변경은 현재 셸에 즉시 반영되지 않습니다. newgrp docker로 임시 적용하거나, 가장 확실하게는 완전히 로그아웃 후 다시 로그인하세요. WSL2라면 wsl --shutdown 후 재진입이 필요합니다.

Q. 그냥 매번 sudo docker를 쓰면 안 되나요? A. 동작은 하지만 권장하지 않습니다. 컨테이너가 생성하는 파일이 root 소유가 되어 나중에 권한이 꼬이고, 보안상으로도 좋지 않습니다. 한 번만 docker 그룹에 가입해 두면 그 뒤로는 sudo 없이 깔끔하게 쓸 수 있습니다.

Q. docker 그룹에 넣는 게 위험하다는데 어느 정도인가요? A. docker 그룹 멤버는 사실상 호스트 root와 동등한 권한을 갖습니다. 호스트 파일시스템을 컨테이너로 마운트해 무엇이든 할 수 있기 때문입니다. 개인 PC에서는 괜찮지만, 여러 사람이 쓰는 서버에서는 신뢰된 사용자에게만 부여하고 rootless Docker를 고려하세요.