Błąd Folder „/tv/” nie jest zapisywalny przez użytkownika „abc” oznacza, że Sonarr może zobaczyć zamontowany katalog, ale proces uruchomiony wewnątrz kontenera nie ma uprawnień do zapisu. Ten sam problem może wystąpić w Radarr jako błąd dotyczący głównego folderu filmów.
W przypadku z lipca 2025 r. ze społeczności IceWhale obie aplikacje pochodziły ze sklepu z aplikacjami ZimaOS i korzystały z ustawień domyślnych PUID=1000 i PGID=1000. Foldery multimediów użytkownika znajdowały się na puli pamięci RAID. Członek zespołu IceWhale zasugerował ustawienie obu identyfikatorów na 0, a autor pierwotnego wpisu potwierdził, że dzięki temu foldery stały się zapisywalne. To istotny wynik źródłowy, ale uruchamianie aplikacji z identyfikatorami równoważnymi uprawnieniom administratora zapewnia znacznie szerszy dostęp do systemu plików, niż jest zwykle potrzebny. Aktualna dokumentacja LinuxServer.io zaleca dopasowanie PUID/PGID do właściciela lub grupy katalogów hosta.
Co oznacza komunikat „Folder nie jest zapisywalny przez użytkownika abc”
Pakiet ZimaOS ze sklepu z aplikacjami opisany w wątku korzystał z kontenerów Sonarr i Radarr w stylu LinuxServer. Obrazy te uruchamiają proces aplikacji jako użytkownik wewnętrzny, zwykle wyświetlany jako abc, podczas gdy PUID i PGID zmapować ten wewnętrzny proces na numeryczne identyfikatory użytkownika i grupy w systemie plików hosta.
Jeśli katalog hosta należy do innego identyfikatora UID/GID, a jego bity uprawnień nie pozwalają zmapowanemu procesowi na zapis, Sonarr lub Radarr mogą przeglądać punkt montowania, ale nie mogą tam tworzyć, zmieniać nazw, przenosić ani importować multimediów.
Oryginalne mapowania sklepu z aplikacjami ZimaOS
Wpis zawierał osobne zrzuty konfiguracji Radarr i Sonarr. Aplikacje miały dostęp do skonfigurowanych woluminów hosta, ale tworzenie folderu głównego kończyło się niepowodzeniem wewnątrz aplikacji.
Błędy Sonarr i Radarr
Sonarr zwrócił:
Nie można dodać folderu głównego
Folder „/tv/” nie jest zapisywalny przez użytkownika „abc”
Radarr wyświetlał odpowiadający mu problem dotyczący ścieżki filmów:
Rozwiązanie społeczności: PUID=0 i PGID=0
Odpowiedział członek zespołu IceWhale:
PUID=0
PGID=0Autor pierwotnego wpisu zmienił obie wartości na zero i zgłosił, że problem został rozwiązany. Jest to zatem potwierdzone rozwiązanie dla tej konkretnej konfiguracji sklepu aplikacji ZimaOS z lipca 2025 roku.
Jednak UID 0 i GID 0 to w systemie Linux identyfikatory uprawnień roota. Uruchamianie Sonarr lub Radarr z tymi identyfikatorami może pozwolić aplikacji na zapisywanie danych w lokalizacjach znacznie wykraczających poza zamierzoną bibliotekę multimediów, jeśli te ścieżki są zamontowane w kontenerze. Używaj tego wyłącznie jako diagnostycznego lub zgodnościowego rozwiązania tymczasowego, gdy rozumiesz zakres przyznanego dostępu.
Preferowane rozwiązanie: dopasuj PUID i PGID do właściciela magazynu hosta
Aktualna dokumentacja LinuxServer.io dotycząca Sonarr i Radarr wyjaśnia zamierzone rozwiązanie: ustaw wartości PUID i PGID zgodnie z właścicielem magazynu hosta PUID i PGID do użytkownika/grupy hosta, który już jest właścicielem zamapowanego woluminu lub ma do niego uprawnienia zapisu.
Zgodnie z zaleceniami LinuxServer problemy z uprawnieniami pojawiają się, gdy wolumin hosta jest własnością identyfikatorów, które nie odpowiadają identyfikatorom przekazanym do kontenera. Zalecany schemat to:
PUID=1000
PGID=1000tylko wtedy, gdy UID 1000 i GID 1000 są rzeczywiście odpowiednie dla ścieżek multimediów. Liczba 1000 nie jest z natury poprawne; to po prostu często spotykany identyfikator pierwszego użytkownika systemu Linux innego niż root.
Zapoznaj się z aktualną dokumentacją LinuxServer dotyczącą Sonarr oraz dokumentacją LinuxServer dotyczącą Radarr.
Jak sprawdzić właściciela magazynu danych i uprawnienia
Jeśli interfejs Pliki w ZimaOS nie wyświetla potrzebnych liczbowych wartości właściciela/grupy systemu Linux, sprawdź rzeczywistą ścieżkę hosta z autoryzowanego terminala.
Najpierw ustal rzeczywisty katalog hosta mapowany na /tv lub /movies. Następnie sprawdź ją:
ls -ldn /REAL/HOST/PATH
stat /REAL/HOST/PATHDane liczbowe pomagają ustalić, który identyfikator UID i GID jest obecnie właścicielem katalogu. Nie uruchamiaj tych poleceń dla ścieżki dostępnej wyłącznie w kontenerze. /tv z hosta, chyba że jest to rzeczywiście ścieżka hosta.
Jeśli zamierzone konto do zarządzania multimediami jest dostępne na hoście, możesz sprawdzić jego identyfikatory za pomocą:
id USERNAMENastępnie ustaw w Sonarr/Radarr PUID i PGID na identyfikatory odpowiadające celowo wybranemu modelowi dostępu.
Nie wykonuj bezrefleksyjnie chown /tv wewnątrz kontenera
Inna odpowiedź społeczności sugerowała:
sudo chown abc:abc /tv/Ta rada jest ryzykowna, jeśli skopiuje się ją bez odpowiedniego kontekstu. Własność katalogu montowanego przez bind mount jest ostatecznie reprezentowana na hoście przez identyfikatory liczbowe. Nazwa abc istnieje w kontenerach LinuxServer i może nie istnieć jako znaczące konto na hoście. Rekurencyjna zmiana właściciela może również nieoczekiwanie wpłynąć na całą bibliotekę multimediów.
Przed użyciem chown, potwierdź:
- dokładna ścieżka na hoście, która będzie zmieniana;
- docelowy UID i GID na hoście;
- czy inne usługi, takie jak qBittorrent, SABnzbd, Jellyfin lub użytkownicy SMB, potrzebują dostępu do tych samych plików;
- czy lepszym rozwiązaniem od zmiany właściciela będzie wspólna grupa.
Utwórz kopię zapasową ważnej konfiguracji i unikaj rekurencyjnych zmian uprawnień, dopóki nie zrozumiesz ich skutków.
Zaplanuj współdzielone uprawnienia do multimediów w całym stosie ARR
Sonarr i Radarr rzadko działają samodzielnie. Klient pobierania najpierw tworzy pliki, następnie Sonarr lub Radarr je importuje, a Jellyfin może odczytywać wynik. Jeśli każdy kontener korzysta z niepowiązanych identyfikatorów i montowań, jedna aplikacja może tworzyć pliki, których inna aplikacja nie będzie mogła modyfikować.
Czytelniejszym rozwiązaniem jest przypisanie aplikacjom wspólnej grupy lub zgodnego mapowania PUID/PGID dla współdzielonego zbioru danych. LinuxServer zaleca również dobrze zaplanowane ścieżki woluminów, aby klienci pobierania i aplikacje ARR mogły w odpowiednich przypadkach korzystać z dowiązań twardych lub atomowych przenosin.
Na przykład zamiast traktować katalogi pobierania i multimediów jako niezależne, odizolowane punkty montowania, jedno wspólne drzewo danych na hoście może ułatwić analizowanie uprawnień i spójności ścieżek:
/data
├── pobieranie
├── multimedia
│ ├── filmy
│ └── tvDokładna ścieżka w ZimaOS zależy od puli pamięci masowej i nie należy kopiować jej bezrefleksyjnie.
Kiedy obejście z identyfikatorami root jest przydatne?
Ustawienie PUID/PGID na 0 może być przydatne jako krótka diagnostyka:
- Jeśli błąd natychmiast zniknie, samo montowanie kontenera jest prawdopodobnie poprawne.
- Pozostały problem prawdopodobnie dotyczy właściciela na hoście lub mapowania uprawnień.
Po potwierdzeniu bezpieczniejszym celem długoterminowym jest przyznanie kontenerowi wyłącznie uprawnień potrzebnych do ścieżek multimediów i pobierania. Jeśli dokładny model pamięci masowej ZimaOS uniemożliwia praktyczne zastosowanie mapowania bez uprawnień administratora, udokumentuj, dlaczego wymagane są identyfikatory root, i ostrożnie ogranicz zamontowane katalogi.
Uruchom ponownie aplikacje po zmianie PUID lub PGID
PUID i PGID są stosowane podczas uruchamiania kontenera. Po ich zmianie w ZimaOS:
- Zapisz konfigurację aplikacji.
- Uruchom ponownie kontener Sonarr/Radarr lub utwórz go ponownie za pośrednictwem ZimaOS.
- Ponownie otwórz ustawienia folderu głównego.
- Przetestuj tworzenie lub wybieranie zamapowanego folderu.
Jeśli folder nadal nie pozwala na zapis, porównaj numeryczną własność i tryb uprawnień katalogu na hoście z identyfikatorami używanymi obecnie przez kontener.
Lista kontrolna uprawnień Sonarr/Radarr w ZimaOS
- Potwierdź, że ścieżka multimediów na hoście jest zamontowana w Sonarr lub Radarr.
- Potwierdź, że ścieżka kontenera jest tą wybieraną w aplikacji.
- Sprawdź UID, GID i bity uprawnień ścieżki na hoście.
- Sprawdź bieżące
PUIDiPGIDw ustawieniach aplikacji ZimaOS. - Preferuj identyfikatory odpowiadające zamierzonemu właścicielowi/grupie na hoście.
- Po zmianie identyfikatorów uruchom ponownie kontener.
- Używaj identyfikatorów PUID/PGID 0 tylko ze świadomością dostępu na poziomie roota, który zapewniają.
- Unikaj szerokiego rekurencyjnego
chmod 777lub wykonanie w ciemnochownpoprawki. - Upewnij się, że klienci pobierania i serwery multimediów używają zgodnego modelu współdzielonych uprawnień.
Najczęściej zadawane pytania dotyczące uprawnień Sonarr i Radarr
Kim jest użytkownik abc?
abc to nazwa wewnętrznego użytkownika usługi powszechnie używana w kontenerach LinuxServer.io. PUID i PGID określają, której numerycznej tożsamości użytkownika i grupy na hoście używa ten proces podczas uzyskiwania dostępu do zamontowanych woluminów.
Dlaczego PUID=1000 i PGID=1000 zawodzą?
Te wartości działają tylko wtedy, gdy UID/GID 1000 ma wymagany dostęp do katalogu multimediów na hoście. Jeśli katalog RAID w ZimaOS należy do innego użytkownika lub grupy, kontener może mieć możliwość jego odczytu, ale nie zapisu.
Czy PUID=0 i PGID=0 rozwiązują problem?
Rozwiązało to pierwotny przypadek opisany przez społeczność, co potwierdził autor. Zapewnia jednak dostęp równoważny uprawnieniom roota w obrębie zamontowanego systemu plików, dlatego nie powinno być automatycznie preferowaną konfiguracją stałą.
Czy powinienem wykonać chmod 777 na folderze multimediów?
Nie jako domyślne rozwiązanie. Uprawnienia do zapisu dla wszystkich są niepotrzebnie szerokie i mogą ukryć rzeczywisty problem z niezgodnością własności. Zamiast tego celowo dopasuj tożsamość kontenera oraz uprawnienia współdzielonej grupy.
Czy Sonarr, Radarr i klient pobierania powinny używać tego samego PUID/PGID?
Nie zawsze muszą używać identycznych identyfikatorów użytkowników, ale w przypadku udostępnianych plików i folderów potrzebują zgodnego modelu własności i grup. Używanie jednej, spójnej grupy współdzielonej to powszechny sposób na uniknięcie błędów importu i zmiany nazw.
