네트워크 공유를 다시 마운트한 후 변경되지 않은 미디어 라이브러리를 미디어 서버가 다시 스캔하지 않도록 하는 방법

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

미디어 서버는 저장소가 잠시 사라지거나 스캐너가 변경된 것으로 판단하는 파일 시스템 상태로 돌아온 후 네트워크 공유를 다시 마운트하면, 변경되지 않은 라이브러리를 다시 스캔할 수 있습니다.

이는 일반적인 시작 시 스캔보다 범위가 좁습니다. 안전하다면 미디어 서버 프로세스를 계속 실행한 상태에서 동일한 SMB 또는 NFS 공유를 의도적으로 다시 마운트하고, 전환 전·중·후에 서버가 인식하는 상태를 기록하세요. 중요한 기준은 미디어 파일 자체가 변경되지 않았는데도 라이브러리 경로가 비어 있거나, 액세스할 수 없거나, 새로 마운트되거나, 다른 변경 신호를 생성하는지 여부입니다.

공유 마운트 해제 및 재마운트 이후 다시 스캔되는지 확인

관련 없는 예약 스캔을 일시적으로 비활성화한 다음, 유지 관리 시간에 테스트 공유 하나를 마운트 해제하고 다시 마운트하면서 라이브러리 스캔 로그를 기록하세요. 공유가 사라지지 않는 일반적인 서버 재시작 상황과 스캔 트리거를 비교하세요.

Jellyfin은 원격 미디어 저장소를 사용할 수 없는 동안 예약된 유지 관리가 실행되면 저장소를 사용할 수 없어 항목이 삭제될 수 있다고 경고합니다.

공유 전환 직후에만 다시 스캔이 시작된다면 원인을 저장소 가시성과 스캐너 이벤트로 좁히세요. 마운트 변경이 전혀 없는데 서버가 다시 스캔한다면 예약 작업이나 데이터베이스의 지속 상태를 다시 확인하세요.

재마운트 중에도 라이브러리 경로 유지

원격 공유가 다시 연결되기 전, 연결되는 동안, 연결된 후에 호스트의 마운트 지점을 점검하세요. 동일한 경로에 있는 비어 있는 일반 디렉터리는 명시적인 마운트 실패보다 위험할 수 있습니다. 미디어 서버가 이를 유효하지만 비어 있는 라이브러리로 해석할 수 있기 때문입니다.

최신 Jellyfin 문제 해결 가이드는 마운트 실패로 라이브러리가 비워지고 대규모 보정 스캔이 시작될 수 있는 이유를 설명합니다.

비어 있는 대체 디렉터리를 노출하는 대신 명확하게 실패하는 마운트 방식을 사용하세요. 미디어 서버 컨테이너나 서비스가 해당 경로에 다시 액세스하도록 허용하기 전에 호스트에서 보이는 상태를 확인하세요.

네트워크 파일 시스템과 로컬 변경 알림 구분

서버가 파일 시스템 감시기, 주기적 스캔, 애플리케이션 콜백 또는 타사 미디어 관리자를 사용하고 있는지 확인하세요. 원격 마운트는 직접 연결된 파일 시스템과 동일한 로컬 변경 알림을 항상 제공하지 않습니다.

Plex는 네트워크 공유에는 변경 트리거가 없어 주기적 또는 명시적 스캔이 필요할 수 있다고 설명합니다.

해결 방법으로 빈번한 주기적 스캔과 광범위한 외부 새로 고침 훅을 모두 활성화하지 마세요. 신뢰할 수 있는 알림 전략 하나를 선택하여 재마운트로 인해 여러 전체 라이브러리 스캔이 겹쳐 실행되지 않도록 하세요.

컨테이너가 다시 연결되기 전에 저장소 준비

미디어 서버가 Docker에서 실행된다면 원격 마운트가 준비되는 시간과 컨테이너의 시작 또는 재시작 시간을 비교하세요. 컨테이너가 호스트의 마운트 지점을 아직 비어 있는 로컬 디렉터리 상태에서 연결한 뒤, 나중에 NAS가 그 아래에 나타나는 상황이 발생할 수 있습니다.

Linux 홈 서버 가이드는 원격 저장소에 의존하는 애플리케이션의 경우 Docker보다 저장소를 먼저 마운트해야 한다고 설명합니다.

긴 고정 대기 시간 대신 제한된 마운트 의존성이나 준비 상태 확인을 사용하세요. 미디어 서버는 실제 라이브러리를 사용할 수 있는 상태로 시작하거나, 빈 자리 표시자를 색인할 수 없도록 충분히 명확하게 실패해야 합니다.

inotify가 모든 NAS 변경 사항을 감지한다고 기대하지 않기

Linux에서는 자동 미디어 감지가 로컬 파일 시스템 이벤트를 기반으로 구축되는 경우가 많습니다. NAS에서 직접 파일을 추가했을 때 미디어 서버 호스트에서 감시 이벤트가 생성되는지, 그리고 재마운트 시 더 광범위한 디렉터리 변경 신호가 생성되는지 비교하세요.

홈 서버 자동 마운트 가이드는 inotify가 네트워크 파일 시스템의 변경을 놓치며 적절한 경우 애플리케이션에서 명시적으로 알림을 보내도록 권장합니다.

감시기 동작이 불안정하다면 서버가 변경되지 않은 전체 라이브러리를 다시 검색하도록 강제하는 대신, 미디어 관리자나 서버 API를 사용해 새로 추가된 콘텐츠에 대한 대상 스캔을 요청하세요.

전체 재스캔 없이 한 번의 제어된 재마운트 확인

마운트 가시성, 시작 순서 또는 스캔 트리거를 수정한 후 라이브러리 데이터베이스, 항목 수, 스캔 로그를 확인하면서 공유를 두 번 다시 마운트하세요. 그런 다음 테스트 파일 하나를 추가하여 새 미디어가 정상적으로 감지되는지 확인하세요.

홈 미디어 비교 자료는 NAS 프로토콜이 마운트 동작을 바꾸며, 미디어 서버가 원격 파일 시스템을 직접 소유하는 것은 아니라고 설명합니다.

변경되지 않은 라이브러리가 재마운트 후 전체 재스캔 없이 유지되고, 선택한 업데이트 방식으로 새 파일도 계속 표시되면 문제가 해결된 것입니다. 증상이 호스트 재부팅 후에만 발생한다면 Jellyfin 재부팅 후 재스캔에 관한 관련 ZimaSpace 문서가 올바른 해결 경로입니다.

지원 및 팁

더 읽어보기

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.