Esta situação começou como um problema frustrante de permissões e acabou por se transformar numa solução repetível. O Syncthing conseguia comunicar com o par Windows e sincronizar para a sua localização AppData predefinida, mas tentar utilizar um caminho de NAS montado, como /media/raid/NAS/Music produziu permissão negada e caminho da pasta em falta erros.
Em agosto de 2025, um utilizador da comunidade publicou a abordagem que funcionou no seu caso: reinstalar o Syncthing com a Instalação Personalizada, utilizar o PUID/PGID do utilizador real do ZimaOS, escolher uma raiz de sincronização adequada e deixar que o Syncthing crie a sua própria pasta de destino. Dois utilizadores posteriores confirmaram explicitamente que isto funcionou. O guia oficial atual da IceWhale para o Syncthing documenta agora essencialmente a mesma configuração.
O Syncthing Original Só Conseguia Escrever no Seu Caminho AppData Predefinido
O utilizador de origem poderia preencher:
/DATA/AppData/syncthing/config/Syncmas não conseguia utilizar o caminho de música pretendido no disco rígido, embora Ficheiros, Jellyfin e Navidrome conseguissem aceder-lhe. Isto é uma forte evidência de uma incompatibilidade de identidade/permissões do contentor, e não de uma falha do disco.
Executar o Syncthing como Root Foi Sugerido, mas Não é a Correção Atual Preferida
Uma resposta inicial da comunidade sugeria PUID/GUID 0. Executar um serviço de sincronização de ficheiros como root pode contornar muitos problemas de permissões, mas também dá ao contentor uma capacidade de escrita/eliminação muito mais ampla do que o necessário.
As orientações atuais da IceWhale recomendam explicitamente a utilização dos IDs do utilizador real.
Utilizar a Instalação Personalizada
Encontrar o PUID e o PGID Reais do Utilizador do ZimaOS
As orientações oficiais atuais utilizam:
id -u nome de utilizador
id -g nome de utilizadorSubstitua nome de utilizador com a conta do ZimaOS que deve ser proprietária e gerir os ficheiros sincronizados e, em seguida, copie os IDs numéricos devolvidos para as variáveis de ambiente do Syncthing.
Não Utilizar a Raiz de um Disco Montado como Pasta do Syncthing
A documentação atual da IceWhale indica que a raiz de um disco montado ou pastas do sistema, como Gallery/Media/Documents, não devem ser utilizadas diretamente como caminho da pasta do Syncthing, pois isso normalmente requer privilégios ao nível da raiz.
Em alternativa, crie/ utilize uma subpasta dedicada adequada.
Deixar o Syncthing Criar a Pasta de Destino
A solução da comunidade alertava especificamente os utilizadores para não criarem previamente o destino através do navegador de Ficheiros do ZimaOS. A documentação oficial atual repete agora a mesma prática recomendada: defina o destino no Syncthing e deixe que o Syncthing o crie.
Esta correção da comunidade está agora refletida na documentação oficial do ZimaOS
Utilize a configuração atual do Syncthing no ZimaOS.
Por que razão o guia avisa que IDs incorretos podem exigir uma reinstalação
Se a primeira instalação criar a configuração/pastas com a identidade errada, alterar simplesmente um valor mais tarde pode deixar a propriedade antiga. Por isso, as orientações atuais pedem aos utilizadores que verifiquem cuidadosamente o PUID/PGID antes da instalação.
Faça uma cópia de segurança da configuração do Syncthing se esta contiver relações importantes entre dispositivos e pastas, antes de eliminar os dados da aplicação para uma reinstalação limpa.
Teste primeiro com uma pequena pasta descartável
Antes de apontar o Syncthing para uma grande árvore de música ou documentos, sincronize primeiro uma pequena pasta de teste, verifique o comportamento bidirecional se estiver ativado, confirme a propriedade no NAS e só depois adicione as pastas de produção.
A correção funciona porque todas as camadas de permissões ficam finalmente alinhadas
Para que o Syncthing crie ficheiros corretamente, quatro aspetos têm de estar alinhados: a pasta do anfitrião ZimaOS existe e tem permissões de escrita para o utilizador/grupo pretendido, o Docker mapeia essa pasta para o contentor, o Syncthing é executado com o PUID/PGID correspondente e o caminho da pasta configurado no Syncthing aponta para a montagem do lado do contentor. Uma incompatibilidade em qualquer uma das camadas pode apresentar o mesmo sintoma de “permissão negada”.
Por que razão as raízes de discos montados não são um destino de sincronização predefinido adequado
A raiz de um disco montado contém frequentemente diretórios geridos pelo sistema, metadados de partilhas ou permissões destinadas a vários serviços. Conceder a um motor de sincronização acesso amplo de escrita nesse local aumenta o alcance de eliminações acidentais ou de uma configuração incorreta. Uma subpasta dedicada torna muito mais fácil compreender a propriedade e a política de cópias de segurança.
Valide a semântica de eliminação do Syncthing antes de ativar a sincronização bidirecional
O Syncthing propaga as alterações de acordo com o modo da pasta, incluindo eliminações em configurações de envio/receção. Antes de o apontar para uma grande biblioteca de música ou documentos, teste o comportamento de criação/alteração do nome/eliminação com ficheiros descartáveis e considere o versionamento do Syncthing se for importante recuperar de eliminações remotas acidentais.
Perguntas frequentes sobre o Syncthing no ZimaOS
Os utilizadores posteriores confirmaram que a abordagem PUID/PGID funcionou?
Sim. Pelo menos dois participantes posteriores na fonte afirmaram explicitamente que o método publicado resolveu o problema.
O Syncthing deve ser executado como root para aceder aos discos?
As orientações atuais da IceWhale recomendam utilizar o PUID/PGID do utilizador real do ZimaOS e, em vez disso, uma subpasta adequada.
Devo criar primeiro a pasta de destino em Ficheiros do ZimaOS?
A documentação atual da IceWhale indica que deve deixar o Syncthing criar a pasta de destino.
