여러 NAS 공유에서 컨테이너 사용자 ID를 구성하는 방법

에바 왕

IceWhale author

에바 왕 는 기술 작가 그리고 이자 ZimaSpace의 상주 장인입니다. 평생을 기술에 열정을 가진 사람으로서 홈랩과 오픈소스 소프트웨어에 열정을 가지고 있으며,복잡한 기술 개념을 쉽게 이해할 수 있는 실습 가이드로 번역하는 데 전문성을 가지고 있습니다.에바는 셀프 호스팅이 어렵지 않고 재미있어야 한다고 믿습니다. 그녀의 튜토리얼을 통해 커뮤니티가 하드웨어 설정의 신비를 풀도록돕고 있습니다. 첫 NAS 구축부터 Docker 컨테이너 마스터링까지.

How to Configure Container User IDs Across Multiple NAS Shares

각 컨테이너 프로세스의 실제 숫자 ID를 필요한 모든 공유의 소유자, 그룹, ACL 및 마운트 모드에 매핑하여 여러 NAS 공유에서 컨테이너 사용자 ID를 구성하세요.

하나의 UID가 모든 데이터셋을 소유하도록 강제하지 말고, 통합 전략으로 chmod 777을 사용하지 마세요. 미디어 서버는 사진에 읽기 전용으로 접근해야 할 수 있고, 다운로더는 수집 공유에 읽기/쓰기 권한이 필요할 수 있으며, 백업 컨테이너는 별도의 보호된 대상이 필요할 수 있습니다. 기본 책임에는 소유권을 사용하고, 공유 접근에는 그룹이나 ACL을 사용하세요.

권한을 변경하기 전에 세 가지 ID를 기록하세요

각 서비스에 대해 NAS 측 소유자 UID/GID, 컨테이너 내부 프로세스의 숫자 사용자 및 그룹 ID, 그리고 PUID/PGID 같은 이미지별 ID 규칙을 기록하세요. 사용자 이름은 같아 보여도 숫자 ID가 다를 수 있으므로 이 세 값이 서로 혼동되는 경우가 많습니다.

PUID와 PGID는 Docker 설정이 아닙니다라는 최신 설명에서도 이러한 구분을 명확히 합니다. PUID와 PGID는 일부 컨테이너 이미지가 해석하는 변수일 뿐, 모든 Docker에 적용되는 설정은 아닙니다.

컨테이너 내부에서 id를 실행하여 실행 중인 프로세스를 확인하고, 호스트의 파일은 숫자 소유권으로 검사하세요. 이미지가 해당 방식을 지원하지 않는 한 Compose에 작성한 값이 실제로 프로세스를 제어한다고 가정하지 마세요.

서비스 간 데이터에는 기본 소유자와 공유 그룹을 사용하세요

하나의 애플리케이션만 사용하는 공유에는 전용 소유자를 지정할 수 있습니다. 여러 서비스가 파일을 쓰는 공유는 일반적으로 해당 서비스에 필요한 작업만 허용하는 공유 그룹이나 ACL을 계획적으로 사용하는 편이 관리하기 쉽습니다.

숫자 UID 및 GID 소유권에 대한 실용적인 설명에서는 바인드 마운트된 파일이 호스트의 숫자 소유권을 따르는 이유와, 해당 ID를 일치시키거나 의도적으로 매핑해야 root 소유로 생성되는 출력과 권한 오류를 방지할 수 있는 이유를 설명합니다.

예를 들어 미디어 작업 흐름에서는 다운로더가 준비 파일을 소유하고, 다운로더와 정리 담당 서비스가 모두 media 그룹에 속하도록 할 수 있습니다. 디렉터리 상속, 기본 ACL 또는 적절한 umask 동작을 설정하여 새 파일에도 공유 접근 권한이 자동으로 유지되도록 하세요.

각 공유에는 컨테이너에 필요한 마운트 권한만 부여하세요

ID는 여러 계층 중 하나일 뿐입니다. UID를 올바르게 매핑해도 읽기 전용 바인드 마운트를 통해 파일을 쓸 수는 없으며, 파일 시스템 권한이 광범위한 컨테이너도 라이브러리를 읽기 전용으로 마운트하여 안전하게 제한할 수 있습니다.

2026년의 런타임 사용자 재정의 설명에서는 바인드 마운트가 호스트 소유권을 사용하는 방식과 런타임 user: 설정으로 프로세스 ID를 일치시키는 방법을 설명하는 동시에, 사용자를 강제로 지정하면 시작 로직이 다른 권한을 전제로 하는 이미지가 작동하지 않을 수 있다고 경고합니다.

각 호스트 경로, 컨테이너 경로, 마운트 모드, 필요한 작업 및 담당 서비스를 문서화하세요. 서비스가 소비만 하는 라이브러리에는 읽기 전용 마운트를 사용하고, 실제로 필요한 가장 작은 경로에만 쓰기 권한을 부여하세요.

-15% OFF

ZimaBoard 2 - 당신의 큰 아이디어를 위한 미니 홈 서버

Single board computer zimaboard2

여러 NAS ACL 모델을 계획적으로 처리하세요

SMB/NFSv4 ACL, POSIX ACL, NFS ID 매핑 및 단순 Unix 모드 비트는 서로 다른 접근 권한을 보여줄 수 있습니다. 하나의 NAS 사용자로 SMB를 통해 정상적으로 작동하는 공유도 호스트에서 다른 숫자 ID를 사용하는 컨테이너 프로세스의 접근은 거부할 수 있습니다.

관련 ZimaSpace 문서인 NAS 권한 변경에서는 대상 ACL 상속, SMB ID, 컨테이너 UID/GID 및 umask를 서로 별개의 계층으로 진단해야 하는 이유를 설명합니다.

여러 프로토콜이 하나의 데이터셋에 접근한다면 하나의 권한 모델을 선택하고 문서화하세요. NAS GUI에서 ACL을 변경하면서 셸의 chmod 및 chown 명령을 반복적으로 섞어 사용하면 다음 파일이 이전 파일과 다르게 동작할 수 있습니다.

재귀적으로 적용하기 전에 모든 작성자에서 파일 생성을 테스트하세요

의도한 소유권과 ACL을 적용한 임시 테스트 디렉터리를 만드세요. 각 컨테이너에서 서비스에 필요한 작업만 수행하도록 목록 조회, 읽기, 생성, 이름 변경 및 삭제를 테스트하세요. 그런 다음 NAS에서 새 파일의 숫자 소유자, 그룹, 모드 및 상속된 ACL을 확인하세요.

기존 파일은 작동하지만 새로 생성된 파일이 다른 서비스에서 실패한다면 그룹 멤버십, 기본 ACL, umask 또는 애플리케이션별 파일 모드 등 생성 경로를 수정하세요. 기존 데이터를 재귀적으로 복구해도 같은 불일치가 내일 다시 발생하는 것을 막을 수는 없습니다.

모든 작성자가 높은 권한 없이 다음에 필요한 서비스에서 사용할 수 있는 파일을 생성하는 것을 확인한 후에만 운영 환경에 적용하세요. 깔끔한 UID/GID 설계는 모든 컨테이너가 우연히 같은 사용자로 실행되기 때문이 아니라, 매핑이 문서화되어 반복적으로 적용할 수 있기 때문에 복구할 수 있습니다.