O erro A pasta '/tv/' não tem permissões de escrita para o utilizador 'abc' isto significa que o Sonarr consegue ver o diretório montado, mas o processo em execução dentro do contentor não tem permissão para escrever nele. O mesmo problema pode ocorrer no Radarr como um erro da pasta raiz de filmes.
No caso da IceWhale Community de julho de 2025, ambas as aplicações vieram da App Store do ZimaOS e utilizavam os valores predefinidos PUID=1000 e PGID=1000As pastas multimédia do utilizador estavam num conjunto de armazenamento RAID. Um membro da equipa da IceWhale sugeriu definir ambos os IDs como 0, e o autor original confirmou que isto tornou as pastas graváveis. No entanto, este é um resultado importante da fonte, mas executar a aplicação com IDs equivalentes aos do root concede um acesso ao sistema de ficheiros muito mais amplo do que o normalmente necessário. A documentação atual da LinuxServer.io recomenda associar PUID/PGID ao proprietário ou grupo dos diretórios do anfitrião.
O que significa “A pasta não tem permissões de escrita para o utilizador abc”
O pacote da App Store do ZimaOS mencionado no tópico utilizava contentores Sonarr e Radarr ao estilo da LinuxServer. Estas imagens executam o processo da aplicação com um utilizador interno normalmente apresentado como abc, enquanto PUID e PGID mapear esse processo interno para IDs numéricos de utilizador e grupo no sistema de ficheiros do anfitrião.
Se o diretório do anfitrião pertencer a um UID/GID diferente e os respetivos bits de permissão não permitirem que o processo mapeado escreva, o Sonarr ou o Radarr consegue navegar pelo ponto de montagem, mas não consegue criar, mudar o nome, mover ou importar ficheiros multimédia aí.
Os mapeamentos originais da App Store do ZimaOS
A publicação incluía capturas de ecrã de configuração separadas para o Radarr e o Sonarr. As aplicações conseguiam ver os volumes do anfitrião configurados, mas a criação da pasta raiz falhava dentro das aplicações.
Os erros do Sonarr e do Radarr
O Sonarr devolveu:
Não foi possível adicionar a pasta raiz
A pasta '/tv/' não tem permissões de escrita para o utilizador 'abc'
O Radarr apresentou o problema correspondente no caminho dos filmes:
A solução da comunidade: PUID=0 e PGID=0
Um membro da equipa IceWhale respondeu:
PUID=0
PGID=0O autor da publicação original alterou ambos os valores para zero e relatou que o problema pareceu resolvido. Esta é, portanto, a resolução confirmada para essa configuração específica da Loja de Aplicações do ZimaOS em julho de 2025.
No entanto, o UID 0 e o GID 0 são identidades de nível raiz no Linux. Executar o Sonarr ou o Radarr com esses IDs pode permitir à aplicação escrever em locais muito além da biblioteca de multimédia pretendida, caso esses caminhos estejam montados no contentor. Utilize esta opção apenas como diagnóstico ou solução de compatibilidade, quando compreender os acessos que concede.
Correção preferencial: fazer corresponder o PUID e o PGID ao proprietário do armazenamento no anfitrião
A documentação atual do LinuxServer.io para o Sonarr e o Radarr explica o objetivo deste modelo: definir o PUID e o PGID de acordo com o proprietário do armazenamento no anfitrião PUID e PGID para um utilizador/grupo no anfitrião que já seja proprietário do volume mapeado ou tenha acesso de escrita ao mesmo.
As orientações do LinuxServer indicam que os problemas de permissões surgem quando um volume no anfitrião pertence a IDs que não correspondem aos IDs fornecidos ao contentor. O padrão recomendado é:
PUID=1000
PGID=1000apenas quando UID 1000 e GID 1000 forem realmente adequados para os caminhos de multimédia. O número 1000 não é inerentemente correto; é simplesmente um ID de utilizador Linux não root comum como primeira opção.
Consulte a documentação do LinuxServer sobre o Sonarr atual e a documentação do LinuxServer sobre o Radarr atual.
Como inspecionar o proprietário e as permissões do armazenamento
Se a interface de Ficheiros do ZimaOS não mostrar os valores numéricos de proprietário/grupo do Linux de que necessita, inspecione o caminho real no anfitrião a partir de um terminal autorizado.
Primeiro, identifique o diretório real no anfitrião mapeado para /tv ou /moviesEm seguida, inspecione-o:
ls -ldn /REAL/HOST/PATH
stat /REAL/HOST/PATHO resultado numérico ajuda a determinar qual UID e GID são atualmente proprietários do diretório. Não execute estes comandos no caminho existente apenas no contentor /tv do anfitrião, a menos que esse seja genuinamente o caminho no anfitrião.
Se a conta de gestão de multimédia pretendida estiver disponível no anfitrião, pode consultar os respetivos IDs com:
id USERNAMEDepois, defina o Sonarr/Radarr PUID e PGID para os IDs que correspondem ao modelo de acesso que definiu deliberadamente.
Não faça chown cegamente a /tv dentro do contentor
Outra resposta da comunidade sugeriu:
sudo chown abc:abc /tv/Esse conselho é arriscado quando é copiado sem contexto. A propriedade de um diretório montado por bind é, em última análise, representada por IDs numéricos no anfitrião. O nome abc existe nos contentores LinuxServer e pode não existir como uma conta de anfitrião relevante. Alterar a propriedade recursivamente também pode afetar inesperadamente toda uma biblioteca multimédia.
Antes de utilizar chown, confirme:
- o caminho exato no anfitrião que será alterado;
- o UID e o GID pretendidos no anfitrião;
- se outros serviços, como o qBittorrent, o SABnzbd, o Jellyfin ou utilizadores SMB, precisam de acesso aos mesmos ficheiros;
- se um grupo partilhado será mais adequado do que alterar a propriedade.
Faça uma cópia de segurança das configurações importantes e evite alterações recursivas de permissões até compreender o respetivo efeito.
Planeie as permissões da multimédia partilhada em toda a stack ARR
O Sonarr e o Radarr raramente funcionam isoladamente. Um cliente de transferências cria primeiro os ficheiros; depois, o Sonarr ou o Radarr importa-os, e o Jellyfin pode ler o resultado. Se cada contentor utilizar IDs e montagens sem relação entre si, uma aplicação pode criar ficheiros que outra aplicação não consegue modificar.
Uma conceção mais limpa consiste em atribuir às aplicações um grupo comum ou um mapeamento PUID/PGID compatível para o conjunto de dados partilhado. A LinuxServer também recomenda caminhos de volumes bem planeados, para que os clientes de transferências e as aplicações ARR possam utilizar hardlinks ou movimentações atómicas quando apropriado.
Por exemplo, em vez de tratar as transferências e a multimédia como montagens isoladas e sem relação, uma única árvore de dados partilhada no anfitrião pode facilitar a análise das permissões e da consistência dos caminhos:
/data
├── transferências
├── multimédia
│ ├── filmes
│ └── tvO caminho exato no ZimaOS depende do seu conjunto de armazenamento e não deve ser copiado cegamente.
Quando é útil a solução alternativa com IDs de root?
Definir PUID/PGID como 0 pode ser útil como diagnóstico rápido:
- Se o erro desaparecer imediatamente, é provável que a montagem do contentor esteja correta.
- O problema restante estará então provavelmente relacionado com a propriedade no anfitrião ou com o mapeamento de permissões.
Depois de confirmado, o objetivo mais seguro a longo prazo é conceder ao contentor apenas as permissões necessárias para os respetivos caminhos de multimédia e transferências. Se o seu modelo exato de armazenamento do ZimaOS tornar impraticável um mapeamento sem root, documente por que motivo são necessários IDs de root e limite cuidadosamente os diretórios montados.
Reiniciar as aplicações depois de alterar o PUID ou o PGID
O PUID e o PGID são aplicados quando o contentor é iniciado. Depois de os alterar no ZimaOS:
- Guarde a configuração da aplicação.
- Reinicie ou recrie o contentor do Sonarr/Radarr através do ZimaOS.
- Abra novamente as definições da pasta raiz.
- Teste a criação ou seleção da pasta mapeada.
Se a pasta continuar sem permissões de escrita, compare a propriedade numérica e o modo do diretório no anfitrião com os IDs agora utilizados pelo contentor.
Lista de verificação de permissões do Sonarr/Radarr no ZimaOS
- Confirme que o caminho multimédia do anfitrião está montado no Sonarr ou no Radarr.
- Confirme que o caminho do contentor é o selecionado dentro da aplicação.
- Inspecione o UID, o GID e os bits de permissão do caminho no anfitrião.
- Verifique o
PUIDePGIDnas definições da aplicação ZimaOS. - Prefira IDs que correspondam ao proprietário/grupo pretendido no anfitrião.
- Reinicie o contentor depois de alterar os IDs.
- Use PUID/PGID 0 apenas compreendendo o acesso ao nível do root que isso concede.
- Evite operações recursivas abrangentes
chmod 777 às cegasouchowncorrige. - Certifique-se de que os clientes de transferências e os servidores multimédia utilizam um modelo de permissões partilhadas compatível.
Perguntas frequentes sobre permissões do Sonarr e do Radarr
Quem é o utilizador abc?
abc é o nome de utilizador interno do serviço normalmente utilizado pelos contentores do LinuxServer.io. O PUID e o PGID determinam qual a identidade numérica do anfitrião que esse processo utiliza para aceder aos volumes mapeados.
Porque é que PUID=1000 e PGID=1000 falham?
Esses valores só funcionam quando o UID/GID 1000 tem o acesso necessário ao diretório multimédia do anfitrião. Se o diretório RAID do ZimaOS pertencer a outro utilizador ou grupo, o contentor pode conseguir vê-lo, mas não escrever nele.
PUID=0 e PGID=0 resolvem o problema?
Resolveu o caso original da comunidade, conforme confirmado pelo autor. Também concede acesso equivalente ao do root dentro do sistema de ficheiros mapeado, pelo que não deve ser automaticamente a configuração permanente preferida.
Devo executar chmod 777 na pasta multimédia?
Não como solução predefinida. As permissões de escrita para todos são desnecessariamente abrangentes e podem ocultar a verdadeira incompatibilidade de propriedade. Em vez disso, configure deliberadamente a identidade do contentor e as permissões do grupo partilhado.
O Sonarr, o Radarr e o cliente de transferências devem usar o mesmo PUID/PGID?
Nem sempre precisam de IDs de utilizador idênticos, mas precisam de um modelo de propriedade/grupo compatível para quaisquer ficheiros e pastas que partilhem. Usar um grupo partilhado consistente é uma forma comum de evitar falhas de importação e mudança de nome.
