L’erreur Le dossier « /tv/ » n’est pas accessible en écriture pour l’utilisateur « abc » cela signifie que Sonarr peut voir le répertoire monté, mais que le processus exécuté dans le conteneur n’a pas l’autorisation d’y écrire. Le même problème peut apparaître dans Radarr sous la forme d’une erreur concernant le dossier racine des films.
Dans le cas de la communauté IceWhale de juillet 2025, les deux applications provenaient de l’App Store de ZimaOS et utilisaient les valeurs par défaut PUID=1000 et PGID=1000. Les dossiers multimédias de l’utilisateur se trouvaient sur un pool de stockage RAID. Un membre de l’équipe IceWhale a suggéré de définir les deux identifiants sur 0, et l’auteur de la publication d’origine a confirmé que cela rendait les dossiers accessibles en écriture. C’est un résultat important de la source, mais exécuter l’application avec des identifiants équivalents à ceux de root accorde un accès bien plus large au système de fichiers que nécessaire dans la plupart des cas. La documentation actuelle de LinuxServer.io recommande plutôt d’aligner PUID/PGID sur le propriétaire ou le groupe des répertoires hôtes.
Ce que signifie « Le dossier n’est pas accessible en écriture pour l’utilisateur abc »
Le paquet de l’App Store de ZimaOS utilisé dans la discussion reposait sur des conteneurs Sonarr et Radarr de type LinuxServer. Ces images exécutent le processus de l’application sous un utilisateur interne généralement affiché comme abc, tandis que PUID et PGID mapper ce processus interne vers des identifiants numériques d’utilisateur et de groupe sur le système de fichiers hôte.
Si le répertoire hôte appartient à un autre UID/GID et que ses bits d’autorisation n’autorisent pas le processus mappé à écrire, Sonarr ou Radarr peuvent parcourir le point de montage, mais ne peuvent pas y créer, renommer, déplacer ou importer des fichiers multimédias.
Les mappages d’origine de l’App Store de ZimaOS
La publication comprenait des captures d’écran distinctes de la configuration de Radarr et de Sonarr. Les applications pouvaient voir les volumes hôtes configurés, mais la création du dossier racine échouait dans les applications.
Les erreurs de Sonarr et Radarr
Sonarr a renvoyé :
Impossible d’ajouter le dossier racine
Le dossier « /tv/ » n’est pas accessible en écriture pour l’utilisateur « abc »
Radarr affichait le problème correspondant pour le chemin des films :
Correctif communautaire : PUID=0 et PGID=0
Un membre de l’équipe IceWhale a répondu :
PUID=0
PGID=0L’auteur du message d’origine a remplacé les deux valeurs par zéro et a indiqué que le problème semblait résolu. Il s’agit donc de la résolution confirmée pour cette configuration spécifique de l’App Store de ZimaOS datant de juillet 2025.
Cependant, l’UID 0 et le GID 0 correspondent aux identités root sous Linux. Exécuter Sonarr ou Radarr avec ces identifiants peut permettre à l’application d’écrire dans des emplacements bien au-delà de la bibliothèque multimédia prévue si ces chemins sont montés dans le conteneur. Utilisez cette solution uniquement comme mesure de diagnostic ou de compatibilité lorsque vous comprenez les accès qu’elle accorde.
Correctif recommandé : faire correspondre PUID et PGID au propriétaire du stockage hôte
La documentation actuelle de LinuxServer.io concernant Sonarr et Radarr explique la conception prévue : définir PUID et PGID à un utilisateur ou groupe hôte qui possède déjà le volume associé ou qui dispose d’un accès en écriture à celui-ci.
Les recommandations de LinuxServer indiquent que les problèmes d’autorisations surviennent lorsqu’un volume hôte appartient à des identifiants qui ne correspondent pas à ceux fournis au conteneur. Leur configuration recommandée est la suivante :
PUID=1000
PGID=1000uniquement lorsque l’UID 1000 et le GID 1000 sont réellement appropriés pour les chemins multimédias. Le nombre 1000 n’est pas intrinsèquement correct ; il s’agit simplement d’un identifiant courant pour le premier utilisateur Linux non root.
Consultez la documentation LinuxServer de Sonarr actuelle ainsi que la documentation LinuxServer de Radarr actuelle.
Comment inspecter le propriétaire et les autorisations du stockage
Si l’interface Fichiers de ZimaOS n’affiche pas les valeurs numériques du propriétaire et du groupe Linux dont vous avez besoin, inspectez le chemin réel sur l’hôte depuis un terminal autorisé.
Identifiez d’abord le véritable répertoire hôte associé à /tv ou /moviesInspectez-le ensuite :
ls -ldn /REAL/HOST/PATH
stat /REAL/HOST/PATHLa sortie numérique vous aide à déterminer quel UID et quel GID possèdent actuellement le répertoire. N’exécutez pas ces commandes sur le chemin accessible uniquement dans le conteneur. /tv depuis l’hôte, sauf s’il s’agit réellement du chemin sur l’hôte.
Si le compte destiné à la gestion des médias est disponible sur l’hôte, vous pouvez consulter ses identifiants avec :
id USERNAMEDéfinissez ensuite le Sonarr/Radarr PUID et PGID aux identifiants correspondant au modèle d’accès que vous souhaitez délibérément mettre en place.
Ne faites pas aveuglément un chown de /tv dans le conteneur
Une autre réponse de la communauté suggérait :
sudo chown abc:abc /tv/Ce conseil est risqué s’il est repris sans contexte. La propriété d’un répertoire monté par liaison est finalement représentée par des identifiants numériques sur l’hôte. Le nom abc existe dans les conteneurs LinuxServer et peut ne pas correspondre à un compte hôte significatif, voire ne pas exister sur l’hôte. Modifier récursivement la propriété peut également affecter toute une bibliothèque multimédia de manière inattendue.
Avant d’utiliser chown, confirmez :
- le chemin exact sur l’hôte qui sera modifié ;
- l’UID et le GID souhaités sur l’hôte ;
- si d’autres services tels que qBittorrent, SABnzbd, Jellyfin ou des utilisateurs SMB doivent accéder aux mêmes fichiers ;
- si un groupe partagé serait plus approprié qu’une modification de la propriété.
Sauvegardez les configurations importantes et évitez de modifier récursivement les autorisations tant que vous n’en comprenez pas les effets.
Planifier les autorisations des médias partagés pour l’ensemble de la pile ARR
Sonarr et Radarr fonctionnent rarement seuls. Un client de téléchargement crée d’abord les fichiers, puis Sonarr ou Radarr les importe, et Jellyfin peut ensuite lire le résultat. Si chaque conteneur utilise des identifiants et des montages indépendants, une application peut créer des fichiers qu’une autre ne peut pas modifier.
Une conception plus propre consiste à attribuer aux applications un groupe commun ou une correspondance PUID/PGID compatible pour le jeu de données partagé. LinuxServer recommande également de planifier soigneusement les chemins des volumes afin que les clients de téléchargement et les applications ARR puissent utiliser des liens matériels ou des déplacements atomiques lorsque cela est approprié.
Par exemple, au lieu de traiter les téléchargements et les médias comme des montages isolés et indépendants, une arborescence de données hôte partagée peut faciliter la gestion des autorisations et la cohérence des chemins :
/data
├── téléchargements
├── médias
│ ├── films
│ └── sériesLe chemin exact dans ZimaOS dépend de votre pool de stockage et ne doit pas être copié sans vérification.
Quand la solution de contournement avec des identifiants root est-elle utile ?
Définir PUID/PGID sur 0 peut être utile pour un court diagnostic :
- Si l’erreur disparaît immédiatement, le montage du conteneur lui-même est probablement correct.
- Le problème restant vient alors probablement de la propriété des fichiers sur l’hôte ou de la correspondance des autorisations.
Une fois la vérification effectuée, l’objectif à long terme le plus sûr est de n’accorder au conteneur que les autorisations nécessaires à ses chemins de médias et de téléchargements. Si votre modèle de stockage ZimaOS exact rend difficile l’utilisation d’une correspondance sans privilèges root, documentez pourquoi les identifiants root sont requis et limitez soigneusement les répertoires montés.
Redémarrer les applications après avoir modifié PUID ou PGID
PUID et PGID sont appliqués au démarrage du conteneur. Après les avoir modifiés dans ZimaOS :
- Enregistrez la configuration de l’application.
- Redémarrez ou recréez le conteneur Sonarr/Radarr via ZimaOS.
- Ouvrez à nouveau les paramètres du dossier racine.
- Testez la création ou la sélection du dossier mappé.
Si le dossier reste non accessible en écriture, comparez la propriété numérique et le mode du répertoire hôte avec les identifiants actuellement utilisés par le conteneur.
Liste de contrôle des permissions de Sonarr/Radarr dans ZimaOS
- Vérifiez que le chemin multimédia de l’hôte est monté dans Sonarr ou Radarr.
- Vérifiez que le chemin du conteneur est bien celui sélectionné dans l’application.
- Examinez l’UID, le GID et les bits de permission du chemin hôte.
- Vérifiez le
PUIDetPGIDdans les paramètres de l’application ZimaOS. - Privilégiez les identifiants correspondant au propriétaire/groupe prévu sur l’hôte.
- Redémarrez le conteneur après avoir modifié les identifiants.
- N’utilisez PUID/PGID 0 qu’en comprenant bien l’accès au niveau root que cela accorde.
- Évitez les opérations récursives trop larges
chmod 777 à l’aveugleou unchowncorrectifs. - Assurez-vous que les clients de téléchargement et les serveurs multimédias utilisent un modèle de permissions partagées compatible.
FAQ sur les permissions de Sonarr et Radarr
Qui est l’utilisateur abc ?
abc Il s’agit du nom d’utilisateur de service interne couramment utilisé par les conteneurs LinuxServer.io. PUID et PGID déterminent l’identité numérique de l’hôte utilisée par ce processus pour accéder aux volumes mappés.
Pourquoi PUID=1000 et PGID=1000 échouent-ils ?
Ces valeurs ne fonctionnent que lorsque l’UID/GID 1000 dispose de l’accès requis au répertoire multimédia de l’hôte. Si le répertoire RAID de ZimaOS appartient à un autre utilisateur ou groupe, le conteneur peut être capable de le consulter, mais pas d’y écrire.
PUID=0 et PGID=0 résolvent-ils le problème ?
Cela a résolu le problème du cas d’origine de la communauté, comme l’a confirmé son auteur. Cela accorde également un accès équivalent à celui de root dans le système de fichiers monté ; cette configuration ne devrait donc pas être automatiquement privilégiée comme solution permanente.
Dois-je appliquer chmod 777 au dossier multimédia ?
Pas comme solution par défaut. Les permissions accessibles en écriture à tous sont inutilement larges et peuvent masquer le véritable problème de discordance de propriété. Faites plutôt correspondre délibérément l’identité du conteneur et les permissions du groupe partagé.
Sonarr, Radarr et le client de téléchargement doivent-ils utiliser le même PUID/PGID ?
Ils n’ont pas toujours besoin d’identifiants utilisateur identiques, mais ils doivent utiliser un modèle de propriété et de groupe compatible pour tous les fichiers et dossiers qu’ils partagent. L’utilisation d’un groupe partagé cohérent est un moyen courant d’éviter les échecs d’importation et de renommage.
