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.
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

Jak zoptymalizować połączenia z bazą danych Jellyfin dla kontenerów działających równocześnie
Zacznij od jednego właściciela bazy danych i zmierz zachowanie blokad SQLite; dodaj inny backend dopiero wtedy, gdy współbieżność i odzyskiwanie danych uzasadnią tę złożoność.

Jak zapobiegać duplikowaniu zadań lub importów w Jellyfin
Duplikowanie pracy zwykle wynika z nakładających się harmonogramów lub więcej niż jednego procesu zapisującego; wyznacz jednego właściciela, jedną ścieżkę i jeden sposób sprawdzania ukończenia.

Jak naprawić Jellyfin po zapełnieniu woluminu bazy danych
Wstrzymaj zapisy, zachowaj bazę danych i pliki WAL, zwolnij miejsce bez bezmyślnego usuwania stanu, a następnie zweryfikuj integralność i pierwotne działanie.

