Considérez une instance Plex vierge après la recréation d’une pile comme un problème de montage ou d’autorisations, jusqu’à preuve que les anciennes données persistantes ont réellement disparu.
Recréer une pile Docker ou Compose remplace les conteneurs et peut également modifier le chemin hôte, le volume nommé, l’identité utilisateur ou le pool de stockage qui fournit `/config`. Plex s’ouvre alors sur un répertoire vide ou illisible et semble nouvellement installé, même si l’ancienne base de données existe toujours. Arrêtez la nouvelle instance, recherchez les anciennes données d’application, comparez les montages effectifs et les propriétaires numériques, et ne restaurez une sauvegarde que si ces données sont réellement absentes.
Arrêtez-vous lorsque Plex ressemble à un serveur vierge
Un assistant de configuration vierge après la recréation d’une pile est un avertissement de persistance, pas une invitation à reconstruire la bibliothèque. Arrêtez le conteneur et inspectez le mappage des données avant que Plex n’écrive davantage d’état. Le problème le plus courant est que le nouveau conteneur lit un chemin hôte vide au lieu de l’ancien répertoire de données d’application.
Un conteneur recréé peut afficher une configuration vierge lorsque le mappage de configuration persistante attendu ne pointe plus vers les anciennes données d’application. Le premier élément à vérifier est de déterminer si l’ancien état existe toujours sur l’hôte.
Localisez l’ancien répertoire de données Plex et vérifiez ses dates de modification, ses fichiers de base de données et ses dossiers de métadonnées. S’ils sont présents, ne les supprimez pas et n’initialisez pas un nouveau serveur. Votre objectif de récupération est le chemin de montage et les autorisations, pas la bibliothèque multimédia.
Comparez exactement les mappages /config anciens et nouveaux
La recréation d’une pile peut modifier un montage bind relatif, un volume nommé, une substitution d’environnement, un pool de stockage ou le répertoire de travail Compose sans changer le chemin visible dans le conteneur. Plex peut toujours voir `/config`, mais ce chemin peut désormais pointer vers un autre emplacement hôte.
Une configuration de conteneur Plex est plus sûre lorsque la configuration se trouve à l’extérieur du conteneur. Comparez les montages effectifs de l’ancien déploiement ou de la sauvegarde avec ceux de la pile recréée, plutôt que de vous fier à un fichier Compose visuellement similaire.
Montez les anciennes données d’application connues en lecture seule dans un conteneur de diagnostic temporaire, ou inspectez-les directement sur l’hôte. Si la base de données et les préférences attendues s’y trouvent, corrigez le mappage de production et redémarrez Plex une seule fois. Si le répertoire est réellement absent, passez à la récupération depuis une sauvegarde.
Vérifiez le propriétaire avant d’accuser la base de données
Un chemin hôte correct peut rester inutilisable si le conteneur recréé s’exécute avec un UID, un GID, un espace de noms utilisateur ou un contexte de sécurité différent. Plex semble alors incapable d’enregistrer les préférences, d’ouvrir les fichiers de base de données ou de créer des répertoires, même si les données sont montées au bon endroit.
Lorsque Plex ne peut pas créer ou mettre à jour les données d’application, vérifiez numériquement les autorisations du répertoire de configuration au lieu de les « corriger » avec un `777` récursif appliqué à l’aveugle.
Effectuez une vérification de l’identité à l’intérieur du conteneur et comparez-la avec le propriétaire numérique et le mode définis sur l’hôte. Appliquez la correction minimale du propriétaire ou de l’ACL qui accorde l’accès au compte de service prévu. Démarrez ensuite Plex et confirmez qu’il ouvre le serveur existant plutôt qu’une nouvelle configuration.
Si le propriétaire numérique correspond, mais que l’accès échoue toujours, examinez les ACL, les étiquettes de sécurité du conteneur et le fonctionnement de l’espace de noms utilisateur avant de modifier la base de données. Un UID/GID correct ne remplace pas une autre couche de contrôle d’accès.
Vérifiez les montages multimédias seulement après le retour de l’état de l’application
Une fois l’identité de l’ancien serveur et les bibliothèques réapparues, certaines bibliothèques peuvent encore sembler indisponibles parce que les montages multimédias ont changé indépendamment de `/config`. Il s’agit d’un rôle de persistance distinct. Corrigez le chemin multimédia sans recréer la bibliothèque ni copier les fichiers multimédias dans le répertoire de données d’application.
Conservez séparément l’état de l’application et les montages multimédias, comme deux rôles de persistance distincts. Cette séparation vous permet de restaurer d’abord l’identité Plex, puis de résoudre les problèmes de chemins multimédias manquants uniquement après la réapparition des bibliothèques d’origine.
Ouvrez plusieurs chemins multimédias connus depuis l’intérieur du conteneur Plex. Si l’ancienne base de données pointe vers `/media/movies`, mais que la pile recréée expose `/movies`, restaurez le chemin interne attendu ou prévoyez une migration contrôlée du chemin de bibliothèque. Ne relancez pas l’analyse avant que le montage soit stable.
Restaurez depuis une sauvegarde uniquement lorsque l’état d’origine a réellement disparu
Si l’ancien répertoire hôte est vide, supprimé ou irrémédiablement corrompu, restaurez la dernière sauvegarde connue comme fiable des données d’application Plex dans un chemin propre et correctement mappé. Conservez séparément l’état défaillant afin de pouvoir encore examiner ce qui s’est passé, plutôt que d’écraser le seul élément de preuve.
Un processus fiable de récupération d’un conteneur protège `/config` persistant, ne remplace que la couche applicative jetable et vérifie les montages avant d’autoriser Plex à écrire à nouveau.
Après la restauration, confirmez l’identité du serveur, le nombre de bibliothèques, l’état de lecture, une lecture locale, un transcodage si vous l’utilisez et un redémarrage. Capturez ensuite la configuration effective de la pile et l’emplacement de la sauvegarde. L’incident n’est clos qu’une fois qu’une autre recréation pointe vers les mêmes données persistantes sans tâtonnement manuel.
Assistance et conseils
Plus à lire

Plex peut-il partager un GPU avec un autre conteneur Docker ?
Plex et un autre conteneur peuvent souvent accéder au même GPU, mais vous devez tester la prise en charge des pilotes, le mappage des...

Comment déterminer si une erreur Plex vient du client ou du serveur
Reproduisez le même élément sur un autre client, comparez le chemin de session, puis recueillez les preuves côté serveur uniquement après que la portée...

Comment configurer le cache de Plex et le stockage temporaire du transcodage
Protégez l’état persistant de Plex en plaçant les fichiers temporaires de transcodage sur un stockage local adapté, puis vérifiez le nettoyage, l’espace libre et...

