So stellst du Jellyfin-Berechtigungen wieder her, nachdem du das Datenverzeichnis verschoben hast

Stelle nach dem Verschieben des Jellyfin-Datenverzeichnisses die Berechtigungen wieder her, indem du die verschobenen Dateien der Identität zuordnest, unter der Jellyfin tatsächlich läuft, und bestätigst, dass der Container oder Dienst auf den vorgesehenen Pfad verweist. Beginne nicht mit chmod -R 777.

Bei einem Umzug können sich der numerische Besitzer, übernommene ACLs, Mount-Optionen, SELinux-Labels oder die von einem neu erstellten Container verwendete UID/GID ändern. Prüfe diese Ebenen in dieser Reihenfolge, korrigiere nur Jellyfin-eigene Daten, starte dann den Server und überprüfe Schreibvorgänge für Datenbank, Metadaten, Sicherung und geplante Aufgaben, bevor du Berechtigungen der Medienbibliothek änderst.

Neuen Pfad und Jellyfin-Laufzeitidentität bestätigen

Stoppe Jellyfin, bevor du die verschobenen Anwendungsdaten reparierst, damit Hintergrund-Schreibvorgänge deine Prüfung nicht beeinträchtigen. Bestätige den neuen Hostpfad, den Pfad, den Jellyfin innerhalb des Containers oder Dienstes sieht, und die UID/GID der laufenden Jellyfin-Identität.

Die Migrationsanleitung von Jellyfin empfiehlt ausdrücklich, die uid und gid des Jellyfin-Benutzers zu ermitteln und bei der Migration die erwarteten Pfade beizubehalten. Jellyfins Hinweise zu UID/GID bei der Migration

Wenn der Container auf das falsche Hostverzeichnis verweist, korrigiere zuerst den Mount. Berechtigungen können keine Pfadzuordnung reparieren, durch die Jellyfin in einem leeren Ordner landet. Wird Jellyfin mit diesem leeren Pfad gestartet, kann ein zweiter, neuer Datenbaum entstehen.

Besitzrechte, Modusbits und ACLs vor dem Ändern prüfen

Ermittle den numerischen Besitzer und die Gruppe des verschobenen Verzeichnisses sowie einiger seiner Datenbank-, Konfigurations-, Metadaten- und Protokoll-Unterverzeichnisse. Prüfe die Ausführungsberechtigungen der übergeordneten Verzeichnisse und alle ACL-Einträge, die möglicherweise vom Zieldateisystem übernommen wurden.

Bei einem Umzug auf ein NAS kann sich das Identitäts- und Berechtigungsmodell ändern, insbesondere bei SMB, NFS oder Containern. Die Diagnose von Berechtigungsproblemen nach dem Umzug von ZimaSpace erklärt, warum ein sichtbarer Mount die Autorisierung anhand der UID/GID des Containerprozesses nicht umgeht.

Ändere nichts, bevor du die Abweichung genau benennen kannst: falscher Besitzer, fehlender Gruppenzugriff, blockierter Zugriff auf ein übergeordnetes Verzeichnis, unerwartete ACL oder schreibgeschützter Mount. Diese Feststellung bestimmt die kleinstmögliche sichere Korrektur.

Besitzrechte nur für Jellyfin-eigene Anwendungsdaten wiederherstellen

Wenn das verschobene Jellyfin-Datenverzeichnis dem Jellyfin-Dienstkonto gehören soll, stelle den vorgesehenen Besitzer und die vorgesehene Gruppe für diesen Anwendungsdatenbaum wieder her. Behalte die Besitzrechte anderer freigegebener Mediendateien bei, sofern Jellyfin diese Dateien nicht tatsächlich verwalten muss.

Die Migrationsdokumentation von Jellyfin empfiehlt, nach einem Umzug die Besitzrechte des Jellyfin-Datenverzeichnisses zu korrigieren. Besitzrechte nach der Migration korrigieren Betrachte das als gezielten Eingriff in die Anwendungsdaten und nicht als Anlass, den Besitz eines gesamten NAS-Shares rekursiv zu ändern.

