CasaOS Syncthing não consegue eliminar ou modificar ficheiros sincronizados

Conclusão principal: se o Syncthing consegue ler uma pasta mas não consegue propagar eliminações ou modificações, teste a permissão de escrita a partir do interior do contentor do Syncthing. Uma montagem associada legível não é automaticamente gravável.

Verifique primeiro o modo da pasta

Uma pasta bidirecional deve utilizar modos de pasta do Syncthing adequados para receber alterações. O modo Apenas envio não funcionará como Enviar e receber.

Comprove que o contentor consegue escrever

docker exec -it syncthing sh
touch /DATA/Gallery/.write-test
rm /DATA/Gallery/.write-test

Se algum dos comandos falhar, corrija as permissões de armazenamento antes de alterar as definições do Syncthing.

Captura de ecrã de um erro de pasta do Syncthing no CasaOS, mostrando uma pasta a falhar enquanto as pastas vizinhas funcionam — Quando uma pasta falha mas as pastas vizinhas funcionam, compare o caminho exato e a propriedade.

Captura de ecrã do caminho de armazenamento do CasaOS utilizada para comparar os mapeamentos de pastas do Syncthing — Utilize uma pasta funcional como referência ao comparar os caminhos de montagem.

Faça corresponder PUID e PGID

O compose oficial do Syncthing para CasaOS passa PUID/PGID e associa /DATA ao contentor. A LinuxServer explica a propriedade PUID/PGID dos volumes do anfitrião.

docker exec syncthing id
stat -c '%u:%g %a %n' /DATA/Gallery

Compare os IDs numéricos. Alterar a propriedade para um nome de utilizador não é suficiente se o contentor for executado com um UID/GID diferente.

As eliminações requerem permissões na pasta principal

Remover ou mudar o nome de um ficheiro requer permissões de escrita e execução na pasta principal. Isto explica por que motivo a leitura/sincronização pode parecer parcialmente funcional enquanto as eliminações remotas falham.

Localização do registo da aplicação CasaOS destacada para a resolução de problemas do Syncthing — Utilize os registos juntamente com testes diretos do sistema de ficheiros.

Estado de não sincronização do Syncthing após um dispositivo remoto modificar ficheiros num anfitrião CasaOS — Um estado de não sincronização após edições remotas aponta para o caminho de escrita do lado recetor.

Compare uma pasta funcional

Compare docker inspect syncthing montagens, stat modo/UID/GID, ACLs com getfacl, estado de sistema de ficheiros só de leitura e padrões a ignorar. Não avance diretamente para chmod 777.

A configuração do Syncthing no CasaOS fornece uma base de referência limpa. A plataforma de aplicações ZimaOS ajuda a comparar alternativas, enquanto o ZimaCube 2 é adequado para cargas de trabalho de armazenamento com várias unidades.

Verifique as ACL quando os bits de modo Unix parecem corretos

Tradicional chmod o resultado pode parecer correto, embora uma ACL continue a alterar as permissões efetivas. Compare um diretório que funciona com um que falha:

getfacl /DATA/Gallery
getfacl /DATA/Documents

Se um dos caminhos contiver entradas ACL adicionais, corrija-as deliberadamente em vez de abrir recursivamente as permissões em todo o lado.

Verifique se o sistema de ficheiros está montado em modo só de leitura

findmnt -no TARGET,SOURCE,FSTYPE,OPTIONS /DATA/Gallery

Um disco montado ro, erros do sistema de ficheiros ou uma unidade externa degradada podem produzir o mesmo sintoma de “consegue ler, mas não consegue alterar”. Se a montagem estiver em modo só de leitura, alterar as definições do Syncthing não resolverá o problema.

Leia o erro do Syncthing por detrás de “fora de sincronia”

Abra a interface Web do Syncthing e verifique o erro da pasta; em seguida, compare os registos do contentor:

docker logs --tail 200 syncthing

Procure permissão negada, operação não permitida, erros de caminho não encontrado ou operações de mudança de nome/eliminação falhadas. “Fora de sincronia” é um estado; o registo geralmente contém a causa subjacente no sistema de ficheiros.

Não utilize Ignorar permissões como solução universal

Ignorar os metadados de permissões pode ajudar quando dois sistemas de ficheiros representam os bits de modo Unix de forma diferente, mas não concede permissão de escrita ao processo. Se o contentor não conseguir eliminar um ficheiro de teste, alterar o comportamento dos metadados de permissões do Syncthing não tornará o diretório do anfitrião editável.

Utilize um teste de escrita controlado

Crie um diretório pequeno e descartável, mapeie-o no Syncthing e verifique as operações criar → editar → mudar o nome → eliminar em ambos os dispositivos. Quando isso funcionar, aplique o mesmo padrão de propriedade e montagem à pasta real. Assim, isola o comportamento da sincronização de uma árvore de diretórios existente e complexa.

Perguntas frequentes

Porque é que o Syncthing consegue adicionar, mas não eliminar?

As permissões do diretório principal podem permitir a leitura, mas impedir operações de mudança de nome/eliminação.

Devo utilizar chmod 777?

Não. Primeiro, comprove o caminho que falha e a identidade do contentor.