Si qBittorrent peut voir un dossier dans ZimaOS, mais que chaque torrent échoue immédiatement, modifier uniquement le chemin de téléchargement dans qBittorrent ne suffit pas. Le dossier hôte doit d’abord être monté dans le conteneur Docker, et l’utilisateur exécutant qBittorrent dans ce conteneur doit avoir l’autorisation d’écrire dans le répertoire hôte monté.
C’est ce qui s’est produit dans le fil de discussion IceWhale Community de janvier 2026. L’auteur d’origine avait associé un dossier multimédia à /Movies-TV, mais le journal d’exécution de qBittorrent affichait Permission denied. La création d’un sous-dossier dédié et l’octroi d’autorisations d’écriture sur l’hôte ont résolu le problème d’origine. La communauté a utilisé chmod -R 777 comme solution rapide, mais les recommandations actuelles de LinuxServer privilégient l’alignement de PUID/PGID sur le propriétaire du dossier hôte plutôt que de laisser le répertoire accessible en écriture à tout le monde.
Chemin hôte et chemin du conteneur
Un chemin ZimaOS n’est pas automatiquement visible dans qBittorrent. Une association classique est la suivante :
Hôte : /DATA/Downloads
Conteneur : /downloadsqBittorrent doit alors enregistrer les téléchargements dans un chemin du conteneur tel que /downloads/qbittorrent.
L’association d’origine
Hôte : /media/Main Storage/Media/Movies
Conteneur : /Movies-TV
Créer un dossier de téléchargement dédié
La structure utilisée dans la solution confirmée par la communauté était la suivante :
/media/Main Storage/Media/Movies/qbittorrent-downloadset ce chemin était utilisé dans qBittorrent :
/Movies-TV/qbittorrent-downloadsVérifier les autorisations
ls -ld "/media/Main Storage/Media/Movies"
ls -ld "/media/Main Storage/Media/Movies/qbittorrent-downloads"Si le répertoire existe, mais que le journal indique Permission denied, l’identité du conteneur ne dispose pas d’un accès en écriture.
La solution rapide confirmée par la communauté
chmod -R 777 "/media/Main Storage/Media/Movies/qbittorrent-downloads"L’auteur d’origine a confirmé que cette commande fonctionnait. Toutefois, 777 accorde largement les droits de lecture, d’écriture et d’exécution. Utilisez-la donc comme outil de diagnostic ou solution temporaire, plutôt que comme modèle d’autorisations permanent.
Solution durable recommandée : aligner PUID et PGID
L’image qBittorrent actuelle de LinuxServer prend en charge PUID et PGID afin d’éviter les conflits d’autorisations liés aux montages bind. Sa documentation recommande de configurer la propriété du répertoire hôte de manière compatible avec les identifiants fournis au conteneur.
Documentation LinuxServer de qBittorrent
PUID=1000
PGID=1000Ces valeurs ne sont que des exemples. Vérifiez le compte hôte concerné avec id USERNAME et utilisez les identifiants réels ou un groupe partagé compatible.
Redémarrer et tester
- Enregistrez l’association de volume.
- Redémarrez ou recréez qBittorrent.
- Définissez le chemin d’enregistrement par défaut sur le chemin du conteneur associé.
- Lancez un petit téléchargement de test.
- Consultez Outils → Journal d’exécution si l’opération échoue encore.
Signification des erreurs
- Permission denied : le chemin existe, mais n’est pas accessible en écriture.
- No such file or directory : le chemin du conteneur est absent ou incorrectement associé.
FAQ sur le chemin de téléchargement de qBittorrent
qBittorrent doit-il utiliser le chemin hôte de ZimaOS ?
Non. Il doit normalement utiliser le chemin côté conteneur défini dans l’association de volume.
chmod 777 a-t-il résolu le problème du fil d’origine ?
Oui. L’auteur a confirmé que cela fonctionnait, mais des autorisations plus restrictives fondées sur PUID/PGID ou sur un groupe sont plus sûres à long terme.
Pourquoi qBittorrent peut-il voir un dossier sans pouvoir y écrire ?
La visibilité d’un montage Docker et les autorisations d’écriture du système de fichiers sont deux choses distinctes. Un dossier associé peut être lisible sans être accessible en écriture par l’utilisateur du conteneur.
