Pourquoi Jellyfin recrée-t-il les fichiers manquants avec le mauvais propriétaire ?

Eva Wong est la rédactrice technique et bricoleuse résidente chez ZimaSpace. Geek depuis toujours, passionnée par les homelabs et les logiciels open source, elle se spécialise dans la traduction de concepts techniques complexes en guides accessibles et pratiques. Eva croit que l’auto-hébergement doit être amusant, pas intimidant. À travers ses tutoriels, elle donne à la communauté les moyens de démystifier les configurations matérielles, depuis la construction de leur premier NAS jusqu’à la maîtrise des conteneurs Docker.

Jellyfin recrée généralement les fichiers avec un propriétaire incorrect lorsque l’identité du service actif diffère de celle du propriétaire du répertoire ou qu’un second chemin d’importation utilise un autre UID/GID.

Le problème concerne-t-il uniquement les illustrations nouvellement téléchargées ou tous les fichiers écrits par Jellyfin ? Comparez un fichier fonctionnel, un fichier nouvellement créé, l’identité du conteneur actif et la destination montée par liaison avant d’exécuter une commande récursive de gestion des permissions. L’objectif est de corriger l’héritage, et non de réparer sans cesse les symptômes.

Déterminez quelle identité et quel chemin ont effectué l’écriture

Inspectez l’utilisateur et les groupes du conteneur en cours d’exécution, puis inspectez le point de montage par liaison actif au lieu de vous fier au fichier Compose présent sur le disque. Vérifiez que les chemins de configuration et de cache de Jellyfin sont accessibles en écriture, tandis que les médias restent en lecture seule lorsque l’accès en écriture n’est pas nécessaire. Une vérification des permissions par couches permet de distinguer la visibilité depuis l’hôte, le mappage du conteneur et l’identité du service.

Si l’hôte voit le fichier mais que le conteneur ne le peut pas, corrigez le montage. Si le conteneur peut écrire mais que le propriétaire est incorrect, poursuivez avec le test de l’identité et de l’héritage.

Si seuls les fichiers importés ont un propriétaire incorrect, comparez l’UID/GID et l’umask de l’importateur avec ceux de Jellyfin. Si chaque nouveau fichier est incorrect, inspectez l’ACL par défaut du répertoire parent et le comportement setgid.

Vérifiez l’umask, les groupes, les ACL et le processus d’importation

Comparez l’UID/GID et le mode du répertoire parent avec ceux du processus qui crée le fichier. Un téléchargeur, une tâche planifiée ou un conteneur auxiliaire peut écrire via un autre conteneur, même si Jellyfin affiche ensuite l’élément. Vérifiez les groupes supplémentaires et les ACL par défaut avant de modifier toute l’arborescence.

N’utilisez pas une modification récursive des permissions autorisant tout le monde en écriture comme solution permanente. Faites correspondre l’identité du service au groupe prévu, ou définissez explicitement le groupe partagé et l’ACL par défaut pour les répertoires précis qui nécessitent une collaboration.

Testez un nouveau fichier via le chemin d’importation exact après avoir modifié l’identité. Ne jugez pas la correction à partir de fichiers créés avant la recréation du conteneur ou du conteneur auxiliaire.

Réparez l’héritage et validez après la recréation

Appliquez la modification minimale de propriété ou d’ACL au répertoire concerné, recréez un fichier de test et vérifiez son propriétaire et son mode. Recréez le conteneur et redémarrez l’hôte, puis répétez le même import afin de vous assurer que la correction résiste au déploiement et à l’ordre de montage.

Faites remonter le problème lorsque les changements de propriété réapparaissent après une recréation propre, que le système de fichiers ignore la propriété POSIX ou que plusieurs services se disputent la gestion du même chemin. Conservez le fichier fonctionnel et la configuration Compose tout en identifiant progressivement le processus d’écriture.

Si la propriété change à nouveau après le redémarrage, le montage ou le déploiement applique une identité différente. Conservez la configuration Compose fonctionnelle avant de modifier à nouveau l’arborescence du système de fichiers.

-15% OFF

Vérifiez la propriété après un redémarrage et une réimportation

Recréez le conteneur, redémarrez l’hôte et importez un fichier de test contrôlé. Confirmez le propriétaire, le groupe, le mode et la visibilité dans Jellyfin depuis l’hôte et le conteneur.

Conservez la correction lorsque les nouveaux fichiers héritent du groupe prévu et que Jellyfin peut lire ou écrire uniquement dans les répertoires requis par le flux de travail. N’accordez pas un accès en écriture étendu à toute l’arborescence des médias.

Faites remonter le problème lorsque le système de fichiers, la couche ACL ou plusieurs processus d’écriture continuent de modifier la propriété après la réimportation contrôlée.

Assistance et conseils

Plus à lire

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.