Conclusão principal: provavelmente, este não é um problema de «continuar a alterar o chmod até o Syncthing funcionar». O sinal mais forte é que a pasta funciona quando está num caminho que o Syncthing consegue ver diretamente, mas falha quando um link simbólico atravessa para outra unidade física. Na CasaOS, isso aponta primeiro para os caminhos montados no contentor e, depois, para as permissões de UID/GID.
«Já configurei as permissões até ao fim… funciona quando seleciono /DATA/AppData/, mas não quando o link aponta para uma unidade física diferente.» Esse resultado do teste é mais útil do que o erro de permissões original, porque isola a falha no caminho de armazenamento.
Por que motivo o link simbólico é a primeira coisa a questionar
O Syncthing não interpreta um link simbólico como «por favor, avance para o destino e sincronize o que lá estiver». O comportamento documentado dos links simbólicos no Syncthing é que os links simbólicos podem ser sincronizados, mas nunca são seguidos. A configuração das pastas também espera um caminho real no dispositivo: o caminho da pasta no Syncthing é o caminho físico para a pasta no disco rígido.
Isso torna suspeito um caminho como este:
/DATA/Documents/Syncthing/SyncFiles → link simbólico → /some/other/physical/driveSe o Syncthing estiver a ser executado no Docker, o anfitrião pode resolver esse link, enquanto o contentor poderá nem sequer conseguir ver o destino.
A aplicação Syncthing da CasaOS explica por que motivo uma segunda unidade pode desaparecer
A definição oficial do Syncthing na CasaOS App Store é especialmente útil neste caso. O respetivo ficheiro compose monta duas localizações do anfitrião no contentor através de bind:
/DATA/AppData/$AppID/config → /config
/DATA → /DATAPode verificar o mapeamento real dos volumes no compose do Syncthing no CasaOS.
Isto significa que um destino fisicamente disponível na árvore /DATA do anfitrião também deverá estar visível em /DATA dentro do contentor Syncthing. No entanto, se o link simbólico apontar, em última análise, para uma montagem do anfitrião fora dessa árvore, o contentor precisará de uma montagem bind separada para o destino real. Com montagens bind do Docker, os diretórios do anfitrião têm de ser montados explicitamente no contentor.
Utilize este teste para distinguir um problema de caminho de um problema de permissões
Execute as verificações por esta ordem. Não comece por outro chmod recursivo.
1. Resolva o caminho real no anfitrião do CasaOS
readlink -f "/DATA/Documents/Syncthing/SyncFiles"Se o comando devolver um caminho fora de /DATA, encontrou uma pista importante.
2. Pergunte ao contentor do Syncthing se consegue ver o mesmo destino
docker exec syncthing ls -ld "/DATA/Documents/Syncthing/SyncFiles"Depois, teste o destino resolvido, caso deva existir dentro do contentor. Se o anfitrião o consegue listar, mas o contentor não, as permissões ainda não são o problema principal; o caminho está ausente do espaço de nomes do contentor.
3. Inspecione as montagens reais do contentor
docker inspect syncthingConsulte a Montagens secção. Deverá conseguir identificar a origem no anfitrião e o destino no contentor da unidade que pretende sincronizar.
A solução mais limpa: monte a unidade real como bind e utilize depois esse caminho no contentor
Se a unidade externa estiver fora de /DATA, expondo-o diretamente ao Syncthing em vez de o ocultar atrás de um link simbólico. Conceptualmente, a entrada do compose tem o seguinte aspeto:
volumes:
- type: bind
source: /real/host/path/to/external-drive
target: /sync-driveDepois, configure o caminho da pasta do Syncthing como algo explícito, por exemplo:
/sync-drive/Dev FilesEste não é um caminho mágico; escolha um destino que corresponda à sua configuração do compose. O importante é que o contentor receba o diretório real do anfitrião como um volume montado.
A imagem Syncthing LinuxServer upstream utiliza o mesmo modelo e documenta mapeamentos de dados separados do anfitrião para o contentor, como /path/to/data1:/data1 e /path/to/data2:/data2. O seu mapeamento de PUID/PGID do Syncthing também explica como a identidade do contentor deve corresponder à propriedade do volume no anfitrião.
Só depois de a montagem estar correta deverá corrigir a propriedade e as permissões
A resolução de problemas original incluía uma sugestão deste género:
sudo chmod -R 770 /path/to/folder770 podem ser adequados em algumas configurações, mas só ajudam se o Syncthing estiver efetivamente a ser executado como um utilizador ou grupo que seja proprietário desse diretório ou pertença ao grupo proprietário. A aplicação CasaOS passa PUID e PGID na imagem do LinuxServer. A documentação do próprio LinuxServer indica que a propriedade dos volumes no anfitrião deve corresponder ao PUID/PGID configurado.
Verifique os IDs em vez de presumir o nome de utilizador casaos é suficiente:
docker exec syncthing id
stat -c '%u:%g %a %n' /real/host/path/to/external-driveSe o UID/GID numéricos não coincidirem, altere intencionalmente a propriedade ou a pertença ao grupo. Evite chmod -R 777; oculta o verdadeiro problema e enfraquece o controlo de acesso.
O que o erro “o ficheiro existe” realmente indica
A mensagem:
mkdir /DATA/Documents/Syncthing/SyncFiles: o ficheiro existenão prova que o diretório final Ficheiros de desenvolvimento o diretório é o problema. O Syncthing está a falhar ao preparar a raiz da pasta. Quando um caminho principal é um link simbólico ou é resolvido de forma diferente dentro do contentor, a aplicação pode encontrar um objeto do sistema de ficheiros onde esperava um caminho de diretório normal.
O diagnóstico mais rápido não consiste, portanto, em eliminar e recriar o mesmo diretório. Consiste em comparar:
- o caminho resolvido no anfitrião;
- o caminho visível dentro do contentor;
- as montagens vinculadas do contentor;
- o PUID/PGID numéricos com a propriedade do destino.
Para uma configuração de base limpa, a configuração do Syncthing no CasaOS apresenta um fluxo normal de sincronização no mesmo caminho antes da personalização para várias unidades. A plataforma de aplicações do ZimaOS é útil para comparar ferramentas alternativas de cópia de segurança ou sincronização de ficheiros. Se o objetivo final for consolidar várias unidades físicas em vez de as interligar através de links simbólicos, o ZimaCube 2 é a opção de hardware centrada no armazenamento.
Perguntas frequentes
Devo resolver isto alterando o proprietário de root para casaos?
Não por si só. A propriedade só é relevante depois de o contentor conseguir ver o caminho de destino real. Verifique primeiro a montagem vinculada e o PUID/PGID numéricos.
Por que motivo um caminho direto funciona, mas o link simbólico para outra unidade falha?
Existe um caminho direto sob um diretório montado no contentor em ambos os sistemas de ficheiros. Um link simbólico pode resolver para uma localização do anfitrião que nunca foi montada no contentor, deixando o Syncthing com um caminho que não consegue percorrer.
O Syncthing segue links simbólicos para sincronizar o diretório de destino?
Não. A documentação do Syncthing afirma que os links simbólicos nunca são seguidos. Utilize um caminho de pasta real visível para o processo do Syncthing.
O que devo alterar primeiro?
Resolva o link simbólico, inspecione as montagens do contentor do Syncthing e monte diretamente o diretório real da unidade externa. Em seguida, verifique o PUID/PGID e as permissões.