Prüfen Sie nach der Korrektur der Besitzangaben erneut ein Beispiel und führen Sie als Jellyfin-Identität in einem eigens dafür vorgesehenen Testunterverzeichnis eine nicht destruktive Schreibbarkeitsprüfung durch. Wird der Schreibzugriff weiterhin verweigert, nehmen Sie keine weiteren chmod-Änderungen vor, sondern prüfen Sie als Nächstes ACLs, Einhängemodus oder Sicherheitskennzeichnung.

Featured

ZimaCube 2 persönliche Cloud-NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Einbindungsmodus und Sicherheitskennzeichnung des Containers überprüfen

Auch mit korrektem Eigentümer auf dem Host kann es in einem Container scheitern, wenn die Bind-Einbindung schreibgeschützt ist, der Laufzeitbenutzer geändert wurde oder das Host-Sicherheitssystem den Pfad blockiert. Vergleichen Sie die aktuelle Containerdefinition mit der zuletzt funktionierenden.

Die Container-Anleitung von Jellyfin zeigt die Ausführung mit expliziter UID/GID, schreibgeschützte Medieneinbindungen und Podman-Optionen zum Neulabeln in SELinux-Umgebungen. Container-Berechtigungen und Neulabeln Diese Einstellungen können außer Kraft setzen, was die gewöhnlichen Unix-Modusbits scheinbar erlauben.

Ändern Sie nur die bestätigte Ebene. Gewähren Sie der Anwendungseinbindung Schreibzugriff, wenn Jellyfin dort schreiben muss, stellen Sie die korrekte Laufzeit-UID/GID wieder her oder wenden Sie das für die Plattform geeignete Label auf diese Einbindung an. Erstellen Sie den Container anschließend einmal neu und prüfen Sie denselben Pfad erneut von innen.

Jellyfin starten und Schreibvorgänge in Datenbank und Datenverzeichnis überprüfen

Starten Sie Jellyfin und verfolgen Sie das Startprotokoll. Vergewissern Sie sich, dass der vorhandene Serverstatus statt eines Einrichtungsassistenten oder einer leeren Bibliothek geöffnet wird, und achten Sie auf Berechtigungsfehler bei Datenbank, Konfiguration, Metadaten oder Protokollen.

Wenn der Start bis zum normalen Dashboard gelangt, lösen Sie in einem Testkontext einen risikoarmen Vorgang aus, der in den von Jellyfin verwalteten Status schreibt, etwa eine geplante Aufgabe oder eine Metadatenaktion, und bestätigen Sie, dass sich die erwartete Datei oder der Datenbankstatus ohne Berechtigungsfehler ändert.

Starten Sie Jellyfin noch einmal neu. Die Reparatur ist erst abgeschlossen, wenn dasselbe Datenverzeichnis nach einem vollständigen Neustart problemlos geöffnet wird. Ein Erfolg in einer einzelnen Sitzung kann ein Einhänge- oder Initialisierungsproblem verdecken, das beim Neuerstellen wieder auftritt.

Weitreichende Änderungen rückgängig machen und mit genauen Nachweisen eskalieren

Wenn Sie bereits weitreichende rekursive Berechtigungen angewendet haben und der Server weiterhin nicht funktioniert, weiten Sie den Zugriff nicht weiter aus. Stellen Sie nach Möglichkeit die dokumentierten Besitzangaben oder eine Sicherung wieder her und wenden Sie sich dann wieder der konkreten Abweichung zwischen Laufzeitidentität und Pfad zu.

Vergleichen Sie bei containerisierten Servern die aktuelle Quelle und das Ziel der Einbindung, UID/GID, Gruppen und den Sicherheitskontext mit der gespeicherten funktionierenden Konfiguration. Vergleichen Sie bei nativen Installationen die Dienstidentität sowie das Einhänge- und ACL-Verhalten des Zieldateisystems. Ziel ist ein nachvollziehbares Berechtigungsmodell.

Hören Sie auf, wenn Jellyfin die ursprüngliche Datenbank öffnet, in die eigenen Datenverzeichnisse schreibt, den ausgewählten Hintergrundvorgang abschließt und einen Neustart übersteht. Eskalieren Sie mit numerischen Besitzangaben, ACL-Ausgabe, Einhängeoptionen, Laufzeit-UID/GID und dem ersten protokollierten Berechtigungsfehler, falls eine dieser Prüfungen weiterhin fehlschlägt.