데이터 디렉터리를 이동한 후 Jellyfin 권한 복원 방법

Jellyfin 데이터 디렉터리를 이동한 뒤에는 이동한 파일의 소유권을 Jellyfin을 실제로 실행하는 ID에 맞추고, 컨테이너나 서비스가 의도한 경로를 가리키는지 확인해 권한을 복구하세요. 먼저 chmod -R 777을 실행하지 마세요.

이동 과정에서 숫자로 표시되는 소유권, 상속된 ACL, 마운트 옵션, SELinux 레이블 또는 새로 만든 컨테이너에 사용된 UID/GID가 달라질 수 있습니다. 이러한 항목을 순서대로 진단하고 Jellyfin 소유 데이터만 수정한 다음, 미디어 라이브러리 권한을 건드리기 전에 서버를 시작해 데이터베이스, 메타데이터, 백업, 예약 작업의 쓰기를 확인하세요.

새 경로와 Jellyfin 실행 ID 확인

백그라운드 쓰기 작업이 검사와 겹치지 않도록 이동한 애플리케이션 데이터를 복구하기 전에 Jellyfin을 중지하세요. 새 호스트 경로, 컨테이너나 서비스 내부에서 Jellyfin이 보는 경로, 실행 중인 Jellyfin ID의 UID/GID를 확인하세요.

Jellyfin 마이그레이션 안내에서는 Jellyfin 사용자의 uid와 gid를 확인하고 마이그레이션 중 예상 경로를 유지할 것을 명시적으로 권장합니다. Jellyfin 마이그레이션 UID/GID 안내

컨테이너가 잘못된 호스트 디렉터리를 가리키면 먼저 마운트를 바로잡으세요. 권한을 수정해도 Jellyfin이 빈 폴더를 가리키도록 하는 경로 매핑은 해결되지 않으며, 해당 빈 경로에서 시작하면 새로운 데이터 트리가 하나 더 만들어질 수 있습니다.

변경 전에 소유권, 모드 비트, ACL 검사

이동한 디렉터리와 데이터베이스, 구성, 메타데이터, 로그 하위 디렉터리의 예시에서 숫자로 표시된 소유자와 그룹을 확인하세요. 상위 디렉터리의 실행 권한과 대상 파일 시스템에서 상속되었을 수 있는 ACL 항목도 확인하세요.

특히 SMB, NFS 또는 컨테이너를 사용하는 경우, NAS로 옮기면 다른 ID 및 권한 모델이 적용될 수 있습니다. ZimaSpace의 이동 후 권한 진단에서는 마운트된 경로가 표시되더라도 컨테이너 프로세스의 UID/GID 권한 검사를 우회할 수 없는 이유를 설명합니다.

정확히 무엇이 잘못되었는지 설명할 수 있을 때까지 아무것도 변경하지 마세요. 소유자 오류, 그룹 액세스 누락, 상위 디렉터리 탐색 차단, 예상치 못한 ACL 또는 읽기 전용 마운트 중 무엇인지 밝혀야 합니다. 이 내용에 따라 가장 작고 안전한 복구 방법을 정할 수 있습니다.

Jellyfin 소유 애플리케이션 데이터에만 소유권 복구

이동한 Jellyfin 데이터 디렉터리를 Jellyfin 서비스 계정이 소유해야 한다면, 해당 애플리케이션 데이터 트리의 소유자와 그룹을 원래 의도대로 복구하세요. Jellyfin이 해당 파일을 실제로 관리해야 하는 경우가 아니라면, 관련 없는 공유 미디어의 소유권은 그대로 유지하세요.

Jellyfin의 마이그레이션 문서에는 이동 후 Jellyfin 데이터 디렉터리의 소유권을 바로잡는 방법이 나와 있습니다. 마이그레이션 후 소유권 수정 이는 특정 애플리케이션 데이터에 대한 작업이지, NAS 공유 전체의 소유권을 재귀적으로 변경할 이유가 아닙니다.

