Solution communautaire

qBittorrent sur ZimaOS : utilisez le bon dossier de téléchargement

A user mapped a secondary HDD into qBittorrent but entered the ZimaOS host path inside the app; switching to /downloads fixed it.

La solution confirmée dans ce fil consistait à définir le chemin d’enregistrement par défaut de qBittorrent sur le chemin du conteneur Docker /downloads, et non sur le chemin de l’hôte ZimaOS. L’utilisateur avait déjà correctement monté le disque dur secondaire ; qBittorrent était simplement configuré pour enregistrer dans un chemin que seul l’hôte pouvait comprendre.

Modifier PUID/PGID pour utiliser root n’a pas résolu le problème dans le cas d’origine. Une fois le chemin corrigé, l’auteur initial a explicitement confirmé que les téléchargements fonctionnaient.

À quoi ressemblait le mappage d’origine

Fichiers ZimaOS montrant un dossier Downloads sur le disque dur GERAL
L’utilisateur souhaitait que les téléchargements de qBittorrent soient enregistrés dans le dossier Downloads du disque GERAL secondaire. Source : forum communautaire IceWhale.
Vue du stockage ZimaOS montrant GERAL comme disque dur séparé de 2 To
ZimaOS reconnaissait déjà GERAL comme un disque dur séparé de 2 To ; la détection du disque n’était donc pas en cause. Source : forum communautaire IceWhale.
Mappage de volume Docker de qBittorrent, de GERAL Downloads vers /downloads
Le mappage de l’application exposait correctement le dossier de l’hôte à qBittorrent sous le chemin du conteneur /downloads. Source : forum communautaire IceWhale.

Le mappage important est, en substance :

Hôte : /media/GERAL/Downloads → Conteneur : /downloads

ZimaOS voit le chemin de gauche. qBittorrent s’exécute à l’intérieur de Docker et doit normalement utiliser celui de droite.

Le mauvais chemin était configuré dans qBittorrent

Chemin d’enregistrement par défaut de qBittorrent incorrectement défini sur le chemin de l’hôte ZimaOS
Dans qBittorrent, l’utilisateur avait saisi le chemin /media de l’hôte au lieu du chemin du conteneur monté. Source : forum communautaire IceWhale.

L’interface Web de qBittorrent était configurée avec /media/GERAL/Downloads. Ce chemin de l’hôte n’était pas celui exposé à l’application à l’intérieur du conteneur.

Le guide actuel sur le dossier qBittorrent décrit le même cas et la solution vérifiée.

Pourquoi PUID et PGID définis sur root n’ont pas aidé

Les autorisations et la visibilité des chemins sont deux problèmes différents. Exécuter le conteneur en tant que root ne peut pas faire apparaître comme par magie un chemin de l’hôte non monté à l’intérieur du conteneur. Vérifiez d’abord le chemin du conteneur ; ne vérifiez les propriétaires que si le chemin correctement mappé renvoie Permission denied.

Le guide consacré aux autorisations qBittorrent couvre ce second type de problème.

Les images Docker actuelles utilisent le même modèle

L’image qBittorrent actuelle de LinuxServer documente un volume de téléchargements monté sur /downloads. Consultez la documentation qBittorrent de LinuxServer avant de modifier une définition d’application personnalisée.

En résumé

Si ZimaOS mappe déjà votre disque cible dans qBittorrent sous /downloads, utilisez /downloads ou un sous-dossier à l’intérieur de celui-ci dans qBittorrent. Ne collez pas le chemin de l’hôte ZimaOS dans l’application, sauf si ce chemin exact est également monté dans le conteneur.