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 Jellyfin, rétablissez les autorisations en faisant correspondre 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 toucher aux 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 d’application déplacées afin d’éviter que les écritures en arrière-plan ne perturbent votre inspection. Confirmez le nouveau chemin hôte, le chemin visible par Jellyfin dans le conteneur ou le service, ainsi que l’UID/GID de l’identité utilisée par Jellyfin en cours d’exécution.
Les recommandations de migration de Jellyfin conseillent explicitement de déterminer l’uid et le gid de l’utilisateur Jellyfin et de préserver les chemins attendus pendant la migration. Recommandations de Jellyfin sur l’UID/GID pour la migration
Si le conteneur pointe vers le mauvais répertoire hôte, corrigez d’abord le montage. Les autorisations ne peuvent pas réparer un mappage de chemin qui dirige Jellyfin vers un dossier vide, et son démarrage sur ce chemin vide peut créer une nouvelle arborescence de données.
Inspecter le propriétaire, les bits de mode et les ACL avant toute modification
Relevez le propriétaire et le groupe numériques du répertoire déplacé, ainsi que ceux d’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 toute entrée ACL éventuellement héritée du système de fichiers de destination.
Un déplacement vers un NAS peut introduire un modèle d’identités et d’autorisations différent, surtout avec SMB, NFS ou des conteneurs. Le diagnostic des autorisations après déplacement de ZimaSpace explique pourquoi un montage visible ne contourne pas les autorisations UID/GID du processus du conteneur.
Ne changez rien avant de pouvoir décrire précisément le problème : propriétaire incorrect, accès au groupe manquant, traversée du répertoire parent bloquée, ACL inattendue ou montage en lecture seule. Cette description détermine la réparation la plus limitée et la plus sûre.
Rétablir la propriété uniquement sur les données d’application appartenant à Jellyfin
Si le répertoire de données Jellyfin déplacé est censé appartenir au compte de service Jellyfin, rétablissez le propriétaire et le groupe prévus sur cette arborescence de données d’application. Préservez la propriété des fichiers multimédias partagés sans rapport, sauf si Jellyfin doit réellement les gérer.
La documentation de migration de Jellyfin indique qu’il faut corriger le propriétaire du répertoire de données Jellyfin après un déplacement. Correction du propriétaire après migration Considérez cela comme une opération ciblée sur les données de l’application, et non comme une raison de vous attribuer récursivement la propriété de tout un partage NAS.
Après avoir corrigé le propriétaire, examinez à nouveau un échantillon et effectuez un test d’écriture non destructif, en tant qu’utilisateur Jellyfin, dans un sous-répertoire de test dédié. Si l’accès en écriture est toujours refusé, cessez de modifier les permissions avec chmod et examinez ensuite les ACL, le mode de montage ou les étiquettes de sécurité.
Vérifiez le mode de montage du conteneur et les étiquettes de sécurité
Même avec un propriétaire correct sur l’hôte, l’accès peut é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 à la dernière configuration fonctionnelle.
Le guide de Jellyfin pour les conteneurs montre comment exécuter le service avec des UID/GID explicites, monter les médias en lecture seule et utiliser les options de relabellisation de Podman dans les environnements SELinux. permissions des conteneurs et relabellisation Ces paramètres peuvent avoir priorité sur les permissions que semblent autoriser les bits de mode Unix ordinaires.
Ne modifiez que la couche dont le problème est confirmé. Rendez le montage des données de l’application accessible en écriture si Jellyfin doit y écrire, rétablissez l’UID/GID d’exécution approprié ou appliquez à ce montage l’étiquette adaptée à la plateforme. Recréez ensuite le conteneur une seule fois et vérifiez à nouveau le même chemin depuis l’intérieur.
Démarrez Jellyfin et vérifiez 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. Confirmez qu’il ouvre l’état du serveur existant plutôt qu’un assistant de configuration ou une bibliothèque vide, et surveillez les erreurs de permission concernant la base de données, la configuration, les métadonnées ou les journaux.
Si le démarrage mène au tableau de bord habituel, déclenchez une opération à faible risque qui écrit dans les données gérées par Jellyfin, comme une tâche planifiée ou une action sur les métadonnées dans un environnement de test, puis confirmez que le fichier ou l’état de la base de données attendu a changé sans erreur de permission.
Redémarrez Jellyfin une nouvelle fois. La réparation n’est terminée que si le même répertoire de données s’ouvre correctement après un démarrage à froid ; 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.
Annulez les modifications étendues et transmettez des éléments précis
Si vous avez déjà appliqué des permissions récursives étendues et que le serveur ne fonctionne toujours pas, ne continuez pas à élargir les accès. Restaurez si possible les propriétaires consignés ou une sauvegarde, puis revenez à l’incompatibilité précise entre l’identité d’exécution et le chemin d’accès.
Pour les serveurs conteneurisés, comparez la source et la cible du montage actuels, les UID/GID, les groupes et le contexte de sécurité avec la configuration 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 de permissions cohérent et explicable.
Arrêtez 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 redémarre sans problème. Si l’une de ces vérifications échoue encore, transmettez les identifiants numériques du propriétaire, la sortie des ACL, les options de montage, les UID/GID d’exécution et la première erreur de journal liée aux permissions, le cas échéant.
Produits recommandés
Assistance et conseils
À lire aussi
Ce qu’il faut vérifier avant de charger un modèle communautaire dans Transformers
Utilisez la mise à jour du bac à sable Jinja de Transformers pour examiner la provenance des modèles, les modèles de conversation, le code...
Exécutez Mirage localement : OCR et détection d’objets à partir d’une seule image
Essayez le petit modèle de vision local de Cactus Compute, testez la reconnaissance optique de caractères et l’extraction d’objets à partir de données réelles,...
Comment planifier un agent de programmation dans Open WebUI sur un serveur domestique
Configurez une automatisation d’agent de codage en mode rapport uniquement dans Open WebUI, sélectionnez son terminal et son espace de travail, puis vérifiez les...
