Community-Lösung

Sonarr- und Radarr-Fehler „Ordner nicht beschreibbar“ auf ZimaOS beheben

A ZimaOS App Store user mapped Sonarr and Radarr to a RAID pool but both reported that /tv or /movies was not writable by user abc. Setting PUID/PGID to 0 resolved the original case, while current LinuxServer guidance favors matching container IDs to host ownership.

Der Fehler Der Ordner „/tv/“ ist für den Benutzer „abc“ nicht beschreibbar. Das bedeutet, dass Sonarr das eingebundene Verzeichnis sehen kann, der darin ausgeführte Prozess jedoch keine Berechtigung zum Schreiben hat. Dasselbe Problem kann in Radarr als Fehler beim Stammordner für Filme auftreten.

Im Fall der IceWhale Community vom Juli 2025 stammten beide Anwendungen aus dem ZimaOS-App-Store und verwendeten die Standardwerte PUID=1000 und PGID=1000. Die Medienordner des Benutzers befanden sich auf einem RAID-Speicherpool. Ein Mitglied des IceWhale-Teams schlug vor, beide IDs auf 0, und der ursprüngliche Verfasser bestätigte, dass die Ordner dadurch beschreibbar wurden. Das ist ein wichtiges Ergebnis aus der Quelle, allerdings gewährt der Betrieb der Anwendung mit Root-äquivalenten IDs deutlich umfassenderen Dateisystemzugriff, als normalerweise erforderlich ist. Die aktuelle Dokumentation von LinuxServer.io empfiehlt stattdessen, PUID/PGID an den Besitzer oder die Gruppe der Host-Verzeichnisse anzupassen.

Was „Ordner ist für Benutzer abc nicht beschreibbar“ bedeutet

Das ZimaOS-App-Store-Paket in diesem Thread verwendete Sonarr- und Radarr-Container nach LinuxServer-Art. Diese Images führen den Anwendungsprozess unter einem internen Benutzer aus, der üblicherweise als abc, während PUID und PGID diesen internen Prozess auf numerische Benutzer- und Gruppen-IDs im Host-Dateisystem abbilden.

Wenn das Host-Verzeichnis einer anderen UID/GID gehört und seine Berechtigungsbits dem eingebundenen Prozess das Schreiben nicht erlauben, können Sonarr oder Radarr die Einbindung durchsuchen, dort aber keine Medien erstellen, umbenennen, verschieben oder importieren.

ZimaOS-Speicheransicht mit dem RAID-Speicherort, der für die Medienordner von Sonarr und Radarr verwendet wird
Der ursprüngliche Benutzer hatte Sonarr und Radarr einem zentralen RAID-Speicherpool zugeordnet, anstatt die Medien im App-Datenverzeichnis zu belassen.

Die ursprünglichen ZimaOS-App-Store-Einbindungen

Der Beitrag enthielt separate Konfigurations-Screenshots für Radarr und Sonarr. Die Anwendungen konnten die konfigurierten Host-Volumes sehen, aber das Erstellen von Stammordnern schlug innerhalb der Anwendungen fehl.

ZimaOS-Radarr-App-Store-Konfiguration mit Medienvolume sowie PUID- und PGID-Einstellungen
Die Radarr-App-Store-Konfiguration verwendete eingebundenen Medienspeicher und die Standardwerte für PUID/PGID.
ZimaOS-App-Store-Konfiguration von Sonarr mit TV-Speicher sowie PUID- und PGID-Einstellungen
Die Sonarr-Konfiguration hatte das TV-Verzeichnis eingebunden, aber dem Containerbenutzer fehlten weiterhin die Schreibrechte auf das Ziel.

Die Sonarr- und Radarr-Fehler

Sonarr gab Folgendes zurück:

Stammordner konnte nicht hinzugefügt werden
Der Ordner „/tv/“ ist für den Benutzer „abc“ nicht beschreibbar.
Sonarr meldete, dass der TV-Stammordner für den Benutzer abc nicht beschreibbar ist.
Sonarr konnte den eingebundenen Pfad /tv auflösen, lehnte ihn jedoch ab, weil sein Containerbenutzer dort keine Schreibrechte hatte.

Radarr zeigte das entsprechende Problem für den Filmpfad:

Berechtigungsfehler im Radarr-Stammordner für ein zugeordnetes Filmverzeichnis in ZimaOS
Bei Radarr bestand dasselbe Problem mit nicht übereinstimmenden Host-Berechtigungen für die zugeordnete Filmbibliothek.

Die Lösung der Community: PUID=0 und PGID=0

Ein Mitglied des IceWhale-Teams antwortete:

PUID=0
PGID=0

Der ursprüngliche Verfasser änderte beide Werte auf null und berichtete, dass das Problem dadurch offenbar behoben wurde. Dies ist daher die bestätigte Lösung für diese spezielle ZimaOS-App-Store-Konfiguration vom Juli 2025.

