스택을 재생성한 후 Plex 인스턴스가 새로 설치된 것처럼 보인다면, 기존 영구 데이터가 실제로 사라졌다는 사실을 입증하기 전까지는 마운트 또는 권한 문제로 간주하세요.
Docker 또는 Compose 스택을 재생성하면 컨테이너가 교체될 뿐 아니라 `/config`를 제공하는 호스트 경로, 명명된 볼륨, 사용자 ID 또는 스토리지 풀이 변경될 수 있습니다. 그러면 Plex가 비어 있거나 읽을 수 없는 디렉터리를 대상으로 실행되어 새로 설치된 것처럼 보일 수 있지만, 기존 데이터베이스는 여전히 남아 있을 수 있습니다. 새 인스턴스를 중지하고, 기존 앱 데이터를 찾은 뒤, 실제 마운트와 숫자형 소유권을 비교하세요. 해당 상태가 정말 사라진 경우에만 백업에서 복원하세요.
Plex가 새 서버처럼 보이면 중지하세요
스택 재생성 후 표시되는 초기 설정 마법사는 라이브러리를 다시 만들라는 신호가 아니라 영구 저장 문제가 있다는 경고입니다. 컨테이너를 중지하고 Plex가 추가 데이터를 기록하기 전에 데이터 매핑을 점검하세요. 가장 흔한 문제는 새 컨테이너가 이전 애플리케이션 데이터 디렉터리 대신 비어 있는 호스트 경로를 읽는 것입니다.
재생성된 컨테이너에서 예상한 영구 설정 매핑이 더 이상 원래 앱 데이터를 가리키지 않으면 Plex가 새로 설정된 것처럼 보일 수 있습니다. 가장 먼저 확인할 것은 기존 상태가 호스트에 여전히 존재하는지 여부입니다.
이전 Plex 데이터 디렉터리를 찾고 수정 시간, 데이터베이스 파일 및 메타데이터 폴더를 확인하세요. 해당 항목이 있다면 삭제하거나 새 서버를 초기화하지 마세요. 복구 대상은 미디어 라이브러리가 아니라 마운트 경로와 권한입니다.
기존 /config 매핑과 새 매핑을 정확히 비교하세요
스택을 재생성하면 컨테이너 내부에 표시되는 경로는 같아도 상대 바인드 마운트, 명명된 볼륨, 환경 변수 치환, 스토리지 풀 또는 Compose 작업 디렉터리가 변경될 수 있습니다. Plex는 여전히 `/config`를 볼 수 있지만, 해당 경로가 이제 다른 호스트 위치를 가리킬 수 있습니다.
설정 데이터를 컨테이너 외부에 저장하는 방식이 Plex 컨테이너 설정에는 가장 안전합니다. 겉보기에 비슷한 Compose 파일을 그대로 믿지 말고, 이전 배포 기록 또는 백업의 실제 마운트와 재생성된 스택의 실제 마운트를 비교하세요.
기존 앱 데이터를 읽기 전용으로 임시 진단 컨테이너에 마운트하거나 호스트에서 직접 검사하세요. 예상한 데이터베이스와 환경 설정이 있다면 운영 매핑을 수정한 후 Plex를 한 번만 다시 시작하세요. 디렉터리가 실제로 사라졌다면 백업 복구로 넘어가세요.
데이터베이스를 탓하기 전에 소유권을 확인하세요
호스트 경로가 올바르더라도 재생성된 컨테이너가 다른 UID, GID, 사용자 네임스페이스 또는 보안 컨텍스트로 실행되면 사용할 수 없을 수 있습니다. 이 경우 데이터가 올바른 위치에 마운트되어 있어도 Plex가 환경 설정을 저장하거나 데이터베이스 파일을 열거나 디렉터리를 생성하지 못하는 것처럼 보입니다.
Plex가 앱 데이터를 생성하거나 업데이트하지 못한다면, 설정 디렉터리 권한을 확인해야 합니다. 무조건 재귀적으로 `777` 권한을 적용해 해결하려 하지 말고 숫자형 권한을 기준으로 점검하세요.
컨테이너 내부에서 사용자 ID를 확인하고 호스트의 숫자형 소유자 및 권한과 비교하세요. 의도한 서비스 계정에 필요한 접근 권한만 부여하도록 최소한의 소유권 또는 ACL 수정만 적용하세요. 그런 다음 Plex를 시작하고 새 설정 화면이 아니라 기존 서버를 여는지 확인하세요.
숫자형 소유권이 일치하는데도 접근이 실패한다면 데이터베이스를 변경하기 전에 ACL, 컨테이너 보안 레이블 및 사용자 네임스페이스 동작을 확인하세요. UID/GID가 올바르더라도 별도의 접근 제어 계층을 무시할 수는 없습니다.
애플리케이션 상태가 복원된 후에만 미디어 마운트를 확인하세요
기존 서버 ID와 라이브러리가 다시 나타난 후에도 `/config`와 별도로 미디어 마운트가 변경되어 일부 라이브러리를 사용할 수 없을 수 있습니다. 이는 별도의 영구 저장 문제입니다. 라이브러리를 다시 만들거나 미디어를 애플리케이션 데이터 디렉터리로 복사하지 말고 미디어 경로를 수정하세요.
애플리케이션 상태와 미디어 마운트를 서로 별도의 영구 저장 영역으로 유지하세요. 이렇게 분리하면 먼저 Plex의 서버 ID를 복원한 다음 기존 라이브러리가 다시 나타난 후에만 누락된 미디어 경로를 점검할 수 있습니다.
Plex 컨테이너 내부에서 알려진 미디어 경로 몇 곳을 열어 보세요. 기존 데이터베이스가 `/media/movies`를 가리키는데 재생성된 스택이 `/movies`를 노출한다면, 예상한 컨테이너 내부 경로를 복원하거나 라이브러리 경로를 통제된 방식으로 마이그레이션할 계획을 세우세요. 마운트가 안정되기 전에는 다시 검색하지 마세요.
기존 상태가 정말 사라진 경우에만 백업에서 복원하세요
기존 호스트 디렉터리가 비어 있거나 삭제되었거나 사용할 수 없을 정도로 손상되었다면, 최근의 정상 Plex 앱 데이터 백업을 깨끗하고 올바르게 매핑된 경로에 복원하세요. 실패한 상태는 별도로 보존하여 유일한 증거를 덮어쓰지 말고 문제의 원인을 계속 조사할 수 있게 하세요.
신뢰할 수 있는 컨테이너 복구 절차는 영구 `/config`를 보호하고, 교체 가능한 애플리케이션 계층만 교체하며, Plex가 다시 기록하기 전에 마운트를 확인합니다.
복원 후 서버 ID, 라이브러리 수, 시청 상태, 로컬 재생, 사용하는 경우 트랜스코딩 및 한 번의 재시작을 확인하세요. 그런 다음 실제 스택 설정과 백업 위치를 기록하세요. 다음에 스택을 재생성했을 때 수작업으로 추측하지 않아도 동일한 영구 데이터를 가리킬 수 있을 때만 문제가 해결된 것입니다.
지원 및 팁
더 읽어보기

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

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

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

