Docker permission denied 오류 해결법: docker 그룹 추가로 sudo 없이 실행하기

Docker 명령어를 실행할 때 "permission denied while trying to connect to the Docker daemon socket" 오류가 발생한다면, /var/run/docker.sock 파일에 대한 접근 권한이 없기 때문입니다. 이 문제는 일반 사용자 계정이 docker 그룹에 속하지 않아 발생하며, sudo 없이 Docker를 사용하려면 사용자 그룹 설정을 변경해야 합니다. 이 글에서는 문제의 원인을 진단하고, 세 가지 해결 방법 중 가장 안전하고 권장되는 방식을 제시합니다.


Docker permission denied while trying to connect 에러 3가지 해결책 비교




1. 문제 원인 진단: docker.sock 권한 확인

먼저 Docker daemon socket 파일의 권한을 확인합니다.

ls -lart /var/run/docker.sock

출력 결과는 다음과 같은 형태입니다.

srw-rw---- 1 root docker 0 Jan 15 10:00 /var/run/docker.sock

권한 구조를 분석하면 다음과 같습니다.

  • s: 소켓 파일 타입
  • 소유자(root): rw- (읽기/쓰기 가능)
  • 그룹(docker): rw- (읽기/쓰기 가능)
  • 일반 사용자: --- (권한 없음)

이 설정에서 일반 사용자는 docker 그룹에 속하지 않으면 docker.sock에 접근할 수 없습니다. 따라서 현재 사용자를 docker 그룹에 추가하는 것이 핵심 해결책입니다.

2. 세 가지 해결 방법 비교

Docker daemon socket 접근 권한 문제를 해결하는 방법은 세 가지가 있습니다.

방법 1: 파일 권한 변경 (비권장)

sudo chmod 666 /var/run/docker.sock
  • 장점: 즉시 적용되며 재로그인 불필요
  • 단점: 모든 사용자가 Docker daemon에 접근 가능해져 보안상 심각한 위험 발생
  • 결론: 개발 환경에서도 권장하지 않음

방법 2: 파일 소유자/그룹 변경

sudo chown 사용자명:docker /var/run/docker.sock
  • 장점: 특정 사용자에게만 권한 부여
  • 단점: Docker 서비스 재시작 시 소유자가 root로 초기화될 수 있음
  • 결론: 임시 해결책으로만 사용 가능

방법 3: 사용자를 docker 그룹에 추가 (권장)

sudo usermod -aG docker $USER
  • 장점: 영구적이고 안전한 해결책, 시스템 재부팅 후에도 유지됨
  • 단점: 그룹 변경 사항을 반영하려면 재로그인 필요
  • 결론: 프로덕션 및 개발 환경 모두에서 권장되는 표준 방식

3. 권장 해결 방법: docker 그룹 추가 (단계별 가이드)

다음 절차를 순서대로 진행하십시오.

Step 1: docker 그룹 생성 (그룹이 없는 경우)

sudo groupadd docker

대부분의 Docker 설치 환경에서는 이미 docker 그룹이 존재하므로 이 단계는 생략 가능합니다. cat /etc/group | grep docker로 확인할 수 있습니다.

Step 2: 현재 사용자를 docker 그룹에 추가

sudo usermod -aG docker $USER

또는 사용자명을 명시적으로 지정할 수 있습니다.

sudo usermod -aG docker [사용자이름]

usermod 옵션 설명:

  • -a: append 모드로, 기존 보조 그룹을 유지하면서 새 그룹 추가
  • -G: 보조 그룹(Secondary Groups) 지정
  • 주의: -a 없이 -G만 사용하면 기존 보조 그룹이 모두 삭제되고 지정한 그룹으로 대체됨

대안으로 gpasswd 명령을 사용할 수도 있습니다.

sudo gpasswd -a $USER docker

Step 3: Docker 서비스 재시작 (선택 사항)

sudo service docker restart

일부 환경에서는 Docker daemon을 재시작해야 변경 사항이 즉시 반영됩니다.

Step 4: 재로그인 (필수)

그룹 변경 사항은 현재 세션에 즉시 반영되지 않습니다. 반드시 다음 중 하나를 실행하십시오.

  • SSH 접속 환경: exit 후 재접속
  • 로컬 터미널: 터미널 종료 후 재시작
  • 또는 su - $USER 명령으로 새 세션 시작

Step 5: 그룹 추가 확인

groups

출력 결과에 docker가 포함되어 있는지 확인합니다. 또는 id 명령으로 UID, GID, 보조 그룹 정보를 모두 확인할 수 있습니다.

id

Step 6: Docker 명령 실행 테스트

docker version
docker run hello-world

sudo 없이 명령이 정상 실행되면 설정이 완료된 것입니다.

4. 추가 인사이트: Primary Group vs Secondary Groups

Linux 그룹 시스템을 이해하면 권한 문제를 더 효과적으로 해결할 수 있습니다.

  • Primary Group: 사용자가 반드시 하나 가지는 기본 그룹. 파일이나 디렉토리 생성 시 소유 그룹이 됩니다. usermod -g로 변경합니다.
  • Secondary Groups: 사용자가 여러 개 가질 수 있는 보조 그룹. 파일 접근 권한 판단 시 Primary와 Secondary 모두 고려됩니다. usermod -aG로 추가합니다.

Docker 그룹은 Secondary Group으로 추가하는 것이 일반적이며, 이는 사용자의 Primary Group(보통 사용자명과 동일)을 변경하지 않으면서 Docker 권한만 추가하는 안전한 방식입니다.

/etc/group 파일 구조:

그룹이름:비밀번호:GID:사용자목록

예시:

docker:x:999:ubuntu,developer

이 경우 docker 그룹(GID 999)에 ubuntu와 developer 사용자가 속해 있습니다.

5. 트러블슈팅: 재로그인 후에도 문제가 지속되는 경우

다음 체크리스트를 확인하십시오.

  • 그룹 추가 확인: groups 명령 결과에 docker가 없다면 usermod 명령이 제대로 실행되지 않은 것입니다. 명령을 다시 실행하십시오.
  • Docker daemon 상태: sudo systemctl status docker로 Docker 서비스가 정상 실행 중인지 확인합니다.
  • docker.sock 파일 존재 여부: ls -l /var/run/docker.sock로 파일이 존재하는지 확인합니다. 파일이 없다면 Docker가 제대로 설치되지 않았거나 실행되지 않은 것입니다.
  • SELinux/AppArmor: 보안 모듈이 활성화된 환경에서는 추가 정책 설정이 필요할 수 있습니다. sudo aa-status 또는 getenforce로 확인하십시오.
  • 재부팅: 모든 방법이 실패하면 시스템을 재부팅하여 모든 세션과 프로세스를 초기화합니다.

결론

Docker daemon socket 권한 오류는 사용자를 docker 그룹에 추가하는 것으로 안전하고 영구적으로 해결할 수 있습니다. chmod 666 같은 방법은 보안 위험이 크므로 절대 사용하지 마십시오. usermod -aG 명령 후 반드시 재로그인하여 그룹 변경 사항을 반영하고, groups 명령으로 확인하는 습관을 들이십시오.

Action Item: 지금 바로 터미널에서 sudo usermod -aG docker $USER를 실행하고, 재로그인 후 docker version으로 sudo 없이 명령이 실행되는지 확인하십시오.


#함께 읽으면 좋은 글

AWS vs Azure vs GCP 프리티어 비교 2025년 VM 성능 실측과 과금 함정 정리 : 바로보기


댓글