Comment restaurer les autorisations de Jellyfin après avoir déplacé son répertoire de données
Après avoir déplacé le répertoire de données de Jellyfin, rétablissez les autorisations en associant les fichiers déplacés à l’identité qui exécute réellement Jellyfin et en vérifiant que le conteneur ou le service pointe vers le chemin prévu. Ne commencez pas par chmod -R 777.
Un déplacement peut modifier la propriété numérique, les ACL héritées, les options de montage, les étiquettes SELinux ou l’UID/GID utilisé par un conteneur recréé. Diagnostiquez ces couches dans cet ordre, ne corrigez que les données appartenant à Jellyfin, puis démarrez le serveur et vérifiez les écritures dans la base de données, les métadonnées, les sauvegardes et les tâches planifiées avant de modifier les autorisations de la médiathèque.
Confirmer le nouveau chemin et l’identité d’exécution de Jellyfin
Arrêtez Jellyfin avant de réparer les données applicatives déplacées afin d’éviter que des écritures en arrière-plan ne perturbent votre inspection. Confirmez le nouveau chemin sur l’hôte, le chemin que Jellyfin voit à l’intérieur du conteneur ou du service, ainsi que l’UID/GID de l’identité Jellyfin en cours d’exécution.
La documentation de migration de Jellyfin recommande de déterminer l’uid et le gid de l’utilisateur Jellyfin et de conserver les chemins attendus pendant la migration. Conseils de Jellyfin sur l’UID/GID lors d’une migration
Si le conteneur pointe vers le mauvais répertoire de l’hôte, corrigez d’abord le montage. Les autorisations ne peuvent pas réparer une correspondance de chemins qui dirige Jellyfin vers un dossier vide, et un démarrage avec ce chemin vide peut créer une seconde arborescence de données vierge.
Inspecter la propriété, les bits de mode et les ACL avant de les modifier
Affichez le propriétaire et le groupe numériques du répertoire déplacé, ainsi qu’un échantillon de ses sous-répertoires de base de données, de configuration, de métadonnées et de journaux. Vérifiez les autorisations d’exécution des répertoires parents et les éventuelles entrées ACL qui ont pu être héritées du système de fichiers de destination.
Un déplacement vers un NAS peut introduire un modèle différent d’identités et d’autorisations, notamment avec SMB, NFS ou les conteneurs. L’diagnostic des autorisations après déplacement de ZimaSpace explique pourquoi un montage visible ne contourne pas l’autorisation UID/GID du processus du conteneur.
Ne modifiez rien avant de pouvoir formuler précisément le problème : propriétaire incorrect, accès du groupe manquant, traversée d’un répertoire parent bloquée, ACL inattendue ou montage en lecture seule. Cette constatation détermine la réparation minimale et sûre.
Rétablir la propriété uniquement sur les données applicatives appartenant à Jellyfin
Si le répertoire de données déplacé de Jellyfin est censé appartenir au compte de service Jellyfin, rétablissez ce propriétaire et ce groupe prévus sur cette arborescence de données applicatives. Conservez la propriété des fichiers multimédias partagés qui ne sont pas concernés, sauf si Jellyfin doit réellement les gérer.
La documentation de migration de Jellyfin indique notamment comment corriger la propriété du répertoire de données Jellyfin après un déplacement. Correction de la propriété après la migration Considérez cette opération comme une intervention ciblée sur les données applicatives, et non comme une raison de vous attribuer récursivement la propriété de tout un partage NAS.
Après avoir corrigé la propriété, inspectez de nouveau un échantillon et effectuez un test d’écriture non destructif, en tant qu’identité Jellyfin, dans un sous-répertoire de test dédié. Si l’écriture reste refusée, cessez d’ajouter des modifications de type chmod et examinez ensuite les ACL, le mode de montage ou l’étiquetage de sécurité.
Vérifier le mode de montage du conteneur et l’étiquetage de sécurité
Un propriétaire correct sur l’hôte peut tout de même échouer dans un conteneur si le montage lié est en lecture seule, si l’utilisateur d’exécution a changé ou si le système de sécurité de l’hôte bloque le chemin. Comparez la définition actuelle du conteneur avec la dernière définition fonctionnelle.
Le guide des conteneurs Jellyfin présente l’exécution avec un UID/GID explicite, les montages des médias en lecture seule et les options de réétiquetage de Podman dans les environnements SELinux. Autorisations et réétiquetage des conteneurs Ces contrôles peuvent outrepasser ce que les bits de mode Unix ordinaires semblent autoriser.
Ne modifiez que la couche confirmée. Rendez le montage des données applicatives accessible en écriture si Jellyfin doit y écrire, rétablissez l’UID/GID d’exécution correct ou appliquez à ce montage l’étiquette adaptée à la plateforme. Recréez ensuite le conteneur une seule fois et vérifiez de nouveau le même chemin depuis l’intérieur de celui-ci.
Démarrer Jellyfin et vérifier les écritures dans la base de données et le répertoire de données
Démarrez Jellyfin et suivez le journal de démarrage. Vérifiez qu’il ouvre l’état existant du serveur plutôt qu’un assistant de configuration ou une médiathèque vide, et surveillez les erreurs d’autorisation liées à la base de données, à la configuration, aux métadonnées ou aux journaux.
Si le démarrage atteint le tableau de bord normal, déclenchez une opération à faible risque qui écrit dans l’état géré par Jellyfin, par exemple une tâche planifiée ou une action sur les métadonnées dans un contexte de test, et vérifiez que le fichier ou l’état de la base de données attendu est modifié sans erreur d’autorisation.
Redémarrez encore une fois Jellyfin. La réparation n’est terminée que si le même répertoire de données s’ouvre correctement après un nouveau démarrage ; une réussite lors d’une seule session peut masquer un problème de montage ou d’initialisation qui réapparaîtra lors de la recréation.
Annuler les modifications générales et transmettre des éléments précis
Si vous avez déjà appliqué des autorisations récursives générales et que le serveur est toujours défaillant, ne continuez pas à élargir les accès. Restaurez si possible la propriété enregistrée ou une sauvegarde, puis revenez à l’écart précis entre l’identité d’exécution et le chemin.
Pour les serveurs conteneurisés, comparez la source du montage actuel, sa cible, l’UID/GID, les groupes et le contexte de sécurité avec la définition fonctionnelle enregistrée. Pour les installations natives, comparez l’identité du service ainsi que le comportement du montage et des ACL du système de fichiers de destination. L’objectif est d’obtenir un modèle d’autorisations cohérent et explicable.
Arrêtez-vous lorsque Jellyfin ouvre la base de données d’origine, écrit dans ses propres répertoires de données, termine l’opération en arrière-plan choisie et résiste à un redémarrage. Si l’un de ces contrôles échoue encore, transmettez la propriété numérique, la sortie des ACL, les options de montage, l’UID/GID d’exécution et la première erreur d’autorisation du journal, le cas échéant.
Produits recommandés
Assistance et conseils
Plus à lire
Jellyfin doit-il utiliser un compte partagé unique ou des comptes distincts pour chaque membre du foyer ?
Choisissez les comptes familiaux Jellyfin selon les limites d’identité, d’accès, de contrôle parental et de récupération dont vous avez besoin.
Pourquoi l’utilisation de la mémoire de Jellyfin reste-t-elle élevée une fois la tâche terminée ?
Distinguez la croissance du processus Jellyfin du cache Linux, et n’intervenez que lorsque la mémoire continue d’augmenter ou crée une réelle pression.
Signes indiquant qu’une configuration de stockage Jellyfin devient un risque pour la récupération des données
Auditez les rôles de stockage de Jellyfin, séparez l’état actif des sauvegardes et des données reconstructibles, puis validez la disposition par une restauration.
