Stoppen Sie den fehlgeschlagenen Plex-Container und seinen automatischen Updater, bevor Sie ein weiteres Image abrufen. Sichern Sie zuerst die aktuellen Logs und den tatsächlichen Plex-Konfigurationspfad. Die Wiederherstellung ist deutlich sicherer, wenn der fehlerhafte Container sich nicht weiter selbst ersetzen oder in den Anwendungszustand schreiben kann.
Auf einem Heim-NAS kann ein Container-Update auf mehreren Ebenen fehlschlagen: Das neue Image startet möglicherweise nicht, der neu erstellte Dienst kann ein Volume oder eine Netzwerkeinstellung verlieren, oder der neue Plex-Build kann vorhandene Anwendungsdaten anders öffnen. Die entscheidende Grenze bildet die persistente Plex-Konfiguration, insbesondere die Datenbank und die Metadaten unter `/config`. Dieser Ablauf trennt Image, Containerdefinition, Mounts und Datenbank, bevor Änderungen vorgenommen werden, stellt anschließend die kleinste fehlgeschlagene Ebene wieder her und überprüft die ursprüngliche Serveridentität, die Bibliothek und die Wiedergabe. Wenn die Logs auf eine beschädigte Datenbank oder eine nicht rückgängig zu machende Migration hinweisen, halten Sie an, bevor Sie ein älteres Image über die einzige Kopie dieses Zustands legen.
Update-Schleife stoppen und fehlgeschlagenen Zustand erfassen
Deaktivieren Sie den automatischen Updater für Plex und stoppen Sie jede schnelle Neustartschleife. Lassen Sie andere funktionierende Dienste weiterlaufen, sofern Plex keine Datenbank verwendet, die einen koordinierten Stopp erfordert. Ziel ist es, den Fehler lange genug unverändert zu halten, um ihn zu untersuchen – nicht den gesamten App-Stack neu zu starten und dadurch den zeitlichen Ablauf zu verwischen.
Notieren Sie das exakte Image-Tag, die Image-ID und den Digest des fehlgeschlagenen Containers, sofern verfügbar. Sichern Sie die tatsächlich verwendeten Mounts, Umgebungsvariablen, veröffentlichten Ports, den Netzwerkmodus, Netzwerk-Aliase, Gerätezuordnungen, zusätzlichen Gruppen, die Neustart-Richtlinie und den Health-Status. Ein Tag wie `latest` ist allein kein zuverlässiger Rollback-Nachweis, da es im Laufe der Zeit auf unterschiedliche Image-Inhalte verweisen kann.
Exportieren Sie die aktuellen Logs, bevor Sie einen weiteren Startversuch unternehmen, und notieren Sie die erste schwerwiegende Meldung – nicht nur den abschließenden Exit-Code. Eine fehlende Datei, eine verweigerte Berechtigung, ein Datenbankfehler, eine nicht unterstützte Anweisung oder ein Adresskonflikt führt jeweils zu einem anderen Wiederherstellungsweg. Notieren Sie außerdem, wann das Update ausgeführt wurde und ob der Container neu erstellt wurde, da ein Pull allein einen bestehenden Container nicht ändert, während eine Neuerstellung seine effektive Definition verändern kann.
Sie können fortfahren, sobald sich der Fehler reproduzieren lässt und Sie vier Fragen beantworten können: Welches Image wurde ausgeführt, welche persistenten Pfade wurden verwendet, welche Laufzeiteinstellungen wurden übernommen und welcher Fehler trat zuerst auf? Wenn diese Fakten noch unbekannt sind, sorgt ein weiterer Pull- oder Neustartversuch nur für zusätzliche Unklarheit, ohne die Wiederherstellung sicherer zu machen.
Plex-Konfiguration vor der Neuerstellung des Containers schützen
Behandeln Sie den Container als austauschbar und die Plex-Konfiguration als persistent. Der kritische Zustand liegt normalerweise am Hostpfad oder im benannten Volume, das auf `/config` gemountet ist; Medienbibliotheken sollten separate Mounts bleiben. Das Neuerstellen des Dienstes ist nur dann risikoarm, wenn es erneut mit demselben persistenten Zustand verbunden wird und nicht mit einem leeren Verzeichnis.
Überprüfen Sie den Mount vom Host aus und, sofern Ihre Plattform dies unterstützt, aus einem temporären schreibgeschützten Kontext. Bestätigen Sie, dass die erwartete Datenbank, Einstellungen, Metadaten, Plug-in-Daten und Protokolle vorhanden sind. Notieren Sie Mount-Quelle, Dateisystem, Eigentümer, Berechtigungen, verfügbaren Speicherplatz und ob das Dateisystem schreibgeschützt geworden ist. Ein leeres Verzeichnis am erwarteten Pfad ist ein Warnsignal zum Anhalten, keine Erlaubnis für Plex, dort einen neuen Server zu erstellen.
Erstellen Sie vor dem Testen eines Rollbacks eine Sicherung des gesamten vorgesehenen Konfigurationspfads und überprüfen Sie anschließend, ob die Sicherung aufgelistet oder an einem isolierten Ort wiederhergestellt werden kann. Wenn das Dateisystem Snapshots unterstützt, kann ein Snapshot die Wiederherstellung beschleunigen. Er sollte jedoch nicht die einzige Kopie sein, wenn möglicherweise dasselbe Speichergerät ausfällt. Bewahren Sie sowohl den fehlerhaften Zustand als auch die letzte als funktionierend bekannte Sicherung auf, bis der Server verifiziert wurde.
Löschen Sie keine Einstellungs-, Datenbank- oder Metadatendateien, damit das ältere Image startet. Wenn die Konfiguration nicht konsistent gelesen werden kann, ihr Besitz unklar ist oder eine Kopie nicht verifiziert werden kann, gehen Sie direkt zur Speicher- oder Datenbankwiederherstellung über. Eine Neuerstellung des Containers kann eine nicht vertrauenswürdige Zustandsquelle nicht reparieren.
Feststellen, ob Image, Definition, Mount oder Datenbank fehlerhaft sind
Vergleichen Sie den erfassten Container mit der letzten funktionierenden Bereitstellung, bevor Sie eine Reparatur auswählen. Beginnen Sie mit der ersten schwerwiegenden Logzeile und der tatsächlich verwendeten Definition. Ordnen Sie den Fehler dann einem von vier Zweigen zu: Das neue Image kann nicht ausgeführt werden, die Containerdefinition wurde geändert, ein persistenter Pfad ist nicht verfügbar oder Plex kann seinen vorhandenen Anwendungsstatus nicht verwenden.
Ein Bild- oder Laufzeitfehler tritt normalerweise auf, bevor Plex `/config` öffnen kann: Architekturfehler, nicht unterstützte CPU-Anweisungen, fehlende Laufzeitbibliotheken oder ein sofortiger Prozessabbruch bei unveränderter Containerdefinition. Ein versionsspezifischer Wiedergabefehler verschwand, nachdem der Server zu einem früheren Plex-Image zurückkehrte. Das macht ein Rollback zu einem nützlichen Unterscheidungsmerkmal, wenn dieselbe Definition zuvor funktionierte und kein Mount- oder Berechtigungsänderung vorgenommen wurde.
Ein Definitions- oder Mount-Fehler tritt nach der Neuerstellung auf, wenn Plex mit fehlenden Medien, einem leeren Server, verweigertem Dateizugriff, keinem Web-Endpunkt oder verlorenem Hardwarezugriff startet. Vergleichen Sie die gespeicherten und tatsächlich verwendeten Volume-Quellen, UID/GID, Gruppen, Ports, den Netzwerkmodus, Geräte und die Umgebung. Beheben Sie die erste nachgewiesene Abweichung, anstatt alle Felder gleichzeitig zu ändern.
Datenbank- und Migrationsmeldungen erfordern eine separate Abgrenzung. Wenn der neue Build eine Schemaänderung begonnen hat, kann ein älteres Image den daraus entstandenen Status möglicherweise nicht lesen. Sichern Sie die aktuelle Konfiguration erneut, bewahren Sie die Protokolle auf und erzwingen Sie keine wiederholten Starts über mehrere Versionen hinweg. Dieser Zweig erfordert ein kompatibles Image, ein verifiziertes Backup vor dem Update oder eine datenbankgerechte Reparatur.
| Beobachtetes Ergebnis | Führender Zweig | Erste Reparatur |
|---|---|---|
| Der Prozess wird beendet, bevor `/config` gelesen wird | Image oder Laufzeitumgebung | Starten Sie das beibehaltene, als funktionierend bekannte Image mit der unveränderten Definition |
| Plex startet als neuer oder leerer Server | Falsche `/config`-Zuordnung | Stoppen Sie den Dienst und stellen Sie die ursprüngliche Mount-Quelle wieder her |
| Die Konfiguration oder die Medien zeigen Berechtigungsfehler | Eigentümer des Mounts oder schreibgeschützter Status | Die bewährte UID/GID, Gruppen oder den Speicherzugriff wiederherstellen |
| Die Protokolle zeigen eine Migration oder einen Datenbankfehler | Anwendungsstatus | Status beibehalten und ein kompatibles Image oder ein verifiziertes Backup verwenden |
Auf das zuletzt als funktionierend bekannte Plex-Image zurücksetzen
Wählen Sie das genaue Image, das zuletzt erfolgreich ausgeführt wurde. Bevorzugen Sie einen beibehaltenen Image-Digest, eine unveränderliche Versionsreferenz oder eine lokale Image-ID gegenüber einem sich ändernden Tag. Lassen Sie automatische Updates deaktiviert, damit der Updater das Zurücksetzen nicht sofort nach dem Start ersetzt.
Erstellen Sie nur den Plex-Dienst aus der gespeicherten Definition neu. Behalten Sie dieselbe Projekt- oder Containeridentität bei, sofern sie sich auf Netzwerke auswirkt, ebenso dieselben Quellen für `/config` und Medien, dieselben Ports, denselben Netzwerkmodus, dieselbe Umgebung, UID/GID, Gruppen und Geräte. Entfernen Sie keine Volumes und führen Sie keine systemweite Bereinigung durch, bevor das alte Image getestet wurde.
Verfolgen Sie den ersten Start in Echtzeit. Bei einem erfolgreichen Zurücksetzen des Images sollte die ursprüngliche Konfiguration geöffnet, dieselbe Serveridentität beibehalten, auf die vorhandenen Bibliotheken zugegriffen und der vorherige schwerwiegende Fehler behoben werden. Lassen Sie die optionale Hardware-Transkodierung und Hintergrundscans zunächst außen vor, bis die grundlegende Anmeldung und der Medienzugriff funktionieren.
Halten Sie an, wenn das alte Image meldet, dass die Datenbank neuer, inkompatibel oder gerade migriert wird. Ein wiederholtes Wechseln zwischen Versionen kann den Wiederherstellungspunkt schwerer nachvollziehbar machen. Stellen Sie eine verifizierte Konfigurationskopie vor dem Update in einem isolierten Pfad wieder her oder wechseln Sie stattdessen zu einem kompatiblen Plex-Image, anstatt ein unsicheres Downgrade zu erzwingen.
Die ursprüngliche Containerdefinition wiederherstellen, wenn ein Rollback nicht ausreicht
Wenn das als funktionsfähig bekannte Image weiterhin fehlschlägt, kehren Sie zum Definitionsvergleich zurück. Stellen Sie jeweils nur eine fehlende Einstellung wieder her und starten Sie nach jeder Änderung ausschließlich Plex neu. So bleiben die Belege nachvollziehbar: Wenn der Server zurückkehrt, wissen Sie, welche Laufzeitabhängigkeit dafür verantwortlich war.
Beginnen Sie mit den Einbindungen von `/config` und den Medien. Vergewissern Sie sich, dass der Container die vorgesehenen Pfade erkennt und als der konfigurierte Benutzer darauf zugreifen kann. Wenn das Update Plex unter einer anderen UID oder GID, einer zusätzlichen Gruppe oder einem anderen Sicherheitskontext neu erstellt hat, stellen Sie die zuletzt funktionierende Identität wieder her oder korrigieren Sie den Besitz des Speichers gezielt. Machen Sie nicht als Abkürzung den gesamten Appdata-Baum für alle Benutzer beschreibbar.
Prüfen Sie anschließend den Webpfad und optionale Geräte. Stellen Sie das vorherige Hostnetzwerk bzw. den veröffentlichten Port, Netzwerkaliasse und die Zugehörigkeit zum Reverse-Proxy wieder her, bevor Sie Firewallregeln ändern. Bestätigen Sie die Weboberfläche zunächst über den direkten Serverpfad. Fügen Sie das GPU-Gerät und den Zugriff auf die Rendergruppe erst hinzu, wenn Plex starten, seine Bibliothek laden und einen grundlegenden, softwarekompatiblen Stream bereitstellen kann.
Eine erfolgreiche Reparatur der Definition hat einen eindeutigen Zustand: Der Container erkennt die vorgesehene Konfiguration und die Medien, der Plex-Endpunkt ist erreichbar und in den Protokollen wird der ausgewählte Abhängigkeitsfehler nicht mehr angezeigt. Wenn derselbe Datenbankfehler nach diesen Prüfungen weiterhin besteht, hören Sie auf, den Container neu zu erstellen, und kehren Sie zum geschützten Zweig des Anwendungszustands zurück.
Plex-Datenbank, Bibliothek und Wiedergabe vor der erneuten Aktivierung von Updates überprüfen
Ein laufender Prozess ist nur die erste Wiederherstellungsprüfung. Melden Sie sich über den direkten Plex-Endpunkt an und bestätigen Sie, dass es sich um den ursprünglich beanspruchten Server handelt – nicht um einen neuen Server, der mit einem leeren Konfigurationsverzeichnis erstellt wurde. Prüfen Sie die Startprotokolle auf Datenbankbeschädigungen, wiederholte Migrationsversuche und unerwartete Bibliotheksinitialisierungen.
Öffnen Sie mehrere vorhandene Bibliothekselemente und bestätigen Sie, dass Poster, Metadaten, Wiedergabestatus und Dateipfade vorhanden sind. Testen Sie den Zugriff auf eine kleine, bekanntermaßen funktionierende Mediendatei vom selben Speicher, der vor dem Update verwendet wurde. Wenn Metadaten vorhanden, die Medien jedoch nicht verfügbar sind, kann die Datenbank fehlerfrei sein, während eine Medien-Einhängung oder eine Berechtigung noch repariert werden muss.
Spielen Sie die bekannte Datei zunächst auf einem lokalen Client und anschließend, falls zutreffend, auf dem Client ab, der den Fehler ausgelöst hat. Notieren Sie den Wiedergabemodus und bestätigen Sie, dass das Vorspulen und Zurückspulen funktioniert. Behandeln Sie fehlende GPU-Beschleunigung, Fernzugriff oder Untertitelverhalten als separate Folgeprüfungen, wenn die grundlegende Wiedergabe erfolgreich ist; sie sollten die Sicherung eines wiederhergestellten Servers nicht blockieren.
Führen Sie abschließend einen kontrollierten Neustart des Plex-Dienstes durch, während der Updater weiterhin deaktiviert ist. Die Wiederherstellung ist nur erfolgreich, wenn dieselbe Serveridentität, Datenbank, Bibliotheken, Metadaten, der Medienzugriff und die grundlegende Wiedergabe nach diesem Neustart wieder verfügbar sind. Bewahren Sie die erfassten Fehlerprotokolle und das Backup auf, bis dieses vollständige Ergebnis wiederholbar ist.
Erkennen, wann Sie aufhören und das nächste Plex-Update wiederherstellbar machen sollten
Beenden Sie die lokale Container-Reparatur, wenn die Protokolle wiederholt eine Beschädigung der Datenbank melden, das Konfigurationsdateisystem E/A-Fehler zurückgibt, die einzige Zustandskopie teilweise migriert wurde oder kein kompatibles Image sie öffnen kann. Bewahren Sie die Image-Kennungen, die effektive Definition, die Protokolle und das Konfigurations-Backup auf. Eine datenbankbewusste Wiederherstellung oder eine Reparatur des Speichers ist zu diesem Zeitpunkt sicherer als weitere Containeränderungen.
Sobald Plex stabil läuft, dokumentieren Sie den wiederhergestellten Image-Digest, die Containerdefinition, persistente Pfade, die Laufzeitidentität, den Netzwerkmodus, die Geräte und die Verifizierungsergebnisse. Der umfassendere Wiederherstellungsprozess für einen einzelnen Dienst ist hilfreich, wenn Plex auch von gemeinsam genutzten Datenbanken, Proxy-Netzwerken oder anderen Stack-Diensten abhängt. Diese funktionierenden Abhängigkeiten sollten jedoch nicht allein deshalb wiederhergestellt werden, weil Plex ausgefallen ist.
Erstellen und überprüfen Sie für das nächste Update zunächst ein frisches `/config`-Backup, behalten Sie das aktuelle Image bei, deaktivieren Sie das automatische Bereinigen, aktualisieren Sie Plex manuell und wiederholen Sie die Prüfungen von Identität, Bibliothek, Wiedergabe und Neustart, bevor Sie die Automatisierung wieder aktivieren. Ein Update ist erst abgeschlossen, wenn es sowohl ein getestetes Rollback-Ziel als auch eine funktionierende neue Version bewahrt.
Support & Tipps
Mehr zum Lesen

Kann Plex eine GPU mit einem anderen Docker-Container gemeinsam nutzen?
Plex und ein weiterer Container können häufig auf dieselbe GPU zugreifen, aber du musst die Treiberunterstützung, die Gerätezuordnung, die Auslastung der Video-Engine, den Speicher...

So erkennst du, ob ein Plex-Fehler vom Client oder vom Server verursacht wird
Reproduziere dasselbe Element auf einem anderen Client, vergleiche den Sitzungspfad und sammle Serverbelege erst, nachdem der Geltungsbereich dir gezeigt hat, wo der Fehler tatsächlich...

So konfigurierst du den Plex-Cache und den temporären Transcodierungs-Speicher
Schütze den persistenten Plex-Zustand, indem du temporäre Transcodierungsdateien auf geeignetem lokalem Speicher ablegst, und überprüfe anschließend die Bereinigung, den freien Speicherplatz und das Verhalten...

