So setzt du eine Jellyfin-Installation nach dem Wechsel in ein neues Netzwerk neu auf

Eva Wong

IceWhale author

Eva Wong ist die Technische Redakteurin und und leidenschaftliche Tüftlerin bei ZimaSpace. Eine lebenslange Geek mit einer Leidenschaft für Homelabs und Open-Source-Software, sie spezialisiert sich darauf, komplexe technische Konzepte in zugängliche, praktische Anleitungenzu übersetzen. Eva ist der Meinung, dass Self-Hosting Spaß machen und nicht einschüchternd sein sollte. Durch ihre Tutorials befähigt sie die Community, Hardware-Setups zu entmystifizieren, vom Bau ihres ersten NAS bis hin zur Beherrschung von Docker-Containern.

How to Rebuild a Jellyfin Setup After Moving to a New Network - Zima Store Online

Jellyfin nach einem Netzwerkwechsel neu aufbauen: Stellen Sie zuerst den lokalen Dienstpfad wieder her und prüfen Sie anschließend Speicher-Mounts, Identität, DNS und Fernzugriff als separate Prüfschritte.

Ein neuer Router, ein neues Subnetz, VLAN oder eine neue DNS-Domain kann eine intakte Jellyfin-Datenbank beschädigt erscheinen lassen, weil Clients, Mounts und Reverse-Proxys nicht mehr denselben Pfad verwenden. Bewahren Sie die alten Netzwerknotizen und eine Kopie der Anwendungsdaten auf. Ziel ist ein nachvollziehbarer Pfad vom Client über den Dienst bis zu den Medien – mit einer klaren Abbruchgrenze, sobald nicht Jellyfin, sondern das Netzwerk selbst die fehlerhafte Ebene ist.

Den alten Pfad vor jeder Änderung dokumentieren

Notieren Sie Serveradresse, Hostnamen, Subnetz, Gateway, DNS-Namen, eingebundene Medienpfade, Ziel des Reverse-Proxys, Zertifikatsnamen sowie Firewall- und Portweiterleitungsregeln. Trennen Sie lokales Streaming vom Streaming aus der Ferne. Falls der alte Host noch verfügbar ist, exportieren Sie die Jellyfin-Konfiguration und listen Sie Benutzer und Bibliotheken auf, bevor Sie neue Adressen vergeben.

Damit schaffen Sie die Ausgangsbasis für den Neuaufbau: Ein Benutzer erreicht den Dienst, der Dienst erreicht Datenbank und Medien, und Backups erreichen ihr Ziel. Beginnen Sie nicht mit einem öffentlichen Port oder einer neuen Proxy-Regel.

Den lokalen Dienst unter einer stabilen Adresse wiederherstellen

Richten Sie eine DHCP-Reservierung oder eine statische Adresse für den Server ein und bestätigen Sie anschließend, dass sich die Jellyfin-Weboberfläche aus demselben LAN öffnen lässt. Prüfen Sie die Bind-Adresse des Dienstes und die Host-Firewall und testen Sie einen lokalen Client, bevor Sie DNS ändern. Wenn die App startet, aber die Bibliotheken leer sind, halten Sie an und prüfen Sie den Speicherpfad, statt die Datenbank neu aufzubauen.

Jellyfins Migrationsanleitung betont, dass interne Daten pfadabhängig sind und dass Containerpfade mit den dokumentierten Medienspeicherorten übereinstimmen müssen (Anleitung zur pfadabhängigen Migration). Behandeln Sie eine Pfadabweichung als Topologiefehler, nicht als Metadatenfehler.

Mounts und Berechtigungen vor DNS wiederherstellen

Binden Sie Medien- und Backup-Volumes unter stabilen Pfaden ein und testen Sie anschließend den Lesezugriff mit dem Dienstkonto von Jellyfin. Überprüfen Sie je Bibliothek eine Datei und einen Schreibvorgang im Verzeichnis mit den Anwendungsdaten. Bewahren Sie Cache und heruntergeladene Grafiken auf wiederherstellbarem Speicher auf, während Benutzermedien, Datenbank und Backups auf geschützten Speicherbereichen verbleiben.

Der Prüfschritt ist BESTANDEN, wenn ein Neustart die Mounts vor dem Start von Jellyfin wiederherstellt und ein Bibliotheksscan keine Warnungen zu fehlenden Dateien erzeugt. Wenn der Mount von einer interaktiven Anmeldung abhängt, korrigieren Sie die Startreihenfolge, bevor Sie fortfahren.

-15% OFF

ZimaBoard 2 – Mini-Heimserver für Ihre große Idee

Single board computer zimaboard2

Identität, DNS und Fernzugriff in dieser Reihenfolge neu aufbauen

Nachdem die lokale Wiedergabe funktioniert, stellen Sie Hostnamen und internen DNS-Eintrag wieder her. Testen Sie einen Client mit dem Namen statt mit der IP-Adresse und prüfen Sie anschließend Reverse-Proxy oder VPN von außerhalb des Heimnetzwerks. Halten Sie Authentifizierung und Autorisierung getrennt vom Routing: Ein fehlgeschlagener Login ist kein Beleg dafür, dass die neue Portweiterleitung falsch ist.

Führen Sie einen Direct-Play- und einen Transcoding-Test mit dem tatsächlichen Client-Mix durch. Notieren Sie den beobachteten Endpunkt, den Wiedergabemodus und den Fehlerpunkt. Ein Migrationsfall aus der Community eignet sich zum Vergleich von Pfad- und Netzwerkannahmen, aber verallgemeinern Sie weder dessen Hardware noch dessen Routereinstellungen (Fallstudie zur Migration).

Rollback und Erweiterungen eindeutig planen

Bewahren Sie den alten DNS-Eintrag, das Konfigurationsbackup und die bisherigen Netzwerknotizen auf, bis lokale Wiedergabe, Benutzerzugriff, Routing aus der Ferne und Wiederherstellung erfolgreich geprüft wurden. Erweitern Sie erst dann, indem Sie einen dedizierten Pfad hinzufügen – etwa ein separates VLAN für die Verwaltung oder eine zweite Netzwerkschnittstelle –, wenn der gemeinsame Pfad instabil wird. Brechen Sie den Neuaufbau ab, wenn der Server keine stabile Adresse, keine dauerhaften Mounts oder keinen getesteten Wiederherstellungspfad erhält; keine noch so umfangreiche Neukonfiguration der Clients behebt diese fehlenden Grundlagen.