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

에바 왕

IceWhale author

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

Why Does Jellyfin Recreate Missing Files With the Wrong Owner? - Zima Store Online

활성 서비스 ID가 디렉터리 소유자와 다르거나 두 번째 가져오기 경로에서 다른 UID/GID를 사용하면 Jellyfin은 대개 잘못된 소유자로 파일을 다시 생성합니다.

문제가 새로 다운로드한 아트워크에만 영향을 주나요, 아니면 Jellyfin이 작성하는 모든 파일에 영향을 주나요? 재귀 권한 명령을 실행하기 전에 정상적으로 작동하는 파일 하나, 새로 생성된 파일 하나, 활성 컨테이너 ID, 바인드 마운트 대상 경로를 비교하세요. 목표는 증상을 반복해서 수정하는 것이 아니라 상속을 바로잡는 것입니다.

어떤 ID와 경로에서 쓰기를 수행했는지 확인

실행 중인 컨테이너의 사용자와 그룹을 확인한 다음, 디스크에 있는 Compose 파일에 의존하지 말고 실제 바인드 마운트를 검사하세요. Jellyfin의 구성 및 캐시 경로에 쓰기 권한이 있는지 확인하고, 쓰기 액세스가 필요하지 않은 경우 미디어는 읽기 전용으로 유지하세요. 단계별 권한 확인을 통해 호스트에서의 가시성, 컨테이너 매핑, 서비스 ID를 구분할 수 있습니다.

호스트에서는 파일이 보이지만 컨테이너에서 보이지 않는다면 마운트를 수정하세요. 컨테이너에서 쓸 수 있지만 소유자가 잘못된 경우에는 ID 및 상속 테스트를 계속 진행하세요.

가져온 파일에만 잘못된 소유자가 지정된다면 가져오기 작업자의 UID/GID와 umask를 Jellyfin의 설정과 비교하세요. 새로 생성되는 모든 파일의 소유자가 잘못된 경우에는 상위 디렉터리의 기본 ACL과 setgid 동작을 확인하세요.

umask, 그룹, ACL, 가져오기 작업자 확인

상위 디렉터리의 UID/GID 및 모드와 파일을 생성하는 프로세스를 비교하세요. 다운로드 프로그램, 예약 작업 또는 사이드카가 다른 컨테이너를 통해 파일을 작성할 수 있으며, 이후 Jellyfin이 해당 항목을 표시할 수도 있습니다. 전체 트리를 변경하기 전에 추가 그룹과 기본 ACL을 확인하세요.

영구적인 해결 방법으로 모든 사용자에게 쓰기 권한을 부여하는 재귀적 권한 변경을 사용하지 마세요. 서비스 ID를 의도한 그룹에 맞추거나, 협업이 필요한 정확한 디렉터리에 공유 그룹과 기본 ACL을 명시적으로 설정하세요.

ID를 변경한 후 정확히 동일한 가져오기 경로를 통해 새 파일 하나를 테스트하세요. 컨테이너나 사이드카를 다시 생성하기 전에 만들어진 파일로 해결 여부를 판단하지 마세요.

상속 수정 및 재생성 후 검증

영향을 받는 디렉터리에 최소한의 소유권 또는 ACL 변경만 적용하고, 테스트 파일 하나를 다시 생성한 뒤 소유자와 모드를 확인하세요. 컨테이너를 다시 생성하고 호스트를 재부팅한 다음 동일한 가져오기를 반복하여 배포 및 마운트 순서가 바뀌어도 해결 방법이 유지되는지 확인하세요.

컨테이너를 정상적으로 재생성한 후에도 소유권이 다시 변경되거나, 파일 시스템이 POSIX 소유권을 무시하거나, 여러 서비스가 동일한 경로를 관리하려고 경쟁하는 경우에는 추가 조사를 진행하세요. 작업 중인 파일과 Compose 구성을 보존한 채 파일을 작성하는 주체를 좁혀 가세요.

재부팅 후 소유권이 다시 변경된다면 마운트 또는 배포 설정에서 다른 ID를 적용하고 있는 것입니다. 파일 시스템 트리를 다시 변경하기 전에 정상적으로 작동하는 Compose 구성을 보존하세요.

-15% OFF