O problema original do qBittorrent tinha duas camadas. Primeiro, o qBittorrent tem de guardar num caminho que exista dentro do contentor. Segundo, o processo do qBittorrent tem de ter permissão de escrita na pasta do anfitrião por trás desse caminho do contentor. O utilizador já tinha resolvido a camada do mapeamento — a pasta estava visível — mas o registo de execução continuava a indicar Permissão negada.
A solução da comunidade criou uma pasta de descargas dedicada e utilizou uma configuração muito abrangente chmod -R 777 como teste rápido às permissões. O autor da publicação original confirmou que as descargas passaram então a funcionar. Esse resultado prova que a falha era um problema de permissões de escrita, mas 777 não deve ser a recomendação permanente num sistema atual.
As definições de armazenamento do qBittorrent no ZimaOS mapearam uma pasta Movies do anfitrião para o caminho do contentor /Movies-TV
/Movies-TV.A fonte utilizou:
-
Anfitrião:
/media/Main Storage/Media/Movies -
Contentor:
/Movies-TV
Dentro do qBittorrent, o caminho de armazenamento deve utilizar /Movies-TV/..., e não o caminho bruto no anfitrião.
A visibilidade comprovou que o mapeamento funcionava; a permissão negada comprovou que as escritas não funcionavam
O registo de execução do qBittorrent do utilizador indicava Permissão negada. Isto é diferente de Ficheiro ou diretório inexistente:
- Ficheiro ou diretório inexistente: é provável que o mapeamento ou o caminho esteja incorreto.
- Permissão negada: o contentor consegue aceder ao caminho, mas não consegue escrever nele.
Uma pasta de descargas dedicada é mais fácil de configurar corretamente ao nível das permissões
A comunidade criou uma subpasta, por exemplo:
/media/Main Storage/Media/Movies/qbittorrent-downloadse definiu o destino do qBittorrent no lado do contentor como:
/Movies-TV/qbittorrent-downloadsIsto é melhor do que conceder a um programa de descargas acesso de escrita a toda uma árvore de ficheiros multimédia, se ele só precisar de um diretório de preparação.
chmod 777 Foi um atalho de diagnóstico, não um modelo de permissões adequado para a configuração final
A resposta da comunidade utilizou a opção recursiva chmod 777 e o autor da publicação original confirmou que resolveu o problema. Isso estabelece causalidade, mas as permissões de escrita para todos os utilizadores permitem que qualquer processo local escreva no diretório.
Uma solução permanente mais segura consiste em identificar o UID/GID de execução do contentor do qBittorrent e conceder apenas a esse utilizador/grupo o acesso de escrita necessário.
Verifique o proprietário antes de o alterar
As verificações úteis, só de leitura, incluem inspecionar o proprietário/grupo e o modo da pasta antes de modificar qualquer coisa. Se o qBittorrent for executado com um PUID/PGID configurável, alinhe esses valores com um grupo do anfitrião que tenha permissão de escrita na pasta de transferências.
Evite alterar recursivamente o proprietário de toda uma biblioteca multimédia partilhada quando apenas uma pasta precisa de ser gravável.
O ZimaOS atual torna explícitos os caminhos dos volumes das aplicações
A documentação atual da IceWhale explica que as aplicações da App Store são executadas dentro de contentores e que as respetivas pastas importantes são mapeadas para armazenamento real do anfitrião. Esses mapeamentos podem ser consultados e editados nas definições da aplicação.
Utilize o modelo atual de caminhos Docker do ZimaOS antes de editar as permissões.
Separe a pasta de preparação das transferências da biblioteca multimédia final
Uma arquitetura comum é:
- O qBittorrent grava numa pasta de transferências dedicada;
- O Sonarr/Radarr ou outro organizador importa os ficheiros concluídos;
- O Jellyfin/Plex lê a biblioteca multimédia final, frequentemente apenas com permissões de leitura.
Isto dá a cada aplicação apenas o acesso de que necessita.
Teste primeiro com uma única transferência pequena
Depois de alterar o mapeamento ou a permissão:
- reinicie o qBittorrent;
- confirme se o caminho de gravação é resolvido dentro do contentor;
- transfira um pequeno ficheiro de teste legal;
- verifique o registo de execução;
- verifique se o ficheiro aparece no armazenamento do anfitrião pretendido.
FAQ sobre o caminho de transferência do qBittorrent
O próprio mapeamento do volume de origem estava incorreto?
A comunidade concluiu que estava visível/correto; o erro restante era de permissão de escrita.
O chmod 777 fez o caso de origem funcionar?
Sim, e o autor da publicação original confirmou que funcionou. Deve ser tratado como um atalho de diagnóstico abrangente, e não como a permissão permanente preferida.
Que caminho deve o qBittorrent utilizar internamente?
O caminho no lado do contentor definido no mapeamento de volumes do ZimaOS, como /Movies-TV/qbittorrent-downloads.