UID 0 und GID 0 sind unter Linux jedoch Identitäten auf Root-Ebene. Wenn Sie Sonarr oder Radarr mit diesen IDs ausführen, kann die Anwendung möglicherweise auf Orte weit über die vorgesehene Medienbibliothek hinaus schreiben, sofern diese Pfade in den Container eingebunden sind. Verwenden Sie dies nur als Diagnose- oder Kompatibilitätslösung, wenn Sie die damit gewährten Zugriffsrechte verstehen.

Bevorzugte Lösung: PUID und PGID an den Eigentümer des Host-Speichers anpassen

Die aktuelle Dokumentation von LinuxServer.io zu Sonarr und Radarr erläutert das vorgesehene Konzept: PUID und PGID an den Eigentümer des Host-Speichers anpassen PUID und PGID zu einem Host-Benutzer bzw. einer Host-Gruppe, der bzw. die bereits Eigentümer des zugeordneten Volumes ist oder Schreibzugriff darauf hat.

Laut den Richtlinien von LinuxServer entstehen Berechtigungsprobleme, wenn ein Host-Volume IDs gehört, die nicht mit den an den Container übergebenen IDs übereinstimmen. Das empfohlene Muster lautet:

PUID=1000
PGID=1000

nur wenn UID 1000 und GID 1000 für die Medienpfade tatsächlich geeignet sind. Die Zahl 1000 ist nicht grundsätzlich korrekt, sondern lediglich eine häufig verwendete erste Benutzer-ID eines Nicht-Root-Linux-Benutzers.

Lesen Sie die aktuelle LinuxServer-Sonarr-Dokumentation und die LinuxServer-Radarr-Dokumentation.

So überprüfen Sie den Eigentümer und die Berechtigungen des Speichers

Wenn die ZimaOS-Dateiverwaltung die benötigten numerischen Linux-Eigentümer- und Gruppenwerte nicht anzeigt, prüfen Sie den tatsächlichen Host-Pfad über ein autorisiertes Terminal.

Ermitteln Sie zunächst das tatsächliche Host-Verzeichnis, das zugeordnet ist zu /tv oder /moviesUntersuchen Sie es anschließend:

ls -ldn /REAL/HOST/PATH
stat /REAL/HOST/PATH

Die numerische Ausgabe hilft Ihnen festzustellen, welcher UID und GID das Verzeichnis derzeit gehören. Führen Sie diese Befehle nicht für den ausschließlich im Container vorhandenen Pfad aus. /tv vom Host, es sei denn, es handelt sich tatsächlich um den Host-Pfad.

Wenn das gewünschte Konto für die Medienverwaltung auf dem Host verfügbar ist, können Sie seine IDs mit folgendem Befehl prüfen:

id USERNAME

Dann setzen Sie die Sonarr-/Radarr- PUID und PGID auf die IDs setzen, die dem von Ihnen bewusst gewählten Zugriffsmodell entsprechen.

Nicht blind „chown /tv“ innerhalb des Containers ausführen

Eine weitere Antwort aus der Community schlug Folgendes vor:

sudo chown abc:abc /tv/

Dieser Hinweis ist riskant, wenn er ohne Kontext übernommen wird. Der Eigentümer eines per Bind-Mount eingebundenen Verzeichnisses wird auf dem Host letztlich durch numerische IDs dargestellt. Der Name abc existiert innerhalb von LinuxServer-Containern und ist möglicherweise kein sinnvoller Host-Benutzer. Eine rekursive Änderung des Eigentümers kann außerdem unerwartet eine gesamte Mediathek betreffen.

Bevor Sie chown, bestätigen Sie:

  • den genauen Host-Pfad, der geändert wird;
  • die gewünschte Host-UID und GID;
  • ob andere Dienste wie qBittorrent, SABnzbd, Jellyfin oder SMB-Benutzer Zugriff auf dieselben Dateien benötigen;
  • ob eine gemeinsame Gruppe besser geeignet ist als eine Änderung des Eigentümers.

Sichern Sie wichtige Konfigurationen und vermeiden Sie rekursive Berechtigungsänderungen, bis Sie deren Auswirkungen verstanden haben.

Gemeinsame Medienberechtigungen für den gesamten ARR-Stack planen

Sonarr und Radarr arbeiten nur selten allein. Ein Download-Client erstellt zunächst Dateien, anschließend importieren Sonarr oder Radarr diese, und Jellyfin kann das Ergebnis lesen. Wenn jeder Container voneinander unabhängige IDs und Mounts verwendet, kann eine Anwendung Dateien erstellen, die eine andere Anwendung nicht ändern kann.

Eine sauberere Lösung besteht darin, den Anwendungen eine gemeinsame Gruppe oder eine kompatible PUID/PGID-Zuordnung für den gemeinsamen Datensatz zu geben. LinuxServer empfiehlt außerdem gut geplante Volume-Pfade, damit Download-Clients und ARR-Anwendungen gegebenenfalls Hardlinks oder atomare Verschiebungen verwenden können.

