The source qBittorrent problem had two layers. First, qBittorrent must save to a path that exists inside the container. Second, the qBittorrent process must have write permission to the host folder behind that container path. The user had already solved the mapping layer—the folder was visible—but the execution log still showed Permission Denied.
Le problème qBittorrent de départ comportait deux niveaux. Premièrement, qBittorrent doit enregistrer vers un chemin qui existe à l’intérieur du conteneur. Deuxièmement, le processus qBittorrent doit disposer des permissions d’écriture sur le dossier de l’hôte situé derrière ce chemin de conteneur. L’utilisateur avait déjà résolu le problème du mappage : le dossier était visible, mais le journal d’exécution affichait toujours Permission Denied. La solution de la communauté a créé un dossier de téléchargement dédié et utilisé une commande très permissive chmod -R 777 777 comme test rapide des permissions. L’auteur du message original a confirmé que les téléchargements fonctionnaient alors. Ce résultat prouve que l’échec était dû à un problème de permissions d’écriture, mais
ne devrait pas constituer la recommandation permanente sur un système actuel.
/Movies-TV.La source utilisait :
-
Hôte :
/media/Main Storage/Media/Movies -
Conteneur :
/Movies-TV
Dans qBittorrent, le chemin d’enregistrement doit utiliser /Movies-TV/..., et non le chemin brut sur l’hôte.
La visibilité a prouvé que le mappage fonctionnait ; « Permission denied » a prouvé que les écritures échouaient
Le journal d’exécution de qBittorrent de l’utilisateur indiquait Permission Denied. C’est différent de No such file or directory:
- No such file/directory : le mappage ou le chemin est probablement incorrect.
- Permission denied : le conteneur peut atteindre le chemin, mais ne peut pas y écrire.
Un dossier de téléchargement dédié est plus facile à configurer correctement au niveau des permissions
La communauté a créé un sous-répertoire tel que :
/media/Main Storage/Media/Movies/qbittorrent-downloadset à définir la destination côté conteneur de qBittorrent sur :
/Movies-TV/qbittorrent-downloadsC’est préférable à l’octroi d’un accès en écriture à un téléchargeur sur tout un arbre de médias s’il n’a besoin que d’un seul répertoire de mise en attente.
chmod 777 était un raccourci de diagnostic, pas un bon modèle de permissions définitif
La réponse de la communauté utilisait une commande récursive chmod 777 et l’auteur du message original a confirmé que cela avait résolu le problème. Cela établit un lien de causalité, mais des permissions accessibles en écriture à tous permettent à chaque processus local d’écrire dans le répertoire.
Une solution permanente plus sûre consiste à identifier l’UID/GID d’exécution du conteneur qBittorrent et à accorder uniquement à cet utilisateur ou groupe les droits d’écriture nécessaires.
Vérifiez le propriétaire avant de le modifier
Les vérifications en lecture seule utiles consistent notamment à examiner le propriétaire, le groupe et le mode du dossier avant toute modification. Si qBittorrent s’exécute avec un PUID/PGID configurable, faites correspondre ces valeurs à un groupe hôte disposant d’un accès en écriture au répertoire de téléchargements.
Évitez de modifier récursivement le propriétaire de toute une bibliothèque multimédia partagée lorsqu’un seul dossier doit être accessible en écriture.
ZimaOS rend désormais explicites les chemins des volumes d’application
La documentation actuelle d’IceWhale explique que les applications de l’App Store s’exécutent dans des conteneurs et que leurs dossiers importants sont mappés vers un véritable stockage hôte. Ces mappages peuvent être consultés et modifiés dans les paramètres de l’application.
Utilisez le modèle actuel des chemins Docker de ZimaOS avant de modifier les autorisations.
Séparez le dossier de téléchargement temporaire de la bibliothèque multimédia finale
Une architecture courante est la suivante :
- qBittorrent écrit dans un dossier de téléchargements dédié ;
- Sonarr/Radarr ou un autre outil d’organisation importe les fichiers terminés ;
- Jellyfin/Plex lit la bibliothèque multimédia finale, souvent en lecture seule.
Cela permet à chaque application de disposer uniquement des accès dont elle a besoin.
Testez d’abord avec un seul petit téléchargement
Après avoir modifié le mappage ou les autorisations :
- redémarrez qBittorrent ;
- confirmez que le chemin d’enregistrement se résout à l’intérieur du conteneur ;
- téléchargez un petit fichier de test légal ;
- consultez le journal d’exécution ;
- vérifiez que le fichier apparaît sur le stockage hôte prévu.
FAQ sur le chemin de téléchargement de qBittorrent
Le mappage du volume source lui-même était-il incorrect ?
La communauté a conclu que le dossier était visible et correctement configuré ; l’erreur restante concernait les droits d’écriture.
chmod 777 a-t-il permis au cas source de fonctionner ?
Oui, et l’auteur du message original a confirmé que cela fonctionnait. Il faut le considérer comme un raccourci de diagnostic général plutôt que comme une autorisation permanente recommandée.
Quel chemin qBittorrent doit-il utiliser en interne ?
Le chemin côté conteneur défini dans le mappage de volume ZimaOS, tel que /Movies-TV/qbittorrent-downloads.