소유권을 수정한 후 샘플을 다시 확인하고, 전용 테스트 하위 디렉터리에 대해 Jellyfin ID로 비파괴 쓰기 가능 여부를 검사하세요. 여전히 쓰기가 거부된다면 chmod 변경을 더 추가하지 말고 ACL, 마운트 모드 또는 보안 레이블을 확인하세요.

Featured

ZimaCube 2 개인용 클라우드 홈 NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

컨테이너 마운트 모드와 보안 레이블 확인

호스트에서 소유자가 올바르더라도 바인드 마운트가 읽기 전용이거나 런타임 사용자가 바뀌었거나 호스트 보안 시스템이 경로를 차단하면 컨테이너 내부에서는 실패할 수 있습니다. 현재 컨테이너 정의를 마지막으로 정상 작동했을 때의 정의와 비교하세요.

Jellyfin 컨테이너 가이드에는 명시적인 UID/GID 실행, 읽기 전용 미디어 마운트, SELinux 환경을 위한 Podman 재레이블 옵션이 나와 있습니다. 컨테이너 권한 및 재레이블 이러한 설정은 일반적인 Unix 권한 비트상 허용되는 것으로 보여도 실제 접근을 제한할 수 있습니다.

확인된 계층만 변경하세요. Jellyfin이 애플리케이션 데이터 마운트에 써야 한다면 쓰기 가능하게 설정하고, 올바른 런타임 UID/GID를 복원하거나 해당 마운트에 플랫폼에 맞는 레이블을 적용하세요. 그런 다음 컨테이너를 한 번 다시 만들고 내부에서 같은 경로를 다시 확인하세요.

Jellyfin을 시작하고 데이터베이스 및 데이터 디렉터리 쓰기를 확인하세요

Jellyfin을 시작하고 시작 로그를 살펴보세요. 설정 마법사나 빈 라이브러리가 아니라 기존 서버 상태를 여는지 확인하고, 데이터베이스, 설정, 메타데이터 또는 로그의 권한 오류가 있는지 살펴보세요.

시작 시 정상 대시보드가 표시되면 테스트 환경에서 예약 작업이나 메타데이터 작업처럼 Jellyfin이 관리하는 상태에 쓰는 위험이 낮은 작업을 하나 실행하세요. 권한 오류 없이 예상한 파일 또는 데이터베이스 상태가 변경되는지 확인하세요.

Jellyfin을 한 번 더 재시작하세요. 새로 시작한 후에도 동일한 데이터 디렉터리가 문제없이 열려야 복구가 완료된 것입니다. 한 세션에서의 성공은 컨테이너를 다시 만들 때 재발하는 마운트 또는 초기화 문제를 가릴 수 있습니다.

광범위한 변경 사항을 롤백하고 정확한 증거와 함께 문제를 보고하세요

이미 광범위한 재귀 권한 변경을 적용했는데도 서버가 여전히 작동하지 않는다면 접근 권한을 계속 확대하지 마세요. 가능하면 기록해 둔 소유권 설정이나 백업에서 복원한 다음, 구체적인 런타임 ID와 경로 불일치를 다시 확인하세요.

컨테이너 서버라면 현재 마운트 소스, 대상, UID/GID, 그룹, 보안 컨텍스트를 저장해 둔 정상 작동 정의와 비교하세요. 네이티브 설치라면 서비스 ID와 대상 파일 시스템의 마운트 및 ACL 동작을 비교하세요. 목표는 설명 가능한 단일 권한 모델을 만드는 것입니다.

Jellyfin이 기존 데이터베이스를 열고, 자체 데이터 디렉터리에 쓰고, 선택한 백그라운드 작업을 완료하며, 재시작 후에도 정상 작동하면 중단하세요. 이 확인 중 하나라도 실패하면 숫자로 표시된 소유권, ACL 출력, 마운트 옵션, 런타임 UID/GID, 권한 관련 첫 로그 오류를 포함해 문제를 보고하세요.