Se o qBittorrent consegue ver uma pasta no ZimaOS, mas todas as torrents falham imediatamente, alterar apenas o caminho de transferência dentro do qBittorrent não é suficiente. Primeiro, a pasta do anfitrião tem de ser montada no contentor Docker e o utilizador que executa o qBittorrent dentro desse contentor tem de ter permissão para escrever na pasta montada do anfitrião.
Foi isso que aconteceu no tópico da IceWhale Community de janeiro de 2026. O autor original mapeou uma pasta de multimédia para /Movies-TV, mas o registo de execução do qBittorrent apresentava Permission denied. Uma subpasta dedicada, juntamente com permissões de escrita no anfitrião, resolveu o caso original. A comunidade utilizou chmod -R 777 como solução rápida, mas as orientações atuais do LinuxServer favorecem a correspondência entre PUID/PGID e o proprietário no anfitrião, em vez de deixar a pasta com permissões de escrita para todos.
Caminho do Anfitrião vs. Caminho do Contentor
Um caminho do ZimaOS não fica automaticamente visível dentro do qBittorrent. Um mapeamento normal é:
Anfitrião: /DATA/Downloads
Contentor: /downloadsDepois, o qBittorrent deve guardar os ficheiros num caminho do contentor, como /downloads/qbittorrent.
O Mapeamento Original
Anfitrião: /media/Main Storage/Media/Movies
Contentor: /Movies-TV
Criar uma Pasta de Transferências Dedicada
A estrutura utilizada pela comunidade foi:
/media/Main Storage/Media/Movies/qbittorrent-downloadse este caminho foi utilizado dentro do qBittorrent:
/Movies-TV/qbittorrent-downloadsVerificar as Permissões
ls -ld "/media/Main Storage/Media/Movies"
ls -ld "/media/Main Storage/Media/Movies/qbittorrent-downloads"Se a pasta existir, mas o registo indicar Permission denied, a identidade do contentor não tem acesso de escrita.
A Solução Rápida Confirmada pela Comunidade
chmod -R 777 "/media/Main Storage/Media/Movies/qbittorrent-downloads"O autor original confirmou que isto funcionou. No entanto, 777 concede permissões amplas de leitura, escrita e execução, pelo que deve ser utilizado como diagnóstico ou solução temporária, e não como modelo ideal de permissões permanente.
Solução a Longo Prazo Preferida: Corresponder PUID e PGID
A imagem atual do qBittorrent do LinuxServer suporta PUID e PGID especificamente para evitar conflitos de permissões em montagens bind. A documentação recomenda tornar a propriedade da pasta no anfitrião compatível com os IDs fornecidos ao contentor.
Documentação do qBittorrent do LinuxServer
PUID=1000
PGID=1000Estes valores são apenas exemplos. Verifique a conta pretendida no anfitrião com id USERNAME e utilize os IDs reais ou um grupo partilhado compatível.
Reiniciar e Testar
- Guarde o mapeamento do volume.
- Reinicie ou recrie o qBittorrent.
- Defina o caminho predefinido para guardar ficheiros como o caminho mapeado do contentor.
- Inicie uma pequena transferência de teste.
- Consulte Ferramentas → Registo de execução se continuar a falhar.
O Que Significam os Erros
- Permission denied: o caminho existe, mas não permite escrita.
- No such file or directory: o caminho do contentor está em falta ou foi mapeado incorretamente.
Perguntas Frequentes sobre o Caminho de Transferências do qBittorrent
O qBittorrent deve utilizar o caminho do anfitrião do ZimaOS?
Não. Normalmente, deve utilizar o caminho do lado do contentor definido no mapeamento do volume.
O chmod 777 resolveu o problema do tópico original?
Sim. O autor confirmou que funcionou, mas permissões mais restritas através de PUID/PGID ou de grupos são mais seguras a longo prazo.
Porque é que o qBittorrent consegue ver uma pasta, mas não consegue escrever nela?
A visibilidade da montagem Docker e a permissão de escrita no sistema de ficheiros são independentes. Uma pasta mapeada pode ser legível, mas não permitir a escrita pelo utilizador do contentor.
