rootful containerd에서 sudo 없이 nerdctl 쓰려다 실패한 기록

containerd를 직접 쓰기 시작하면 자연스럽게 이런 생각이 든다.

Docker는 docker 그룹에 사용자만 추가하면 sudo 없이 쓸 수 있는데,
nerdctl도 비슷하게 할 수 있지 않을까?

나도 같은 생각으로 rootful containerd 환경에서 일반 사용자 계정으로 sudo 없이 nerdctl을 쓰려고 시도했다.

결론부터 말하면,

내 환경에서는 원하는 방식이 성립하지 않았다.

이 글은 그 과정을 정리한 기록이다.

---

목표

내가 원한 것은 아래 3가지를 동시에 만족하는 구성이었다.

• containerd는 기존처럼 rootful 유지
• 일반 사용자 계정에서 sudo 없이 nerdctl 실행
• Docker의 docker 그룹처럼 socket 권한 기반으로 해결

즉, rootless로 전환하는 것이 아니라 기존 system containerd를 유지하면서 일반 사용자에게 socket 접근 권한만 열어주는 방식을 원했다.

---

처음에 생각한 방법

접근 방식 자체는 단순했다.

1. containerd 전용 그룹 생성
2. 일반 사용자를 해당 그룹에 추가
3. /run/containerd/containerd.sock의 그룹을 containerd로 변경
4. socket 권한을 660으로 맞춰 일반 사용자가 접근 가능하게 설정

예를 들면 이런 식이다.

sudo groupadd containerd
sudo usermod -aG containerd $USER

처음 생각에는 Docker와 크게 다르지 않아 보였다.

---

containerd socket 권한 변경에 사용한 파일

containerd는 systemd 서비스로 올라오기 때문에, socket 권한을 맞추려면 systemd override 파일을 써야 했다.

내가 사용한 파일 위치는 다음과 같다.

/etc/systemd/system/containerd.service.d/override.conf

디렉토리가 없다면 먼저 생성해야 한다.

sudo mkdir -p /etc/systemd/system/containerd.service.d
sudo vi /etc/systemd/system/containerd.service.d/override.conf

---

내가 실제로 넣은 override 설정

처음에는 단순히 ExecStartPost=/bin/chgrp ... 정도만 생각했지만, 실제로는 socket 생성 타이밍 때문에 바로 실패할 수 있어서 아래처럼 작성했다.

[Service]
ExecStartPost=
ExecStartPost=/bin/sh -c 'for i in $(seq 1 50); do [ -S /run/containerd/containerd.sock ] && break; sleep 0.1; done; /bin/chgrp containerd /run/containerd/containerd.sock && /bin/chmod 660 /run/containerd/containerd.sock'

의도는 이렇다.

• containerd가 뜬 직후 socket 파일이 아직 생성되지 않았을 수 있음
• 그래서 최대 5초 정도 짧게 대기
• socket이 생성되면 그룹을 containerd로 변경
• 권한을 660으로 변경

즉, 단순 권한 변경이 아니라 socket 생성 시점까지 고려한 설정이었다.

설정 후에는 다음과 같이 적용했다.

sudo systemctl daemon-reexec
sudo systemctl daemon-reload
sudo systemctl restart containerd

---

실제로 확인한 상태

서버에서 확인한 상태는 겉으로 보기에는 거의 완벽했다.

1. socket 권한

ls -l /run/containerd/containerd.sock

실제 결과:

srw-rw---- 1 root containerd 0 Mar 29 22:31 /run/containerd/containerd.sock

즉,

• owner: root
• group: containerd
• mode: 660

원하던 형태로 잘 잡혀 있었다.

---

2. 사용자 그룹 포함 여부

id

실제 결과:

uid=1000(test) gid=1000(test) groups=1000(test),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),100(users),1001(containerd)

즉, 일반 사용자도 containerd 그룹에 정상적으로 포함되어 있었다.

---

여기까지 보면 될 것 같았는데

이 상태만 보면 보통 이렇게 생각하게 된다.

socket 권한도 맞고, 그룹도 맞았으니 이제 sudo 없이 되겠지?

그래서 아래처럼 실행해봤다.

nerdctl --address /run/containerd/containerd.sock ps

그리고 환경변수로도 시도했다.

CONTAINERD_ADDRESS=/run/containerd/containerd.sock nerdctl ps

그런데 실제 결과는 예상과 달랐다.

FATA[0000] rootless containerd not running? (hint: use `containerd-rootless-setuptool.sh install` to start rootless containerd): stat /run/user/1000/containerd-rootless: no such file or directory

---

왜 rootless 에러가 나오는가

이 부분이 가장 헷갈렸다.

처음 보면 이렇게 생각하기 쉽다.

