Docker: docker 데몬 소켓에 연결할 수 없음 (unix:///var/run/docker.sock)

안녕하세요, BlueByte입니다. docker ps나 docker build가 Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?로 멈추면, Docker CLI 자체는 정상입니다 — 모든 명령을 넘겨주는 백그라운드 서비스(데몬)에 닿지 못한 것뿐입니다. 증상은 아무 docker 명령이나 즉시 그 줄과 함께 실패하거나, 가까운 사촌 격인 permission denied while trying to connect to the Docker daemon socket으로 실패하는 것입니다. 오늘은 소켓이 무엇인지, CLI가 소켓에 닿지 못하는 세 가지 이유, 어느 쪽인지 확인하는 법, 원인별 해결과 예방까지 하나씩 짚어보겠습니다.

이 메시지와 permission-denied 변형이 알려주는 것

입력하는 docker 명령은 클라이언트일 뿐입니다. 이 명령은 /var/run/docker.sock의 Unix 소켓을 통해 오래 떠 있는 데몬과 대화하며, 모든 build·run·ps는 사실 그 소켓을 건너 보내는 요청입니다. 두 에러 문자열은 요청이 도착하지 못했음을 뜻합니다:

Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?

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

비슷해 보이지만 원인은 다릅니다. 첫 번째는 아무도 응답하지 않았다는 뜻 — 데몬이 꺼져 있거나 CLI가 엉뚱한 엔드포인트를 향한 것입니다. 두 번째는 데몬이 떠 있고 응답했지만 커널이 소켓 파일에 대한 당신의 접근을 거부한 것입니다. 무엇을 바꾸기 전에 어느 쪽을 받았는지 먼저 읽으세요.

CLI가 소켓에 닿지 못하는 세 가지 이유

두 변형 모두 다음 중 하나로 귀결됩니다:

• 데몬이 실행 중이 아님 — docker 서비스가 멈췄거나 실패해 소켓에 리스너가 없습니다.
• 사용자가 docker 그룹에 없음 — 데몬은 떠 있지만 소켓 소유자가 root:docker라 당신 계정이 열 수 없어 permission denied가 납니다.
• CLI가 엉뚱한 엔드포인트를 향함 — Docker context나 남아 있는 DOCKER_HOST가 존재하지 않는 원격·rootless 소켓으로 명령을 보냅니다.

먼저, 데몬이 정말 실행 중인지 확인하기

짐작하지 말고 systemd에 물어보세요:

sudo systemctl status docker

● docker.service - Docker Application Container Engine
     Loaded: loaded (/lib/systemd/system/docker.service; enabled)
     Active: inactive (dead) since Mon 2026-09-15 09:02:11 KST

Active: inactive (dead)나 failed면 데몬이 꺼진 것 — 그게 Cannot connect의 원인입니다. active (running)이면 데몬은 정상이고 문제는 아래의 권한이나 context입니다.

멈춘 데몬 고치기: 시작하고 부팅 시 자동 시작으로 설정

서비스를 시작하고, 재부팅에 발목 잡히지 않도록 자동으로 올라오게 설정하세요:

sudo systemctl start docker
sudo systemctl enable docker.service

Active: active (running) since Mon 2026-09-15 09:05:40 KST

start가 실패하면 journalctl -u docker --no-pager -n 50으로 로그를 읽으세요 — 잘못된 /etc/docker/daemon.json이 데몬이 올라오지 못하는 흔한 이유입니다.

permission denied 고치기: 사용자를 docker 그룹에 추가

데몬이 실행 중인데 permission denied가 나면 당신 계정이 root 소유 소켓을 열 수 없는 것입니다. 자신을 docker 그룹에 넣고 그룹 멤버십을 다시 읽어들이세요:

sudo usermod -aG docker $USER
newgrp docker

newgrp docker는 전체 로그아웃 없이 현재 셸에 새 그룹을 적용합니다. 분명히 짚어둘 점 하나 — docker 그룹은 root 수준 권한을 부여합니다. 그룹에 속한 누구든 호스트 전체를 마운트하는 컨테이너를 띄울 수 있으니 신뢰하는 사용자만 추가하세요.

엉뚱한 context나 DOCKER_HOST를 향한 CLI 고치기

데몬이 떠 있고 그룹에도 속했는데 여전히 연결하지 못하면 CLI가 다른 곳을 향하는 것일 수 있습니다. context를 나열해 무엇이 활성인지 보세요:

docker context ls

NAME       DESCRIPTION   DOCKER ENDPOINT               ERROR
default *                unix:///var/run/docker.sock
remote                   tcp://10.0.0.9:2375

*가 활성 context를 표시합니다. 닿지 않는 원격·rootless context에 가 있으면 되돌리세요:

docker context use default

남아 있는 override도 확인하세요 — echo $DOCKER_HOST. 의도치 않게 설정된 tcp://나 rootless unix://.../docker.sock가 찍히면 unset DOCKER_HOST 후 다시 시도하세요.

실제 사례: sudo로는 되는데 그냥은 안 될 때

Docker를 설치하고 docker ps를 실행하면 permission denied while trying to connect to the Docker daemon socket이 납니다. sudo docker ps는 되니 데몬은 실행 중이고 당신 계정만 접근 권한이 없다는 뜻입니다. 모든 명령 앞에 sudo를 붙이는 대신 sudo usermod -aG docker $USER와 newgrp docker를 실행합니다. 이제 셸이 docker 그룹을 지녀 소켓을 열 수 있으니 docker ps가 sudo 없이 동작합니다.

소켓이 끝까지 응답하는지 확인하기

클라이언트·소켓·데몬 전체 경로가 도는지 증명하세요:

docker run hello-world

Hello from Docker!
This message shows that your installation appears to be working correctly.

docker version은 조용한 확인법입니다 — Client 섹션만이 아니라 Server 섹션까지 찍히면 CLI가 데몬에 닿은 것입니다. Server 블록이 없으면 아직 연결되지 않은 것입니다.

재발을 막기 — 그리고 "Error response from daemon"과의 차이

재부팅에도 살아남도록 서비스를 enable(systemctl enable docker.service)하고, 평소 쓰는 사용자를 docker 그룹에 유지하고, 셸 프로필에 DOCKER_HOST를 전역으로 설정해 모든 프로젝트를 조용히 리다이렉트하는 일을 피하세요. 끝으로 이것을 docker: Error response from daemon: ...과 혼동하지 마세요. 그 메시지는 CLI가 데몬에 닿았다는 뜻입니다 — 연결은 됐고 데몬이 특정 요청(잘못된 이미지 이름, 포트 충돌)을 거부한 것입니다. Error response from daemon이 보이면 소켓 보기를 멈추세요. 연결은 정상이고 문제는 명령 자체입니다.