Jellyfin-Berechtigungen nach dem Verschieben seines Datenverzeichnisses wiederherstellen
Nach dem Verschieben des Jellyfin-Datenverzeichnisses stellen Sie die Berechtigungen wieder her, indem Sie die verschobenen Dateien der Identität zuordnen, unter der Jellyfin tatsächlich läuft, und bestätigen, dass der Container oder Dienst auf den vorgesehenen Pfad verweist. Beginnen Sie nicht mit chmod -R 777.
Ein Verschieben kann numerische Besitzverhältnisse, geerbte ACLs, Mount-Optionen, SELinux-Labels oder die von einem neu erstellten Container verwendete UID/GID ändern. Diagnostizieren Sie diese Ebenen in dieser Reihenfolge, korrigieren Sie nur Daten im Besitz von Jellyfin und starten Sie anschließend den Server. Überprüfen Sie Schreibvorgänge für Datenbank, Metadaten, Backups und geplante Aufgaben, bevor Sie die Berechtigungen der Medienbibliothek ändern.
Neuen Pfad und Jellyfin-Laufzeitidentität bestätigen
Stoppen Sie Jellyfin, bevor Sie die verschobenen Anwendungsdaten reparieren, damit Hintergrundschreibvorgänge Ihre Prüfung nicht beeinflussen. Bestätigen Sie den neuen Hostpfad, den Pfad, den Jellyfin innerhalb des Containers oder Dienstes sieht, sowie die UID/GID der laufenden Jellyfin-Identität.
Die Jellyfin-Migrationsanleitung empfiehlt ausdrücklich, die uid und gid des Jellyfin-Benutzers zu ermitteln und die erwarteten Pfade während der Migration beizubehalten. Jellyfin-Anleitung zu UID/GID bei Migrationen
Wenn der Container auf das falsche Hostverzeichnis verweist, korrigieren Sie zuerst den Mount. Berechtigungen können keine falsche Pfadzuordnung beheben, durch die Jellyfin in einen leeren Ordner geleitet wird. Ein Start mit diesem leeren Pfad kann außerdem einen zweiten, neuen Datenbaum erzeugen.
Besitzverhältnisse, Modus-Bits und ACLs vor Änderungen prüfen
Listen Sie den numerischen Besitzer und die Gruppe des verschobenen Verzeichnisses sowie einer Auswahl seiner Datenbank-, Konfigurations-, Metadaten- und Protokollunterverzeichnisse auf. Prüfen Sie die Ausführungsberechtigungen der übergeordneten Verzeichnisse und alle ACL-Einträge, die vom ZielfDateisystem übernommen worden sein könnten.
Ein NAS-Verschieben kann ein anderes Identitäts- und Berechtigungsmodell einführen, insbesondere bei SMB, NFS oder Containern. Der Beitrag zur Berechtigungsdiagnose nach dem Verschieben von ZimaSpace erklärt, warum ein sichtbarer Mount die UID/GID-Autorisierung des Containerprozesses nicht umgeht.
Ändern Sie nichts, bevor Sie die Abweichung genau benennen können: falscher Besitzer, fehlender Gruppenzugriff, blockierter Zugriff auf übergeordnete Verzeichnisse, unerwartete ACL oder schreibgeschützter Mount. Diese Feststellung bestimmt die kleinste sichere Reparatur.
Besitzverhältnisse nur für Jellyfin-eigene Anwendungsdaten wiederherstellen
Wenn das verschobene Jellyfin-Datenverzeichnis dem Jellyfin-Dienstkonto gehören soll, stellen Sie den vorgesehenen Besitzer und die vorgesehene Gruppe für diesen Anwendungsdatenbaum wieder her. Behalten Sie den Besitz gemeinsam genutzter Mediendateien unverändert bei, sofern Jellyfin diese Dateien nicht tatsächlich verwalten muss.
Die Jellyfin-Migrationsdokumentation beschreibt auch die Korrektur der Besitzverhältnisse im Jellyfin-Datenverzeichnis nach einem Verschieben. Korrektur der Besitzverhältnisse nach der Migration Betrachten Sie dies als gezielten Vorgang für Anwendungsdaten, nicht als Anlass, rekursiv den Besitz einer gesamten NAS-Freigabe zu übernehmen.
Prüfen Sie nach der Korrektur der Besitzverhältnisse erneut eine Auswahl von Dateien und führen Sie als Jellyfin-Identität einen nicht destruktiven Schreibbarkeitstest in einem eigens dafür vorgesehenen Testunterverzeichnis durch. Wenn der Schreibzugriff weiterhin verweigert wird, fügen Sie nicht weitere chmod-Änderungen hinzu, sondern prüfen Sie als Nächstes ACLs, den Mount-Modus oder die Sicherheitskennzeichnung.
Mount-Modus des Containers und Sicherheitskennzeichnung prüfen
Ein korrekter Besitzer auf dem Host kann innerhalb eines Containers trotzdem zu Fehlern führen, wenn der Bind-Mount schreibgeschützt ist, sich der Laufzeitbenutzer geändert hat oder das Host-Sicherheitssystem den Zugriff auf den Pfad blockiert. Vergleichen Sie die aktuelle Containerdefinition mit der zuletzt funktionierenden.
Die Container-Anleitung von Jellyfin zeigt die explizite Ausführung mit UID/GID, schreibgeschützte Medien-Mounts und Podman-Optionen zur Neukennzeichnung in SELinux-Umgebungen. Containerberechtigungen und Neukennzeichnung Diese Einstellungen können außer Kraft setzen, was gewöhnliche Unix-Modus-Bits scheinbar erlauben.
Ändern Sie nur die bestätigte Ebene. Machen Sie den Mount der Anwendungsdaten schreibbar, wenn Jellyfin dort schreiben muss, stellen Sie die korrekte Laufzeit-UID/GID wieder her oder wenden Sie die für die Plattform geeignete Kennzeichnung auf diesen Mount an. Erstellen Sie den Container anschließend einmal neu und prüfen Sie denselben Pfad erneut von innerhalb des Containers.
Jellyfin starten und Schreibvorgänge in Datenbank und Datenverzeichnis prüfen
Starten Sie Jellyfin und verfolgen Sie das Startprotokoll. Vergewissern Sie sich, dass der vorhandene Serverzustand und nicht ein Einrichtungsassistent oder eine leere Bibliothek geöffnet wird, und achten Sie auf Berechtigungsfehler bei Datenbank, Konfiguration, Metadaten oder Protokollen.
Wenn der Start das normale Dashboard erreicht, lösen Sie einen risikoarmen Vorgang aus, der in den Jellyfin-eigenen Zustand schreibt, beispielsweise eine geplante Aufgabe oder eine Metadatenaktion in einem Testkontext. Bestätigen Sie anschließend, dass sich die erwartete Datei oder der erwartete Datenbankzustand ohne Berechtigungsfehler ändert.
Starten Sie Jellyfin noch einmal neu. Die Reparatur ist erst abgeschlossen, wenn dasselbe Datenverzeichnis nach einem frischen Start problemlos geöffnet wird; ein Erfolg in nur einer Sitzung kann ein Mount- oder Initialisierungsproblem verbergen, das beim erneuten Erstellen wieder auftritt.
Umfassende Änderungen zurücknehmen und mit genauen Belegen eskalieren
Wenn Sie bereits umfassende rekursive Berechtigungen angewendet haben und der Server weiterhin nicht funktioniert, erweitern Sie den Zugriff nicht weiter. Stellen Sie nach Möglichkeit die aufgezeichneten Besitzverhältnisse oder ein Backup wieder her und kehren Sie anschließend zur konkreten Abweichung bei Laufzeitidentität und Pfad zurück.
Vergleichen Sie bei containerisierten Servern die aktuelle Mount-Quelle, das Ziel, UID/GID, Gruppen und den Sicherheitskontext mit der gespeicherten funktionierenden Definition. Vergleichen Sie bei nativen Installationen die Dienstidentität sowie das Mount- und ACL-Verhalten des ZielfDateisystems. Ziel ist ein einziges nachvollziehbares Berechtigungsmodell.
Beenden Sie die Fehlerbehebung, wenn Jellyfin die ursprüngliche Datenbank öffnet, in seine eigenen Datenverzeichnisse schreibt, den ausgewählten Hintergrundvorgang abschließt und einen Neustart übersteht. Eskalieren Sie mit numerischen Besitzverhältnissen, ACL-Ausgabe, Mount-Optionen, Laufzeit-UID/GID und dem ersten berechtigungsbezogenen Protokollfehler, falls eine dieser Prüfungen weiterhin fehlschlägt.
Empfohlene Produkte
Support & Tipps
Mehr zum Lesen
Sollte Jellyfin ein gemeinsames Konto oder separate Haushaltskonten verwenden?
Wählen Sie Jellyfin-Haushaltskonten nach den benötigten Grenzen für Identität, Zugriff, Jugendschutz und Wiederherstellung aus.
Warum bleibt der Speicherverbrauch von Jellyfin nach Abschluss der Arbeit hoch?
Unterscheiden Sie das Wachstum des Jellyfin-Prozesses vom Linux-Cache und untersuchen Sie es nur, wenn der Speicherverbrauch weiter ansteigt oder tatsächlich Druck auf den Arbeitsspeicher...
Anzeichen dafür, dass ein Jellyfin-Speicherlayout zum Wiederherstellungsrisiko wird
Prüfen Sie die Speicherrollen von Jellyfin, trennen Sie den laufenden Zustand von Backups und wiederherstellbaren Daten und belegen Sie das Layout durch eine Wiederherstellung.
