Fix Docker "permission denied /var/run/docker.sock" in 5 Minutes

Fix Docker "permission denied /var/run/docker.sock" in 5 Minutes

Seen that red error message again?

You've SSH'd into a server, typed a casual docker ps, and gotten this:

permission denied while trying to connect to the Docker daemon socket at
unix:///var/run/docker.sock: Get "http://%2Fvar%2Frun%2Fdocker.sock/v1.43/containers/json":
dial unix /var/run/docker.sock: connect: permission denied

So you fall back to sudo docker ps as a temporary workaround, then it fails again on the CI runner... This post is how you break that loop. We'll go error message → root-cause diagnosis → copy-paste commands and get you to a permanent fix in five minutes.

Why it fails — how docker.sock permissions work

Let's look at the culprit first.

ls -l /var/run/docker.sock
# srw-rw---- 1 root docker 0 Jun 24 09:12 /var/run/docker.sock

Breaking down that output explains everything.

• s: not a regular file — a Unix socket
• rw- (owner root) / rw- (group docker) / --- (others): only root or members of the docker group can read and write
• Ownership: root:docker

Docker's daemon (dockerd) runs as root, and the docker CLI is just a client that writes commands to this socket.

[docker CLI] --(소켓에 write)--> /var/run/docker.sock --> [dockerd (root)]
                                  소유권: root:docker
                                  권한:   srw-rw----

So if your account is not a member of the docker group, you can't write to the socket and you get permission denied. The takeaway is simple: docker group membership is the key.

5-minute diagnosis table by cause

Match your symptoms to a case first.

Copy-paste fix commands

Case ① Add yourself to the group

# 현재 그룹 확인
id

# docker 그룹에 현재 유저 추가
sudo usermod -aG docker $USER

# 즉시 반영 (재로그인 대체)
newgrp docker

# 반영 확인 - docker가 보이면 성공
groups

The cleanest approach is exit then reconnect SSH. A new shell starts with the updated group info.

Case ③ When the socket is corrupted

ls -l /var/run/docker.sock          # 상태 확인
sudo chown root:docker /var/run/docker.sock
sudo chmod 660 /var/run/docker.sock
sudo systemctl restart docker       # 데몬 재시작으로 소켓 재생성

Case ④ Rootless Docker

# rootless는 사용자 전용 소켓을 사용
export DOCKER_HOST=unix://$XDG_RUNTIME_DIR/docker.sock
docker context use rootless

"I ran usermod and it still doesn't work" — the most common trap

This is where people get stuck the most. If you've already run usermod -aG docker and still get permission denied, the cause is almost always that your current shell session still has the old group info.

Group membership is baked into the shell at login, so an already-running shell does not update automatically. Compare these two:

id      # 현재 "셸 세션"에 적용된 그룹 → docker 없음
groups  # 마찬가지로 현 세션 기준

getent group docker   # 시스템 DB 기준 → 여기엔 내가 들어있음!

If it shows up in getent but not in id, the session hasn't been refreshed. Fix it with one of these three:

1. newgrp docker — enter a subshell with the new group (immediate)
2. Fully log out and reconnect SSH — most reliable
3. sudo systemctl restart docker then reconnect (also covers socket issues)

Practitioner tip: If you're working inside a tmux/screen session, newgrp alone may not be enough. Kill the session completely and reattach. I once burned 30 minutes because I didn't know this.

Temporary workaround vs permanent fix vs rootless

Environment-specific notes (CI/CD)

• GitHub Actions: Official Ubuntu runners already have permissions set, so it just works. For self-hosted runners, add the runner user with sudo usermod -aG docker <runner-user> and restart the runner service.
• GitLab Runner: If you mount the host socket (-v /var/run/docker.sock:...) instead of DinD (docker:dind), the GID of the user inside the container must match the host docker group's GID.
• Trend: Because of DinD's security and performance cost, BuildKit / socket-mount approaches are becoming more common in CI. Docker Desktop licensing issues have also driven adoption of Podman and colima.

Wrap-up: permanent-fix checklist + security warning

□ id 에 docker 그룹이 보이는가
□ ls -l /var/run/docker.sock 이 srw-rw---- root docker 인가
□ usermod 후 재로그인(또는 newgrp)으로 세션 갱신했는가
□ sudo 없이 docker ps 가 동작하는가

One last point, stated bluntly: a docker group member can mount the host root filesystem (-v /:/host) and effectively seize root. In other words, docker group = root.

So avoid casually adding people to the group on shared or production servers. Prefer rootless Docker or sudo plus audit logging. On a personal dev box, adding the group is the most convenient option — just know what it means.

One-liner: If you're blocked, check the group with id → if missing, usermod -aG docker $USER → re-login → docker ps. Bookmark this so you don't get lost next time.

References: official docs

The primary source for the behavior, settings, and errors in this post is the official documentation below. Check it for version-specific options and exact behavior.

• Docker official documentation

FAQ

Q. I ran usermod and still get permission denied. A. Your current shell still has the old group info. If you're in getent group docker but not in id, the session hasn't been refreshed. Fix it with newgrp docker or a full SSH reconnect.

Q. Is it safe to use Docker without sudo? A. The docker group is effectively equivalent to root. Fine on a personal server; on shared or production servers, prefer rootless Docker or a sudo audit policy.

Q. Do the same commands work on WSL/Mac? A. No. Docker Desktop uses a separate backend, so this is often unrelated to group membership. Check Desktop settings and whether WSL integration is enabled first.