Anstatt Downloads und Medien beispielsweise als voneinander unabhängige, isolierte Mounts zu behandeln, kann ein einziger gemeinsamer Datenbaum auf dem Host die Einschätzung der Berechtigungen und die Konsistenz der Pfade erleichtern:

/data
├── Downloads
├── Medien
│   ├── Filme
│   └── Serien

Der genaue ZimaOS-Pfad hängt von Ihrem Speicherpool ab und sollte nicht blind kopiert werden.

Wann ist die Root-ID-Umgehung sinnvoll?

PUID/PGID setzen auf 0 kann als kurze Diagnose nützlich sein:

  • Wenn der Fehler sofort verschwindet, ist der Container-Mount selbst wahrscheinlich korrekt.
  • Das verbleibende Problem liegt dann wahrscheinlich beim Eigentümer oder bei der Rechtezuordnung auf dem Host.

Nach der Bestätigung besteht das sicherere langfristige Ziel darin, dem Container nur die für seine Medien- und Downloadpfade erforderlichen Berechtigungen zu erteilen. Falls Ihr konkretes ZimaOS-Speichermodell eine Zuordnung ohne Root-Rechte unpraktikabel macht, dokumentieren Sie, warum Root-IDs erforderlich sind, und beschränken Sie die eingebundenen Verzeichnisse sorgfältig.

Apps nach dem Ändern von PUID oder PGID neu starten

PUID und PGID werden beim Start des Containers angewendet. Nachdem Sie sie in ZimaOS geändert haben:

  1. Speichern Sie die App-Konfiguration.
  2. Starten Sie den Sonarr-/Radarr-Container über ZimaOS neu oder erstellen Sie ihn neu.
  3. Öffnen Sie die Einstellungen für den Stammordner erneut.
  4. Testen Sie, ob Sie den eingebundenen Ordner erstellen oder auswählen können.

Wenn der Ordner weiterhin nicht beschreibbar ist, vergleichen Sie den numerischen Besitz und die Berechtigungen des Host-Verzeichnisses mit den IDs, die der Container jetzt verwendet.

Checkliste für Sonarr-/Radarr-Berechtigungen in ZimaOS

  1. Bestätigen Sie, dass der Medienpfad des Hosts in Sonarr oder Radarr eingebunden ist.
  2. Bestätigen Sie, dass im App-Inneren der ausgewählte Pfad der Containerpfad ist.
  3. Überprüfen Sie die UID, GID und Berechtigungsbits des Host-Pfads.
  4. Überprüfen Sie die aktuellen PUID und PGID in den ZimaOS-App-Einstellungen.
  5. Bevorzugen Sie IDs, die dem vorgesehenen Besitzer bzw. der vorgesehenen Gruppe auf dem Host entsprechen.
  6. Starten Sie den Container neu, nachdem Sie die IDs geändert haben.
  7. Verwenden Sie PUID/PGID 0 nur, wenn Sie die dadurch gewährten Zugriffsrechte auf Root-Ebene verstehen.
  8. Vermeiden Sie weitreichende rekursive chmod 777 oder blind chown behebt.
  9. Stellen Sie sicher, dass Download-Clients und Medienserver ein kompatibles Modell für gemeinsame Berechtigungen verwenden.

FAQ zu Berechtigungen für Sonarr und Radarr

Wer ist der Benutzer abc?

abc ist der interne Dienstbenutzername, der von LinuxServer.io-Containern häufig verwendet wird. PUID und PGID bestimmen, welche numerische Host-Identität der Prozess für den Zugriff auf eingebundene Volumes verwendet.

Warum schlagen PUID=1000 und PGID=1000 fehl?

Diese Werte funktionieren nur, wenn UID/GID 1000 den erforderlichen Zugriff auf das Medienverzeichnis des Hosts hat. Wenn Ihr ZimaOS-RAID-Verzeichnis einem anderen Benutzer oder einer anderen Gruppe gehört, kann der Container es möglicherweise sehen, aber nicht beschreiben.

Beheben PUID=0 und PGID=0 das Problem?

Das hat den ursprünglichen Community-Fall behoben, wie der Autor bestätigt hat. Es gewährt jedoch auch Zugriff auf Root-Ebene innerhalb des eingebundenen Dateisystems und sollte daher nicht automatisch als bevorzugte dauerhafte Konfiguration verwendet werden.

Soll ich den Medienordner mit chmod 777 versehen?

Nein, nicht als Standardlösung. Weltweit beschreibbare Berechtigungen sind unnötig weitreichend und können die eigentliche Abweichung beim Besitz verschleiern. Stimmen Sie stattdessen die Container-Identität und die Berechtigungen der gemeinsamen Gruppe gezielt aufeinander ab.

Sollten Sonarr, Radarr und der Download-Client dieselbe PUID/PGID verwenden?

Sie benötigen nicht immer identische Benutzer-IDs, aber für alle gemeinsam genutzten Dateien und Ordner ein kompatibles Besitz-/Gruppenmodell. Eine einheitliche gemeinsame Gruppe ist eine gängige Möglichkeit, Fehler beim Importieren und Umbenennen zu vermeiden.