Dlaczego Jellyfin odtwarza brakujące pliki z niewłaściwym właścicielem?

Eva Wong jest Technicznym pisarzem i stałym majsterkowiczem w ZimaSpace. Całe życie geek z pasją do homelabów i oprogramowania open-source, specjalizuje się w tłumaczeniu skomplikowanych koncepcji technicznych na przystępne, praktyczne przewodniki. Eva wierzy, że samodzielne hostowanie powinno być zabawą, a nie czymś onieśmielającym. Poprzez swoje samouczki umożliwia społeczności rozwiewanie tajemnic konfiguracji sprzętu, od budowy pierwszego NAS po opanowanie kontenerów Docker.

Jellyfin zwykle ponownie tworzy pliki z niewłaściwym właścicielem, gdy aktywna tożsamość usługi różni się od właściciela katalogu lub druga ścieżka importu używa innego UID/GID.

Czy problem dotyczy tylko nowo pobranych grafik, czy każdego pliku zapisywanego przez Jellyfin? Przed uruchomieniem jakiegokolwiek rekurencyjnego polecenia zmiany uprawnień porównaj jeden działający plik, jeden nowo utworzony plik, aktywną tożsamość kontenera oraz miejsce docelowe montowania bind. Celem jest naprawa dziedziczenia, a nie wielokrotne usuwanie skutków problemu.

Ustal, która tożsamość i ścieżka wykonały zapis

Sprawdź użytkownika i grupy działającego kontenera, a następnie zbadaj aktywne montowanie bind zamiast polegać na pliku Compose zapisanym na dysku. Potwierdź, że ścieżki konfiguracji i pamięci podręcznej Jellyfin są zapisywalne, natomiast multimedia pozostają tylko do odczytu, gdy dostęp do zapisu nie jest wymagany. Warstwowa kontrola uprawnień pozwala rozróżnić widoczność na hoście, mapowanie w kontenerze i tożsamość usługi.

Jeśli host widzi plik, ale kontener nie, napraw montowanie. Jeśli kontener może zapisywać, ale właściciel jest niewłaściwy, przejdź do testu tożsamości i dziedziczenia.

Jeśli tylko importowane pliki mają niewłaściwego właściciela, porównaj UID/GID oraz umask importera z wartościami Jellyfin. Jeśli każdy nowy plik jest niewłaściwy, sprawdź domyślną listę ACL katalogu nadrzędnego oraz działanie bitu setgid.

Sprawdź umask, grupy, listy ACL i proces importu

Porównaj UID/GID i tryb katalogu nadrzędnego z procesem, który tworzy plik. Downloader, zadanie harmonogramu lub sidecar może zapisywać przez inny kontener, mimo że Jellyfin później wyświetla ten element. Przed zmianą całego drzewa sprawdź grupy dodatkowe i domyślne listy ACL.

Nie stosuj rekurencyjnej zmiany uprawnień na zapis dla wszystkich jako trwałego rozwiązania. Dopasuj tożsamość usługi do zamierzonej grupy albo jawnie skonfiguruj współdzieloną grupę i domyślną listę ACL dla konkretnych katalogów, które wymagają współpracy.

Po zmianie tożsamości przetestuj jeden nowy plik za pośrednictwem dokładnej ścieżki importu. Nie oceniaj poprawki na podstawie plików utworzonych przed ponownym utworzeniem kontenera lub sidecara.

Napraw dziedziczenie i zweryfikuj je po ponownym utworzeniu

Zastosuj najmniejszą niezbędną zmianę właściciela lub listy ACL w dotkniętym problemem katalogu, utwórz ponownie jeden plik testowy i sprawdź jego właściciela oraz tryb. Utwórz ponownie kontener i uruchom ponownie hosta, a następnie powtórz ten sam import, aby poprawka przetrwała wdrożenie i kolejność montowania.

Eskaluj problem, gdy zmiany właściciela wracają po całkowicie czystym ponownym utworzeniu, system plików ignoruje własność POSIX lub wiele usług konkuruje o zarządzanie tą samą ścieżką. Zachowaj działający plik i konfigurację Compose, jednocześnie zawężając poszukiwania do procesu wykonującego zapis.

Jeśli po ponownym uruchomieniu właściciel znów się zmienia, montowanie lub wdrożenie stosuje inną tożsamość. Zachowaj działającą konfigurację Compose, zanim ponownie zmienisz drzewo systemu plików.

-15% OFF

Zweryfikuj własność po ponownym uruchomieniu i imporcie

Utwórz ponownie kontener, uruchom ponownie hosta i zaimportuj jeden kontrolowany plik testowy. Potwierdź właściciela, grupę, tryb oraz widoczność w Jellyfin zarówno z hosta, jak i z kontenera.

Zachowaj poprawkę, gdy nowe pliki dziedziczą zamierzoną grupę, a Jellyfin może odczytywać lub zapisywać tylko w katalogach wymaganych przez dany proces. Nie przyznawaj szerokiego dostępu do zapisu w całym drzewie multimediów.

Eskaluj problem, gdy system plików, warstwa ACL lub wiele procesów zapisujących nadal zmienia właściciela po kontrolowanym ponownym imporcie.

Wsparcie i wskazówki

Więcej do przeczytania

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.