A solução confirmada neste tópico foi definir o Caminho predefinido para guardar do qBittorrent como o caminho do contentor Docker /downloads, e não como o caminho do anfitrião ZimaOS. O utilizador já tinha montado corretamente o HDD secundário; o qBittorrent estava simplesmente a ser instruído a guardar num caminho que apenas o anfitrião reconhecia.
Alterar PUID/PGID para root não resolveu o caso original. Assim que o caminho foi corrigido, o autor original confirmou explicitamente que os downloads funcionavam.
Como era o mapeamento original
O mapeamento importante é, conceptualmente:
Anfitrião: /media/GERAL/Downloads → Contentor: /downloads
O ZimaOS vê o lado esquerdo. O qBittorrent é executado dentro do Docker e deve normalmente utilizar o lado direito.
O caminho incorreto estava dentro do qBittorrent
A interface Web do qBittorrent estava configurada com /media/GERAL/Downloads. Esse caminho do anfitrião não era o caminho exposto à aplicação dentro do contentor.
O guia atual sobre pastas do qBittorrent documenta o mesmo caso e a resolução verificada.
Porque é que PUID e PGID como root não ajudaram
As permissões e a visibilidade do caminho são problemas diferentes. Executar como root não faz com que um caminho do anfitrião não montado apareça magicamente dentro de um contentor. Primeiro, verifique o caminho do contentor; só investigue o proprietário quando o caminho mapeado correto devolver Permission denied.
O guia de permissões do qBittorrent aborda esse segundo modo de falha.
As imagens Docker atuais utilizam o mesmo padrão
A imagem atual do qBittorrent da LinuxServer documenta um volume de downloads montado em /downloads. Consulte a documentação do qBittorrent da LinuxServer antes de alterar uma definição de aplicação personalizada.
Em resumo
Se o ZimaOS já mapeia o disco pretendido para o qBittorrent como /downloads, utilize /downloads ou uma subpasta dentro dele no qBittorrent. Não cole o caminho do anfitrião ZimaOS na aplicação, a menos que esse caminho exato também esteja montado no contentor.
