NAS 공유를 위한 컨테이너 사용자 및 그룹 매핑 체크리스트

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

안전한 접근 방식은 NAS 내보내기부터 호스트 마운트, 실행 중인 컨테이너 프로세스까지 숫자 ID 매핑을 확인하는 작업을 단일 명령이 아닌 관찰 가능한 단계들의 연속으로 다루는 것입니다.

SMB 또는 NFS 기반 NAS 공유를 사용하는 Linux 컨테이너 호스트에서는 컨테이너가 NAS 마운트 경로를 볼 수 있지만 권한 오류로 읽기나 쓰기에 실패할 수 있다는 점이 실제 위험입니다. 현재 ID와 복구 지점을 기록하고, 가장 영향이 적은 판별 작업부터 시작하며, 다른 변수를 변경하기 전에 통과 및 실패 결과를 해석하십시오. 스토리지가 불안정해지거나 복구 가능한 유일한 사본이 노출될 상황이라면 중단하십시오. 아래 절차는 원래 워크로드가 성공하거나 증거가 에스컬레이션 경계에 도달할 때만 끝납니다.

실제 컨테이너 프로세스 ID 확인

이미지 문서, Compose의 user 설정, 환경 변수, 엔트리포인트 동작, 실행 중인 애플리케이션 프로세스의 UID, GID 및 보조 그룹을 확인하십시오. PUID와 PGID라는 변수는 이미지별 관례일 뿐 보편적인 Docker 기능이 아니므로, 해당 이미지가 이를 지원하는지 확인하십시오.

LinuxServer 커뮤니티의 컨테이너 PUID 및 PGID 권한 사례는 겉보기에는 올바른 PUID 및 PGID 값이어도 bind mount에 접근할 수 없을 수 있음을 보여 줍니다. 이 사례는 모든 이미지가 동일한 초기화 로직을 구현한다는 근거가 아니라, 실행 중인 프로세스와 마운트를 확인해야 한다는 점을 상기시키는 용도로 활용하십시오.

컨테이너 내부와 호스트에서 id를 사용해 숫자 값을 기록하십시오. 이전에 권한 오류가 발생했다는 이유만으로 애플리케이션이 root로 실행된다면 중단하십시오. root 접근은 ID 매핑 결함을 숨기고 서비스가 침해되었을 때 피해를 키웁니다.

NAS에서 호스트 마운트까지 소유권 추적

NAS에서 대상 디렉터리의 숫자 소유자, 그룹, 모드, ACL 및 기본 ACL을 확인하십시오. 컨테이너 호스트에서는 동일하게 마운트된 객체를 확인하고 숫자 값을 비교하십시오. 이름은 다르지만 숫자가 같다면 레이블만 다른 것이며, 숫자가 다르면 권한 부여 경로가 실제로 다른 것입니다.

NFS의 경우 내보내기 옵션, NFS 버전, ID 매핑, root squash 및 클라이언트 마운트 ID를 포함하십시오. SMB의 경우 마운트 자격 증명, 서버 측 매핑 ID, uid 또는 gid 표시 옵션, Unix 확장 기능 또는 ACL 변환 사용 여부를 포함하십시오.

서버 ACL과 클라이언트 마운트 옵션을 동시에 변경하지 마십시오. 하나의 테스트 파일에 알려진 숫자 소유자를 설정하고, 마운트 해제, 재마운트 및 재부팅 후에도 호스트가 안정적인 매핑을 확인하면 해당 단계는 통과입니다.

bind mount 및 보조 그룹 테스트

컨테이너의 소스 경로가 네트워크 공유가 마운트되기 전에 생성된 비어 있는 로컬 디렉터리가 아니라 예상한 호스트 마운트인지 확인하십시오. 런타임 마운트를 검사한 다음, 임시 하위 디렉터리에서 애플리케이션 사용자로 목록 조회, 읽기, 생성, 이름 변경 및 삭제를 테스트하십시오.

Server Fault 사례는 소유자와 ACL 항목이 일치해 보이는 경우에도 NFS ACL 권한 불일치가 발생할 수 있음을 설명합니다. 이는 ACL 마스크, 서버 매핑 및 유효 ID를 모두 검사해야 하는 이유를 보여 줍니다. 디렉터리와 생성된 파일 모두에서 getfacl 결과를 수집하십시오.

그룹 접근이 필요하다면 지원되는 보조 숫자 그룹을 추가하고 프로세스 그룹은 시작 시 고정되므로 컨테이너를 다시 생성하십시오. 애플리케이션이 빈 경로에서 시작하는 경우 컨테이너 빈 경로 진단에 관한 ZimaSpace 가이드를 활용하십시오. 이는 ACL 문제가 아니라 마운트 순서 문제입니다.

-15% OFF

가장 제한적인 ID 수정 적용 후 재테스트

애플리케이션이 지원하는 UID, GID 또는 보조 그룹을 NAS 정책에 맞추는 방식을 우선하십시오. 여러 서비스가 협업하는 경우 공유 그룹과 상속 ACL을 사용하십시오. 전체 공개 쓰기 권한, 관련 없는 데이터셋 전체에 대한 재귀적 소유권 변경, 특권 컨테이너를 지름길로 사용하지 마십시오.

매핑 옵션을 변경했다면 컨테이너를 다시 생성하고 공유를 재마운트한 다음 동일한 작업을 반복하십시오. 호스트를 한 번 재시작하여 부팅 후에도 마운트 순서와 숫자 ID가 유지되는지 확인하십시오. 새로 생성된 파일이 의도된 일반 사용자에게 계속 쓰기 가능하면서도 컨테이너에 불필요한 권한을 부여하지 않는지 확인하십시오.

앱이 원래 워크로드를 통과하고, 거부되어야 하는 작업은 계속 거부되며, 재시작 후에도 소유권이 안정적으로 유지되면 체크리스트를 완료하십시오. 사용자 네임스페이스, rootless 매핑 또는 NAS ID 서비스가 선택한 이미지에서 지원할 수 없는 방식으로 ID를 다시 작성한다면 에스컬레이션하십시오.

지원 및 팁

더 읽어보기

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.