Plex의 숫자형 런타임 ID를 안정적으로 유지하고, 복원 중 소유권을 보존하며, appdata와 미디어 액세스를 별도로 테스트하여 권한 드리프트를 방지하세요.
이미지 업데이트, 호스트 마이그레이션, 스택 재생성 또는 백업 복원 후 권한 오류가 자주 발생하는 이유는 파일은 그대로 남아 있지만 숫자형 소유자, 그룹, ACL 또는 예상 런타임 사용자가 변경되기 때문입니다. 가장 안전한 예방 방법은 `/config`와 미디어에 대해 정상적으로 작동하는 기준 상태를 마련하고, 변경할 때마다 간단한 검증을 한 번 수행하는 것입니다. 기준 상태를 통해 전체 트리에 동일한 소유권이 정말 필요한 것으로 확인되지 않는 한, 광범위한 재귀 권한 수정은 피하세요.
권한을 변경하기 전에 숫자형 소유권을 기록하세요
Plex 프로세스가 사용하는 숫자형 UID와 GID, 그리고 appdata 및 미디어 경로에 저장된 숫자형 소유자를 알고 있으면 권한 드리프트를 가장 쉽게 방지할 수 있습니다. 호스트와 컨테이너의 사용자 이름은 다를 수 있지만 파일 시스템은 여전히 숫자 값을 기준으로 권한을 적용합니다.
숫자형 UID 및 GID 매핑을 사용하면 컨테이너 프로세스가 호스트 소유권에 맞게 작동할 수 있습니다. 사용자 이름이나 기억에 의존하지 말고 스택 구성에 해당 값을 기록하세요.
시스템이 정상적으로 작동할 때 appdata 디렉터리 하나, 데이터베이스 파일 하나, 미디어 디렉터리 하나에 대해 `stat` 출력 또는 이에 상응하는 정보를 수집하세요. 이 값들은 이미지 업데이트, 호스트 마이그레이션, 복원 또는 스토리지 이동 후 확인할 기준이 됩니다.
컨테이너 업데이트 전반에서 런타임 ID를 안정적으로 유지하세요
이미지 업데이트로 기본값, 엔트리포인트 동작 또는 환경 변수 해석 방식이 변경될 수 있습니다. 실제 Plex 프로세스가 다른 ID로 시작하면 새로 생성되는 파일의 소유자가 달라질 수 있으며, 이후 재시작 시 기존 상태에 액세스하지 못할 수 있습니다.
플랫폼 또는 이미지 변경 후 appdata 쓰기 액세스 손실이 발생한다면, 실제 런타임 ID가 업데이트해야 하는 파일과 더 이상 일치하지 않는다는 신호일 수 있습니다.
이미지 또는 호스트를 업그레이드할 때마다 실행 중인 컨테이너 내부에서 프로세스의 UID/GID를 확인하고, 적절한 경우 쓰기 가능한 임시 경로에 테스트 파일 하나를 생성하세요. 숫자가 예기치 않게 변경되었다면 새로운 소유권이 확산되기 전에 런타임 구성을 수정하세요.
Appdata 쓰기 액세스와 미디어 액세스를 분리하세요
Plex 애플리케이션 상태에는 일반적으로 읽기 및 쓰기 액세스가 필요하지만, 미디어 라이브러리는 다른 도구가 파일을 관리하도록 의도적으로 허용한 경우가 아니라면 읽기 액세스만 필요할 수 있습니다. 두 경로에 동일한 광범위한 권한을 부여하면 실제로 필요한 작업이 무엇인지 파악하기 어려워지고 실수의 영향 범위가 커집니다.
안정적인 컨테이너 액세스는 제한 없는 모드 비트가 아니라 PUID 및 PGID 정렬에 달려 있습니다. 지속적인 해결책으로 모든 사용자에게 쓰기 권한을 부여하지 말고 서비스 역할에 맞게 액세스를 설정하세요.
`/config`, 미디어, 트랜스코드 임시 공간에 필요한 액세스를 각각 정의하세요. 변경 후 각 경로에 대해 Plex 프로세스로 테스트를 수행하세요. 읽기 전용 미디어 경로에서 파일 삭제가 실패하는 것은 의도된 동작일 수 있지만, appdata 경로에서 데이터베이스 저널을 생성하지 못하는 것은 문제가 됩니다.
복원 과정에서 소유권과 ACL을 보존하세요
백업에 Plex 파일이 모두 포함되어 있어도 복원 도구가 관리자 계정으로 파일을 기록하거나 ACL을 제거하거나 그룹 소유권을 변경하면 권한 드리프트가 발생할 수 있습니다. 그러면 다음 컨테이너는 데이터가 완전한 것처럼 보지만 일관되게 업데이트하지 못합니다.
시작하기 전에 복원된 소유권을 런타임 ID와 비교해야 합니다. 그래야 완전한 백업이 읽을 수 없는 appdata 트리로 복원되는 일을 방지할 수 있습니다.
복원 테스트에는 체크섬과 파일 수뿐 아니라 소유자, 그룹, 모드 및 ACL 처리 방식도 포함하세요. 작은 샘플을 다른 위치에 복원한 뒤 메타데이터를 비교하세요. 도구가 권한을 보존하지 못한다면 복원 후 소유권을 명시적으로 설정하는 단계를 운영 절차서에 추가하세요.
샘플 복원이 통과한 후에는 실제 복구에 사용할 것과 동일한 도구와 옵션으로 다시 확인하세요. 다른 수동 복사 방식에 의존하는 권한 보존 테스트는 운영 백업 워크플로가 안전하다는 증거가 아닙니다.
재귀적 수정 대신 간단한 테스트로 드리프트를 점검하세요
재귀적 `chmod` 또는 `chown` 명령은 Plex를 다시 시작할 수 있게 만들지만, 미디어, 백업 또는 공유 애플리케이션 데이터에 의도적으로 다르게 설정된 권한까지 다시 작성할 수 있습니다. 더 안전한 유지 관리 방식은 드리프트가 발생한 정확한 경로를 찾아내고 필요한 소유권 또는 액세스만 수정하는 것입니다.
appdata 권한 확인에 실패하면 마운트, 소유자, ACL 또는 사용자를 변경하기 전에 Plex 런타임 ID로 지정된 경로를 테스트하세요.
권한 변경이 컨테이너 교체와 동시에 발생한다면 컨테이너 영속성 워크플로에서 런타임 ID와 데이터 위치를 함께 관리해야 합니다.
지원 및 팁
더 읽어보기

Plex가 다른 Docker 컨테이너와 GPU를 공유할 수 있나요?
Plex와 다른 컨테이너가 동일한 GPU에 함께 액세스할 수 있는 경우가 많지만, 드라이버 지원, 디바이스 매핑, 비디오 엔진 부하, 메모리, 복구 동작을 테스트해야 합니다.

Plex 오류가 클라이언트에서 발생한 것인지 서버에서 발생한 것인지 확인하는 방법
다른 클라이언트에서 동일한 항목을 재현하고, 세션 경로를 비교한 다음, 범위 분석을 통해 장애가 실제로 발생한 위치를 확인한 후에만 서버 증거를 수집하세요.

Plex 캐시 및 트랜스코딩 임시 저장소 구성 방법
영구 Plex 상태는 보호하면서 트랜스코딩 임시 파일은 적합한 로컬 저장소에 배치한 다음, 정리 상태와 여유 공간 및 재시작 동작을 확인하세요.

