Immich 데이터 폴더의 권한 드리프트를 방지하는 방법

Immich에서 권한 드리프트를 방지하려면 서로 다른 컨테이너, NAS 프로토콜, 업데이트 또는 유지 관리 작업이 서로 다른 ID로 새 파일을 만들기 전에 파일 소유권과 접근 규칙을 예측 가능하게 설정해야 합니다.

지속 가능한 해결책은 주기적으로 재귀적 권한 초기화를 수행하는 것이 아닙니다. 각 워크플로에 실제로 필요한 숫자형 UID/GID와 접근 권한을 기록하고, 마운트 소유권과 ACL 상속을 의도적으로 관리하며, 읽기 전용 경로와 쓰기 가능한 경로를 분리하고, 변경할 때마다 생성 경로를 테스트해야 합니다. 긴급한 `chown` 없이도 다음에 생성되는 새 파일이 올바르게 생성될 때 권한 드리프트가 방지된 것입니다. 오늘 라이브러리를 우연히 읽을 수 있는지만으로는 충분하지 않습니다.

각 Immich 경로를 읽고 쓰는 ID 기록하기

Immich에 마운트된 호스트 경로를 나열하고, 각 경로에서 어떤 프로세스가 파일을 읽거나 생성하거나 이름을 변경하거나 삭제해야 하는지 확인합니다. 모든 쓰기 주체에 대해 호스트와 컨테이너 내부에서 사용하는 숫자형 UID와 GID를 기록합니다. 파일은 사용자 이름이 아니라 숫자로 소유권을 저장하므로, 사용자 이름이 일치하는지보다 숫자형 ID가 더 중요합니다.

Immich 외부의 쓰기 주체도 목록에 포함합니다. SMB 업로드, NFS 클라이언트, 백업 도구, 가져오기 스크립트, 미디어 관리 컨테이너, 관리자 셸 모두 같은 트리 아래에 파일을 만들 수 있습니다. 이들이 서로 다른 ID로 작업하면 라이브러리에 소유자와 권한 모드가 점점 다양해져, 한 경로에서는 작동하지만 다른 경로에서는 실패할 수 있습니다.

이 ID 매핑을 Compose 구성과 함께 보관합니다. 그러면 향후 이미지 업데이트, 서버 마이그레이션 또는 복원된 NAS 계정을 정상 기준과 비교할 수 있으며, 새 업로드가 실패한 뒤에야 불일치를 발견하는 일을 피할 수 있습니다.

의도적인 소유자, 공유 그룹, 최소 권한 모델 사용하기

애플리케이션이 관리하는 데이터를 어떤 ID가 소유해야 하는지, 그리고 접근이 필요한 공유 그룹이 있는지 결정합니다. 각 워크플로에 필요한 읽기 또는 쓰기 권한만 부여합니다. 한 컨테이너가 썸네일을 만들거나 가져온 파일을 이동하지 못한다는 이유만으로 Immich 트리 전체를 모든 사용자가 쓸 수 있게 만들지 마세요.

UID/GID 불일치와 지나치게 넓은 권한 모드는 공유 볼륨 장애의 흔한 원인입니다. 더 안전한 방식은 무제한 접근 권한을 부여하는 대신 컨테이너와 볼륨의 권한을 일치시키는 것입니다. 여러 서비스가 같은 스토리지 풀에 접근할 수 있는 홈 서버에서는 특히 중요합니다.

여러 서비스에 쓰기 권한이 필요하다면 애플리케이션마다 재귀적으로 소유권을 번갈아 변경하지 말고, 공유 그룹과 일관된 그룹 권한 또는 ACL을 사용합니다. 먼저 대표 디렉터리 하나를 확인합니다. 현재 백업이 있는 경우를 제외하면 사진 라이브러리 전체에 광범위한 재귀 변경을 적용하는 일은 일상적인 유지 관리가 아니라 최후의 수단이어야 합니다.

새 파일 권한을 예측 가능하게 만들기

