Comment reconstruire une configuration Jellyfin après le passage à un nouveau réseau

Reconstruisez Jellyfin après un changement de réseau en rétablissant d’abord le chemin du service local, puis en validant séparément les montages de stockage, l’identité, le DNS et l’accès à distance.

Un nouveau routeur, sous-réseau, VLAN ou domaine DNS peut donner l’impression qu’une base de données Jellyfin saine est défaillante, car les clients, les montages et les reverse proxies ne partagent plus le même chemin. Conservez les anciennes notes réseau ainsi qu’une copie des données de l’application. L’objectif est d’obtenir un chemin connu du client au service, puis du service aux médias, avec une limite d’arrêt claire lorsque c’est le réseau lui-même — et non Jellyfin — qui constitue la couche défaillante.

Consignez l’ancien chemin avant toute modification

Notez l’adresse du serveur, le nom d’hôte, le sous-réseau, la passerelle, le nom DNS, les chemins des médias montés, la destination du reverse proxy, le nom du certificat ainsi que toute règle de pare-feu ou de redirection de port. Séparez le streaming local du streaming à distance. Si l’ancien hôte est toujours disponible, exportez la configuration de Jellyfin et répertoriez les utilisateurs et les bibliothèques avant d’attribuer de nouvelles adresses.

Vous établissez ainsi la référence pour la reconstruction : un utilisateur atteint le service, le service atteint sa base de données et ses médias, et les sauvegardes atteignent leur destination. Ne commencez pas par ouvrir un port public ou créer une nouvelle règle de proxy.

Rétablissez le service local sur une adresse stable

Attribuez au serveur une réservation DHCP ou une adresse statique, puis vérifiez que l’interface web de Jellyfin s’ouvre depuis le même réseau local. Vérifiez l’adresse d’écoute du service et le pare-feu de l’hôte, puis testez un client local avant de modifier le DNS. Si l’application démarre mais que les bibliothèques sont vides, arrêtez-vous et inspectez le chemin de stockage au lieu de reconstruire la base de données.

Les recommandations de migration de Jellyfin soulignent que les données internes dépendent des chemins et que les chemins des conteneurs doivent correspondre aux emplacements de médias consignés (recommandations de migration sensibles aux chemins). Considérez une incohérence de chemin comme une défaillance de topologie, et non comme une défaillance des métadonnées.

Reconnectez les montages et les autorisations avant le DNS

Montez les volumes de médias et de sauvegarde sur des chemins stables, puis testez l’accès en lecture avec le compte de service Jellyfin. Vérifiez un fichier par bibliothèque ainsi qu’une écriture dans le répertoire des données de l’application. Conservez le cache et les illustrations téléchargées sur un stockage reconstructible, tandis que les médias utilisateur, la base de données et les sauvegardes restent sur des supports protégés.

La condition de sortie est PASS lorsqu’un redémarrage recrée les montages avant le démarrage de Jellyfin et qu’une analyse de bibliothèque ne génère aucun avertissement concernant des fichiers manquants. Si le montage dépend d’une connexion interactive, corrigez l’ordre de démarrage avant de continuer.

-15% OFF

ZimaBoard 2 - Mini serveur domestique pour votre grande idée

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Reconstruisez l’identité, le DNS et l’accès à distance dans cet ordre

Une fois la lecture locale opérationnelle, rétablissez le nom d’hôte et l’enregistrement DNS interne. Testez un client avec le nom, et non avec l’adresse IP, puis validez le reverse proxy ou le VPN depuis l’extérieur du domicile. Séparez l’authentification et l’autorisation du routage : un échec de connexion ne prouve pas que la nouvelle redirection de port est incorrecte.

Lancez une lecture directe et une transcodification avec les appareils réellement utilisés par les clients. Notez le point de terminaison observé, le mode de lecture et le point d’échec. Un cas de migration communautaire peut servir à comparer les hypothèses liées aux chemins et au réseau, mais ne généralisez pas ses composants matériels ni ses paramètres de routeur (étude de cas de migration).

Définissez explicitement le retour arrière et l’extension

Conservez l’ancien enregistrement DNS, la sauvegarde de configuration et les anciennes notes réseau jusqu’à ce que la lecture locale, l’accès des utilisateurs, le routage distant et la restauration aient tous été validés. N’étendez le réseau qu’en ajoutant un chemin dédié — par exemple un VLAN séparé pour la gestion ou une seconde interface réseau — lorsque le chemin partagé se dégrade. Arrêtez la reconstruction si le serveur ne peut pas obtenir une adresse stable, des montages persistants ou une voie de récupération testée ; aucune reconfiguration des clients ne peut corriger l’absence de ces fondations.