En résumé : Auto-Organize d’Emby nécessite à la fois un montage Docker accessible en écriture et des permissions hôtes autorisant l’écriture
Emby peut analyser une bibliothèque multimédia avec un accès en lecture seule, mais Auto-Organize doit renommer, déplacer et parfois supprimer des fichiers. Cela nécessite un accès en écriture à deux niveaux : le dossier hôte ZimaOS doit être monté dans le conteneur en lecture/écriture, et le processus Emby doit être autorisé à modifier les fichiers hôtes. Corrigez délibérément ces deux aspects ; n’utilisez pas récursivement chmod 777 comme solution permanente.
Étape 1 : Confirmer que le dossier hôte est monté en lecture/écriture
Ouvrez les paramètres de l’application Emby et examinez les volumes. Un mappage devrait conceptuellement ressembler à ceci :
/media/RAID5/TV -> /media/tvDans Emby, sélectionnez /media/tv. Emby ne peut pas parcourir directement le chemin hôte ZimaOS affiché à gauche. Les montages bind Docker expliquent ce modèle à deux chemins.
Les chemins d’application ZimaOS actuels s’appliquent aux conteneurs de l’App Store en général.
Étape 2 : Prouver que le montage n’est pas en lecture seule
docker inspect EMBY_CONTAINER
Repérez le point de montage bind TV/média et confirmez qu’il n’est pas marqué en lecture seule. Vous pouvez également effectuer un test depuis l’intérieur du conteneur en créant un fichier temporaire inoffensif dans la destination mappée exacte :
docker exec -it EMBY_CONTAINER sh
touch /media/tv/.emby-write-test
rm /media/tv/.emby-write-testSi touch échoue, Auto-Organize échouera également.
Étape 3 : Faire correspondre le processus Emby au propriétaire côté hôte
Vérifiez le dossier hôte et l’identité du processus :
ls -ld /media/RAID5/TV
ls -ln /media/RAID5/TV
docker exec EMBY_CONTAINER idAccordez ensuite uniquement les permissions minimales de propriétaire/groupe requises par ce conteneur. L’ancienne réponse suggérait chown -R 1000:1000, mais l’UID 1000 n’est pas nécessairement l’identité utilisée par toutes les images Emby. Vérifiez d’abord.
La configuration Docker d’Emby constitue la référence amont pour l’image que vous exécutez.
N’utilisez pas chmod -R 777 comme solution permanente
Si 777 rend la fonctionnalité opérationnelle, vous avez démontré qu’il s’agit d’un problème de permissions, mais vous avez également accordé un accès en écriture à tous les utilisateurs et processus locaux. Une fois le test terminé, rétablissez un modèle propriétaire/groupe plus restrictif. Pour un serveur multimédia, 775 avec le groupe approprié est généralement plus sûr que « tout le monde peut écrire », mais les valeurs exactes dépendent de la configuration de l’identité de votre conteneur.
Gardez les chemins source et destination accessibles en écriture
L’organisation automatique peut surveiller un dossier entrant, puis déplacer les fichiers vers la bibliothèque TV finale. Les deux emplacements doivent être visibles dans le conteneur, et la destination doit être accessible en écriture. Une bibliothèque finale en lecture seule peut donner l’impression que le dossier surveillé fonctionne correctement jusqu’à la première opération de renommage ou de déplacement.
Le RAID 5 n’est pas la couche des autorisations
Le fait que les médias se trouvent sur un RAID 5 n’empêche pas les écritures en soi. Le RAID contrôle la redondance et le stockage en blocs ; les montages bind Docker et la propriété du système de fichiers contrôlent l’accès de l’application. Ne reconstruisez pas la grappe simplement parce qu’un conteneur reçoit Permission refusée.
La migration des données ZimaOS est utile lorsque les chemins des médias ont été déplacés après la création du conteneur Emby.
Sauvegarder la configuration d’Emby avant de recréer l’application
Réinstaller Emby peut modifier les paramètres du conteneur sans corriger le dossier multimédia sous-jacent. Préservez la configuration persistante d’Emby et documentez tous les mappages de volumes avant de recréer l’application. La sauvegarde ZimaOS couvre la couche de récupération.
Un ordre de dépannage des autorisations plus sûr
- Vérifiez que le chemin hôte existe.
- Vérifiez que le chemin du conteneur pointe vers cet emplacement.
- Vérifiez que le montage est accessible en lecture/écriture.
- Vérifiez l’UID/GID du conteneur.
- Vérifiez le propriétaire et le groupe sur l’hôte.
- Testez un fichier temporaire.
- Ce n’est qu’ensuite que vous devez tester l’organisation automatique.
Les exigences des applications ZimaOS présentent le modèle de stockage plus large de l’App Store.
FAQ
Pourquoi Emby peut-il lire les fichiers, mais pas les organiser ?
La lecture suffit pour la lecture des fichiers. La fonction d’organisation automatique doit pouvoir créer, renommer, déplacer et supprimer des fichiers.
Dois-je faire un chown du dossier vers 1000:1000 ?
Uniquement si le processus Emby en cours d’exécution utilise effectivement cet UID/GID. Vérifiez d’abord l’identité du conteneur.
chmod 777 est-il sûr ?
Utilisez-le uniquement comme bref diagnostic si nécessaire. Il est trop permissif pour servir de modèle d’autorisations permanent.
Le RAID 5 rend-il Emby accessible en lecture seule ?
Non. Le niveau RAID et les autorisations des fichiers de l’application sont deux couches distinctes.
Quel chemin dois-je ajouter dans Emby ?
Utilisez le chemin côté conteneur indiqué dans le mappage de volume Docker, et non le chemin hôte affiché dans les fichiers ZimaOS.
