O tópico original demonstra por que motivo “a aplicação não consegue escrever no RAID” não deve ser imediatamente tratado como um erro de permissões do ZimaOS. A primeira resposta da comunidade afirmava que, normalmente, os contentores da App Store tinham acesso apenas de leitura fora da respetiva AppData, a menos que uma pasta fosse criada ou “tocada” através de Ficheiros. O autor da publicação original tentou exatamente isso e, ainda assim, não conseguiu criar pastas no SFTPGo nem eliminar música do Navidrome.
Depois desses contraexemplos, o autor da resposta reviu a explicação: a propriedade do sistema de ficheiros é apenas uma camada. Cada aplicação também tem o seu próprio utilizador do contentor, caminhos internos esperados e limites funcionais. Essa correção posterior é a lição mais fiável.
Existem três camadas de permissões diferentes
- Armazenamento do anfitrião ZimaOS: a pasta real do RAID ou do disco, bem como a respetiva propriedade e permissões.
- Mapeamento de volumes Docker: se a pasta do anfitrião está montada no contentor e se a montagem é apenas de leitura.
- Comportamento da aplicação: o utilizador com que a aplicação é executada e se o próprio software permite criar, eliminar ou mudar o nome de ficheiros.
Uma falha em qualquer uma destas camadas pode parecer um erro de “acesso negado”.
Criar a pasta em Ficheiros não foi uma solução universal
A sugestão inicial era criar ou mover a pasta pretendida através de Ficheiros do ZimaOS, para que a propriedade correta lhe fosse aplicada. O autor da publicação original criou srv/data no RAID, indicou-o ao SFTPGo e continuou a receber erros de acesso negado.
Por isso, o método de Ficheiros não pode ser apresentado como uma solução garantida para todas as aplicações.
O SFTPGo precisa de um caminho com escrita que corresponda ao seu utilizador de execução e à sua configuração
O SFTPGo é executado com as suas próprias permissões e regras de pastas virtuais/diretório inicial. Uma pasta do anfitrião pode existir e estar visível, mas continuar sem permissões de escrita para o processo do SFTPGo.
Numa implementação atual, verifique em conjunto a pasta do anfitrião, o modo de montagem Docker, o UID/GID do contentor e o diretório inicial/pasta virtual configurado para o utilizador do SFTPGo.
O Navidrome é sobretudo um servidor de biblioteca multimédia
O autor da resposta original afirmou que o Navidrome deve ser tratado como sendo apenas de leitura para a gestão da biblioteca e que, no contexto em causa, a eliminação de faixas a partir do Navidrome não era suportada. Por conseguinte, a incapacidade de apagar uma música não era uma boa prova de que as permissões do RAID estivessem universalmente avariadas.
Gira os ficheiros de música de origem com Ficheiros ou outra ferramenta de gestão de ficheiros, salvo se a versão atual específica do Navidrome documentar uma funcionalidade suportada de modificação de ficheiros.
Verifique se o volume Docker está montado como apenas de leitura
Um mapeamento de volume pode utilizar explicitamente o modo apenas de leitura. Se a aplicação se destina a modificar ficheiros, a pasta do anfitrião tem de ser mapeada com permissões de leitura e escrita, e a identidade do processo tem de ter permissões de escrita no sistema de ficheiros do anfitrião.
O ZimaOS atual permite aos utilizadores consultar e editar os mapeamentos de volumes das aplicações nas definições da aplicação.
O ZimaOS atual torna mais visíveis os caminhos do anfitrião e do contentor
A IceWhale documenta agora a relação entre caminhos do lado da aplicação, como /config ou /media, e as pastas de armazenamento reais que lhes servem de suporte.
Consulte o modelo atual de caminhos das aplicações do ZimaOS antes de utilizar chmod/chown recursivos como primeira resposta.
Não utilize chmod 777 como atalho de diagnóstico
Permissões de escrita demasiado abrangentes podem ocultar o verdadeiro problema e expor dados partilhados a processos não relacionados. Também não resolvem o problema de uma aplicação que abre intencionalmente um volume em modo apenas de leitura ou recusa um caminho através da sua própria configuração.
Altere apenas a propriedade ou as permissões de grupo mínimas exigidas pela aplicação.
Uma sequência de diagnóstico melhor
- Confirme a pasta exata do anfitrião no ZimaOS.
- Confirme que os volumes da aplicação mapeiam essa pasta para o caminho esperado dentro do contentor.
- Verifique se o mapeamento é apenas de leitura.
- Identifique o UID/GID ou o utilizador com que o contentor é executado.
- Verifique se essa identidade consegue escrever na pasta do anfitrião.
- Confirme que a própria aplicação suporta a operação tentada.
Perguntas frequentes sobre permissões de armazenamento das aplicações
A recriação da pasta em Ficheiros do ZimaOS resolveu o caso original do SFTPGo?
Não. O autor da publicação original tentou fazê-lo e continuou a receber um erro de acesso negado.
Uma pasta do RAID com permissões de leitura passa automaticamente a permitir escrita em todas as aplicações?
Não. O modo de montagem Docker, o UID/GID do contentor e o comportamento da aplicação continuam a ser relevantes.
O Navidrome deve ser utilizado como gestor de ficheiros de uso geral?
Não. Trate a origem da música como sendo gerida fora do Navidrome, salvo se a aplicação atual suportar explicitamente a modificação de ficheiros.