나는 rootless를 하겠다고 한 적이 없는데 왜 rootless 에러가 나오지?

하지만 이 에러의 의미는 다음과 같이 이해해야 한다.

• 내가 rootless를 원해서 나온 에러가 아님
• 서버가 rootless로 설정되어 있다는 뜻도 아님
• 비root 사용자로 nerdctl을 실행했을 때, 클라이언트가 내부적으로 rootless 관련 경로를 먼저 확인하는 흐름으로 들어간 것

내 환경에서는 아래 값도 확인되었다.

echo $XDG_RUNTIME_DIR

결과:

/run/user/1000

즉, 비root 실행 시 nerdctl은 자연스럽게 /run/user/1000/containerd-rootless 같은 rootless 관련 경로를 보게 되고, 그 경로에 rootless containerd가 없으니 그 단계에서 실패해버린 것이다.

핵심은 이거였다.

socket 권한이 열려 있어도, 기대한 rootful socket 연결 단계까지 가지 못하고 rootless 체크 단계에서 먼저 죽을 수 있다.

---

버전 문제도 확인해봄

처음에는 혹시 nerdctl 버전 문제인가 싶어서 그것도 확인했다.

기존 버전:

nerdctl version 2.0.0

그래서 최신 쪽으로 올려서 다시 테스트했다.

업그레이드 후 확인한 것들:

which nerdctl
nerdctl --version
id
ls -l /run/containerd/containerd.sock
nerdctl --address /run/containerd/containerd.sock ps
CONTAINERD_ADDRESS=/run/containerd/containerd.sock nerdctl ps

하지만 결과는 크게 달라지지 않았다.

즉, 단순히 구버전이라서 생긴 문제로 끝나지 않았다.

---

최종 결론

결론은 명확했다.

내 환경에서는 아래 조건이 모두 충족되어도 내가 원한 방식은 성립하지 않았다.

• containerd는 rootful 유지
• socket 그룹을 containerd로 설정
• socket 권한을 660으로 설정
• 사용자를 containerd 그룹에 추가
• --address 또는 CONTAINERD_ADDRESS로 rootful socket 명시
• nerdctl 버전 업그레이드까지 수행

그럼에도 불구하고 비root 사용자로 실행한 nerdctl은 여전히 rootless 경로를 먼저 확인하다가 실패했다.

즉, 내가 원했던 조합인

• rootful containerd
• sudo 없는 nerdctl
• 기존 서버 환경 유지

이 세 가지를 동시에 만족시키는 데는 실패했다.

---

그래서 실무적으로는 어떻게 해야 하나

결국 선택지는 두 가지뿐이다.

1. rootful 운영을 유지한다면 sudo nerdctl

가장 현실적인 선택이다.

sudo nerdctl ps

기존 운영 방식과 가장 잘 맞고, 동작도 명확하다.
운영 서버에서 system containerd를 계속 사용할 생각이라면 이 방식이 가장 단순하다.

---

2. 정말 sudo 없이 쓰고 싶다면 rootless로 전환

무조건 sudo 없는 사용성이 핵심이라면 결국 rootless containerd/nerdctl 쪽으로 가야 한다.

다만 이 경우는 전제가 달라진다.

• 기존 rootful 운영 방식과 다름
• 네트워크/스토리지/권한 제약 고려 필요
• 운영 목적에 따라 불편할 수 있음

즉, 무sudo 사용 자체가 가장 중요한 요구사항일 때만 선택할 만하다.

---

이번에 얻은 결론 한 줄 요약

Docker에서는 docker 그룹 방식이 익숙해서 nerdctl도 비슷하게 될 것처럼 보이지만, 내 환경에서는 rootful containerd에 대해 Docker와 같은 방식의 무sudo 사용 모델이 깔끔하게 성립하지 않았다.

결국 정리하면 이렇게 된다.

rootful을 유지하려면 sudo nerdctl, 무sudo를 원하면 rootless로 가야 한다.

---

마무리

이번 시도에서 알게 된 것은 하나다.

nerdctl은 겉모습은 Docker CLI와 비슷하지만, 실제 동작 모델은 다르고, 특히 비root 사용자 + rootful containerd 조합에서는 기대처럼 단순하게 풀리지 않을 수 있다.

처음에는 “socket 권한만 열면 되겠지”라고 생각했지만, 실제로는 그보다 더 복잡했다.
Docker에서 익숙했던 접근을 그대로 가져오면 생각보다 쉽게 막힌다.

같은 시도를 해보는 사람이라면, 시간을 아끼기 위해 먼저 이 결론부터 알고 시작하는 편이 낫다.

내 환경 기준으로는 rootful containerd에서 sudo 없는 nerdctl은 포기하는 것이 맞았다.