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

에바 왕

IceWhale author

에바 왕 는 기술 작가 그리고 이자 ZimaSpace의 상주 장인입니다. 평생을 기술에 열정을 가진 사람으로서 홈랩과 오픈소스 소프트웨어에 열정을 가지고 있으며,복잡한 기술 개념을 쉽게 이해할 수 있는 실습 가이드로 번역하는 데 전문성을 가지고 있습니다.에바는 셀프 호스팅이 어렵지 않고 재미있어야 한다고 믿습니다. 그녀의 튜토리얼을 통해 커뮤니티가 하드웨어 설정의 신비를 풀도록돕고 있습니다. 첫 NAS 구축부터 Docker 컨테이너 마스터링까지.

How to Restore Jellyfin Permissions After Moving Its Data Directory - Zima Store Online

Jellyfin의 데이터 디렉터리를 옮긴 후에는 실제로 Jellyfin을 실행하는 사용자 ID에 맞게 이동한 파일의 권한을 복원하고, 컨테이너 또는 서비스가 의도한 경로를 가리키는지 확인하세요. 처음부터 chmod -R 777을 사용하지 마세요.

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

새 경로와 Jellyfin 런타임 ID 확인

백그라운드 기록 작업이 검사와 충돌하지 않도록 이동한 애플리케이션 데이터를 복구하기 전에 Jellyfin을 중지하세요. 새로운 호스트 경로, 컨테이너 또는 서비스 내부에서 Jellyfin이 인식하는 경로, 그리고 실행 중인 Jellyfin 사용자의 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 사용자로 전용 테스트 하위 디렉터리에 비파괴적인 쓰기 가능성 검사를 실행하세요. 여전히 쓰기가 거부된다면 chmod를 계속 추가하지 말고 다음으로 ACL, 마운트 모드 또는 보안 레이블을 검사하세요.

Featured

ZimaCube 2 개인용 클라우드 홈 NAS

ZimaCube2

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

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

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

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

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

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

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

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

광범위한 변경을 되돌리고 정확한 증거와 함께 문제 제기

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

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

Jellyfin이 원래 데이터베이스를 열고, 자체 데이터 디렉터리에 기록하며, 선택한 백그라운드 작업을 완료하고, 다시 시작한 후에도 정상 작동할 때 중단하세요. 이러한 검사 중 하나라도 계속 실패한다면 숫자 소유권, ACL 출력, 마운트 옵션, 런타임 UID/GID 및 최초의 권한 관련 로그 오류를 함께 제출하여 문제를 제기하세요.