Immich는 왜 누락된 파일을 잘못된 소유자로 다시 생성하나요?

Immich는 누락된 원본을 일반적인 복구 기능으로 조용히 다시 만들어서는 안 됩니다. 삭제된 객체가 다시 나타났다면 먼저 그것이 생성된 썸네일인지, 인코딩된 동영상인지, 프로필 아티팩트인지, XMP 사이드카인지, 아니면 다른 쓰기 가능한 파일인지 확인하세요. 이러한 파일은 서로 다른 프로세스에 의해 다시 생성되거나 덮어써질 수 있으며, 그 과정에서 다른 소유자를 물려받을 수 있습니다.

재생성된 객체 하나와 해당 상위 디렉터리만 임시로 사용하세요. 호스트의 숫자형 UID/GID와 ACL을 컨테이너 내부에서 실제로 쓰기를 수행하는 프로세스의 UID/GID 및 ACL과 비교한 다음, 실제로 파일을 만든 주체가 Immich인지, 사이드카 작성 기능인지, NAS 프로토콜인지, 아니면 다른 호스트 프로세스인지 확인하세요. 해당 작성 주체를 파악하기 전에는 재귀적 chown이나 chmod 777을 사용하지 마세요.

재생성된 파일을 상위 디렉터리 및 정상적으로 작동하는 인접 파일과 비교하기

재생성된 파일, 상위 디렉터리, 그리고 정상적으로 작동하는 오래된 파일에 대해 소유자, 그룹, 모드, ACL, 관련된 경우 확장 속성, 숫자형 UID/GID를 기록하세요. NAS와 컨테이너 사이에서는 이름이 오해를 불러일으킬 수 있습니다. 숫자형 ID를 확인하면 한 시스템의 “immich”가 다른 시스템에서도 같은 ID에 매핑되는지 알 수 있습니다.

NAS로 이동한 파일에 대한 ZimaSpace 권한 워크플로는 이 상황에 그대로 적용됩니다. 새 객체에는 대상 ACL, 컨테이너 ID, 프로토콜 매핑, 생성 규칙이 적용됩니다. 따라서 대체 파일은 읽을 수 있더라도 다른 도구의 워크플로를 중단시키는 소유자를 가질 수 있습니다. 재생성된 파일이 상위 디렉터리의 상속 설정과 일치하고 표시 이름만 낯설다면, 변경하기 전에 숫자형 ID를 매핑하세요. 상위 디렉터리와 정상 파일 모두와 다르다면 작성 주체의 ID를 계속 확인하세요. 문제는 파일 시스템 ACL이 아니라 컨테이너 설정에 있을 수 있습니다.

대체 파일을 작성하는 프로세스와 실제 UID/GID 확인하기

관련 로그와 파일 시스템을 확인하면서 안전한 재생성을 한 번 실행하세요. 쓰기를 수행하는 컨테이너 내부의 실제 사용자와 그룹을 확인하세요. 대신 사이드카, 메타데이터 도구, 백업 프로세스 또는 호스트 스크립트가 파일을 만든다면 Immich의 실행 ID를 변경하지 말고 해당 서비스를 확인하세요.

컨테이너의 소유권은 이름이 아니라 숫자형 ID를 기준으로 합니다. Docker 파일 소유권 설명에서 볼 수 있듯이 UID/GID 매핑이 일치하지 않으면 동일한 바인드 마운트 파일도 호스트와 컨테이너에서 서로 다른 사용자 이름으로 표시될 수 있습니다. 공통 기준으로 숫자형 ID를 사용하세요.

Immich의 외부 라이브러리 소유권 논의에서는 한 배포 환경에서 XMP 사이드카가 root로 작성된 사례가 보고되었습니다. 이는 실제 작성 주체와 지원되는 실행 ID를 확인해야 한다는 사례이지, 현재 모든 Immich 설치 환경에서 모든 재생성 파일이 root로 작성된다는 의미는 아닙니다.

컨테이너가 의도적으로 비root 사용자로 실행 중이라면 해당 UID/GID가 호스트 또는 NAS에 실제로 존재하고 마운트된 경로에 필요한 접근 권한을 갖는지 확인하세요. 컨테이너 내부의 기호 사용자 이름이 같은 이름을 가진 호스트 계정과 자동으로 일치하는 것은 아닙니다.

기존 파일을 반복해서 수정하지 말고 생성 규칙을 바로잡기

확인된 경계 중 가장 작은 부분을 수정하세요. 지원되는 경우 서비스 UID/GID를 일치시키고, 상위 디렉터리의 그룹 또는 ACL 상속을 수정하며, 적절한 umask를 설정하거나, 잘못된 ID를 제공하는 NAS 공유 매핑을 변경하세요. Immich와 다른 정식 리더가 원본 및 생성 파일에 접근할 수 있는 상태를 유지해야 합니다.

기본 해결 방법으로 모든 사용자에게 쓰기 권한을 부여하지 마세요. 이는 ID 불일치를 숨기고 불필요하게 쓰기 접근 권한을 확대합니다. 마찬가지로 PostgreSQL 소유권, 모델 캐시, 업로드 디렉터리, 외부 라이브러리를 하나의 명령으로 재귀적으로 변경하지 마세요. 이러한 경로는 의도적으로 서로 다른 서비스 ID를 사용할 수 있습니다.

외부 라이브러리를 변경할 수 없는 상태로 유지해야 한다면 마운트를 읽기 전용으로 설정하고 앱이 소유하는 쓰기 가능한 상태를 다른 곳에 보관하는 방법을 고려하세요. 단, 사용 중인 기능이 해당 위치에 사이드카를 작성할 필요가 없는 경우에만 적용해야 합니다. 중요한 것은 사진 보관함의 모든 파일을 하나의 계정으로 강제로 통일하는 것이 아니라, 원하는 소유권과 쓰기 동작을 결정하는 것입니다.

Featured

ZimaCube 2 개인용 클라우드 홈 NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

파일 하나를 다시 생성하고 재시작 후 검증하기

안전하게 재생성할 수 있는 임시 생성 객체나 테스트 사이드카 하나만 삭제한 다음, 정확히 동일한 Immich 작업을 다시 실행하세요. 새 파일의 소유자, 그룹, ACL 및 Immich와 이전에 실패했던 다른 프로그램에서의 읽기 가능 여부를 확인하세요. 이 테스트 중에는 원본 미디어를 건드리지 마세요.

컨테이너를 다시 시작한 다음 호스트도 한 번 재부팅하여 수정된 ID와 마운트가 수명 주기 변경 후에도 유지되는지 확인하세요. 올바른 수정이 이루어졌다면 다음 테스트 파일은 별도의 조치 없이 예상한 소유권으로 자동 생성되어야 합니다. Immich의 쓰기와 경쟁하는 시작 후 chown 스크립트에 의존해서는 안 됩니다.

소유권 변경이 데이터베이스나 원본으로 예기치 않게 확산되거나, 재시작 후 서비스가 읽기 또는 쓰기 권한을 잃는다면 중지하고 보존해 둔 설정에서 복원하세요. 숫자형 ID, ACL 출력, 마운트 옵션, 컨테이너의 실제 사용자, Compose 일부 설정, 그리고 Immich가 재생성한 정확한 파일 유형을 함께 제공하여 문제를 에스컬레이션하세요.