CasaOS Syncthing : impossible de supprimer ou de modifier les fichiers synchronisés

Conclusion clé : si Syncthing peut lire un dossier, mais ne peut pas propager les suppressions ou les modifications, testez les permissions d’écriture depuis l’intérieur du conteneur Syncthing. Un montage lié accessible en lecture n’est pas automatiquement accessible en écriture.

Vérifiez d’abord le mode du dossier

Un dossier bidirectionnel doit utiliser des modes de dossier Syncthing adaptés à la réception des modifications. Le mode Envoi uniquement ne se comportera pas comme le mode Envoi et réception.

Vérifiez que le conteneur peut écrire

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

Si l’une ou l’autre commande échoue, corrigez les permissions du stockage avant de modifier les paramètres de Syncthing.

Capture d’écran d’une erreur de dossier Syncthing dans CasaOS montrant qu’un dossier échoue alors que les dossiers voisins fonctionnent — Lorsqu’un dossier échoue alors que les dossiers voisins fonctionnent, comparez le chemin exact et la propriété.

Capture d’écran du chemin de stockage CasaOS utilisée pour comparer les mappages de dossiers Syncthing — Utilisez un dossier fonctionnel comme référence pour comparer les chemins de montage.

Faites correspondre PUID et PGID

Le compose Syncthing de CasaOS officiel transmet PUID/PGID et monte /DATA dans le conteneur. LinuxServer explique la propriété PUID/PGID des volumes hôtes.

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

Comparez les identifiants numériques. Remplacer la propriété par un nom d’utilisateur ne suffit pas si le conteneur s’exécute avec un autre UID/GID.

Les suppressions nécessitent des droits sur le répertoire parent

La suppression ou le renommage d’un fichier nécessite les permissions d’écriture et d’exécution sur le répertoire parent. Cela explique pourquoi la lecture et la synchronisation peuvent sembler partiellement fonctionnelles alors que les suppressions distantes échouent.

Emplacement du journal de l’application CasaOS mis en évidence pour le dépannage de Syncthing — Utilisez les journaux avec des tests directs du système de fichiers.

État de désynchronisation de Syncthing après la modification de fichiers par un appareil distant sur un hôte CasaOS — Un état de désynchronisation après des modifications distantes indique un problème au niveau du chemin d’écriture du côté récepteur.

Comparez un dossier fonctionnel

Comparez docker inspect syncthing les montages, stat mode/UID/GID, les ACL avec getfacl, l’état du système de fichiers en lecture seule et les motifs d’exclusion. Ne passez pas directement à chmod 777.

La configuration de Syncthing pour CasaOS fournit une base propre. La plateforme d’applications ZimaOS permet de comparer les alternatives, tandis que ZimaCube 2 convient aux charges de travail de stockage multi-disques.

Vérifiez les ACL lorsque les bits de mode Unix semblent corrects

Traditionnel chmod La sortie peut sembler correcte alors qu’une ACL modifie toujours les permissions effectives. Comparez un répertoire fonctionnel avec un répertoire en échec :

getfacl /DATA/Gallery
getfacl /DATA/Documents

Si un chemin contient des entrées ACL supplémentaires, corrigez-les intentionnellement plutôt que d’ouvrir récursivement les permissions partout.

Vérifiez si le système de fichiers est en lecture seule

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

Un disque monté ro, les erreurs du système de fichiers ou un lecteur externe dégradé peuvent produire le même symptôme : « peut lire, mais ne peut pas modifier ». Si le montage lui-même est en lecture seule, modifier les paramètres de Syncthing ne pourra pas résoudre le problème.

Lisez l’erreur Syncthing derrière « désynchronisé »

Ouvrez l’interface web de Syncthing et examinez l’erreur du dossier, puis comparez les journaux du conteneur :

docker logs --tail 200 syncthing

Recherchez autorisation refusée, opération non autorisée, des erreurs de chemin introuvable ou des opérations de renommage/suppression échouées. « Désynchronisé » est un état ; le journal contient généralement la cause sous-jacente liée au système de fichiers.

N’utilisez pas Ignorer les permissions comme solution universelle

Ignorer les métadonnées de permissions peut être utile lorsque deux systèmes de fichiers représentent différemment les bits de mode Unix, mais cela n’accorde pas au processus l’autorisation d’écrire. Si le conteneur ne peut pas supprimer un fichier de test, modifier le comportement de Syncthing concernant les métadonnées de permissions ne rendra pas le répertoire de l’hôte accessible en écriture.

Utilisez un test d’écriture contrôlé

Créez un petit répertoire temporaire, mappez-le dans Syncthing et vérifiez les opérations créer → modifier → renommer → supprimer depuis les deux appareils. Une fois que cela fonctionne, appliquez le même modèle de propriété et de montage au dossier réel. Cela permet d’isoler le comportement de synchronisation d’une arborescence existante complexe.

FAQ

Pourquoi Syncthing peut-il ajouter des fichiers, mais pas les supprimer ?

Les permissions du répertoire parent peuvent autoriser la lecture tout en bloquant les opérations de renommage et de suppression.

Dois-je utiliser chmod 777 ?

Non. Prouvez d’abord le chemin en échec et l’identité du conteneur.