기존 파일이 완벽해 보여도 생성 규칙이 잘못되면 새 파일에서 즉시 드리프트가 발생할 수 있습니다. 해당 경로에 적용되는 상위 디렉터리 ACL, 기본 ACL 항목, umask, 서비스 ID, SMB 또는 NFS 생성 설정을 확인합니다. 예방의 목표는 정리가 아니라 상속 규칙을 바로잡는 것입니다.

권한을 재귀적으로 변경하기 전에 호스트의 숫자형 소유권과 컨테이너 내부에서 실제로 실행 중인 UID/GID를 비교합니다. 이 UID/GID 바인드 마운트 확인을 사용하면 ID 불일치와 실제 권한 부족을 빠르게 구분할 수 있습니다. 지나치게 개방적인 권한으로 문제를 가리는 대신 소유자와 그룹 관계를 바로잡습니다.

각 일반 쓰기 경로를 통해 작은 테스트 파일을 하나씩 만듭니다. Immich 업로드, 가져오기 워크플로, 사용하는 경우 SMB/NFS 전송, 백업 복원을 각각 테스트합니다. 각 테스트 후 소유자, 그룹, 권한 모드, ACL을 확인합니다. 두 생성 경로가 호환되지 않는 결과를 만든다면 더 많은 데이터를 가져오기 전에 해당 정책 충돌을 해결합니다.

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

마운트 및 업데이트 변경으로 소유권이 다시 작성되지 않게 하기

Compose 편집, 이미지 업데이트, NAS 재마운트 또는 마이그레이션을 권한에 영향을 주는 변경으로 취급합니다. 적용하기 전에 현재 마운트 소스와 대상, 해당 경로가 읽기 전용인지 읽기-쓰기인지, 유효한 컨테이너 사용자, 각 주요 디렉터리의 숫자형 소유권 샘플을 기록합니다.

전송 및 네트워크 스토리지는 서로 다른 SMB/NFS ID, 숫자형 ID, ACL 상속, umask 동작을 도입할 수 있습니다. Immich 데이터를 파일 시스템이나 접근 방식 사이에서 이동할 때마다 NAS 권한 변경 장애 지점을 변경 전 체크리스트로 사용합니다.

변경 후 대량 작업을 실행하기 전에 같은 샘플을 비교합니다. 시작 시 소유권이 갑자기 변경되면 스택을 중지하고 어떤 엔트리포인트, 유지 관리 작업 또는 매핑된 ID가 원인인지 확인합니다. 원인이 밝혀지지 않은 재귀적 소유권 재작성을 대규모 라이브러리 전체에 계속 적용하지 마세요.

작고 반복 가능한 테스트로 드리프트 감사하기

일정에 따라 또는 업그레이드 후 간단한 권한 감사를 실행합니다. 안정적인 원본 파일 몇 개, 최근 업로드 파일, 새로 생성된 파생 파일, 외부 라이브러리 마운트를 확인합니다. 예상하지 못한 소유자, 누락된 그룹 접근 권한, 쓰기 가능하게 바뀐 읽기 전용 마운트, 더 이상 예상대로 상속되지 않는 ACL이 있는지 살핍니다.

그런 다음 종단 간 쓰기 테스트를 수행합니다. 일반 클라이언트를 통해 일회용 파일을 업로드하고, Immich가 처리하도록 한 뒤, 파일을 열고 애플리케이션을 통해 삭제합니다. 외부 라이브러리 또는 가져오기 경로를 사용하는 경우 해당 경로로 대표 파일 하나를 추가하고, Immich가 소유권을 예기치 않게 변경하지 않고 읽을 수 있는지 확인합니다.

Immich 재시작과 호스트 재부팅 후에도 새 파일이 계속 의도한 ID와 접근 권한을 받을 때 비로소 예방 절차가 완성됩니다. 두 이벤트 중 하나가 발생할 때마다 수동으로 권한을 복구해야 한다면 시스템은 여전히 드리프트 중인 것입니다. 접근 권한을 확대하기 전에 생성 규칙 또는 ID 매핑을 수정합니다.