Conclusion essentielle : il ne s’agit probablement pas d’un problème où il faudrait « continuer à modifier chmod jusqu’à ce que Syncthing fonctionne ». Le signal le plus probant est que le dossier fonctionne lorsqu’il se trouve sur un chemin que Syncthing peut voir directement, mais échoue lorsqu’un lien symbolique traverse vers un autre disque physique. Dans CasaOS, cela oriente d’abord vers les chemins montés dans le conteneur, puis vers les permissions UID/GID.
« J’ai déjà configuré les permissions jusqu’au bout… cela fonctionne quand je cible /DATA/AppData/, mais pas quand le lien pointe vers un autre disque physique. » Ce résultat de test est plus utile que l’erreur de permission initiale, car il localise l’échec au chemin de stockage.
Pourquoi le lien symbolique est le premier élément à remettre en question
Syncthing ne considère pas un lien symbolique comme une invitation à « aller jusqu’à la cible et à synchroniser tout ce qui s’y trouve ». Selon le informations documentées sur le comportement des liens symboliques de Syncthing, les liens symboliques peuvent être synchronisés, mais ne sont jamais suivis. La configuration de ses dossiers attend également un chemin réel propre à l’appareil : le chemin du dossier Syncthing correspond au chemin physique du dossier sur le disque dur.
Cela rend suspect un chemin comme celui-ci :
/DATA/Documents/Syncthing/SyncFiles → lien symbolique → /some/other/physical/driveSi Syncthing s’exécute dans Docker, l’hôte peut résoudre ce lien alors que le conteneur peut ne pas voir du tout la destination.
L’application Syncthing de CasaOS explique pourquoi un deuxième disque peut disparaître
La définition officielle de Syncthing dans l’App Store de CasaOS est particulièrement utile ici. Son fichier compose monte deux chemins de l’hôte dans le conteneur :
/DATA/AppData/$AppID/config → /config
/DATA → /DATAVous pouvez vérifier le mappage réel des volumes dans le fichier compose Syncthing de CasaOS.
Cela signifie qu’une cible physiquement disponible sous l’arborescence /DATA de l’hôte devrait également être visible sous /DATA dans le conteneur Syncthing. Mais si le lien symbolique pointe finalement vers un point de montage de l’hôte situé en dehors de cette arborescence, le conteneur a besoin d’un montage bind distinct pour accéder à la destination réelle. Avec les montages bind Docker, les répertoires de l’hôte doivent être explicitement montés dans le conteneur.
Utilisez ce test pour distinguer un problème de chemin d’un problème d’autorisations
Effectuez les vérifications dans cet ordre. Ne commencez pas par un autre chmod récursif.
1. Résolvez le chemin réel sur l’hôte CasaOS
readlink -f "/DATA/Documents/Syncthing/SyncFiles"Si la commande renvoie un chemin situé en dehors de /DATA, vous avez découvert un indice important.
2. Demandez au conteneur Syncthing s’il peut voir la même destination
docker exec syncthing ls -ld "/DATA/Documents/Syncthing/SyncFiles"Testez ensuite la destination résolue si elle est censée exister dans le conteneur. Si l’hôte peut la parcourir mais pas le conteneur, les autorisations ne sont pas encore le problème principal ; le chemin est absent de l’espace de noms du conteneur.
3. Inspectez les montages réels du conteneur
docker inspect syncthingConsultez la Montages section. Vous devriez pouvoir identifier la source sur l’hôte et la destination dans le conteneur pour le lecteur que vous souhaitez synchroniser.
La solution la plus propre : liez le véritable lecteur, puis utilisez ce chemin dans le conteneur
Si le lecteur externe se trouve en dehors de /DATA, exposez-le directement à Syncthing au lieu de le dissimuler derrière un lien symbolique. Conceptuellement, l’entrée Compose ressemble à ceci :
volumes:
- type: bind
source: /real/host/path/to/external-drive
target: /sync-driveConfigurez ensuite le chemin du dossier Syncthing de manière explicite, par exemple :
/sync-drive/Dev FilesIl ne s’agit pas d’un chemin magique ; choisissez une destination correspondant à votre configuration Compose. L’essentiel est que le conteneur reçoive le véritable répertoire de l’hôte en tant que volume monté.
L’image Syncthing LinuxServer en amont utilise le même modèle et documente des mappages distincts hôte-conteneur pour les données, tels que /path/to/data1:/data1 et /path/to/data2:/data2. Son mappage PUID/PGID de Syncthing explique également comment l’identité du conteneur doit correspondre à la propriété du volume sur l’hôte.
Ce n’est qu’une fois le montage correct que vous devez corriger la propriété et les autorisations
Le dépannage initial comprenait une suggestion du type :
sudo chmod -R 770 /path/to/folder770 peuvent convenir dans certaines configurations, mais cela n’est utile que si Syncthing s’exécute réellement avec un utilisateur ou un groupe qui possède ce répertoire ou appartient au groupe qui le possède. L’application CasaOS transmet PUID et PGID dans l’image LinuxServer. La documentation officielle de LinuxServer indique que le propriétaire du volume sur l’hôte doit correspondre au PUID/PGID configuré.
Vérifiez les identifiants plutôt que de supposer le nom d’utilisateur casaos suffit :
docker exec syncthing id
stat -c '%u:%g %a %n' /real/host/path/to/external-driveSi l’UID/GID numérique ne correspond pas, modifiez intentionnellement la propriété ou l’appartenance au groupe. Évitez chmod -R 777; il masque le véritable problème et affaiblit le contrôle des accès.
Ce que l’erreur « le fichier existe » indique réellement
Le message :
mkdir /DATA/Documents/Syncthing/SyncFiles : le fichier existene prouve pas que le chemin final Fichiers de développement le répertoire est le problème. Syncthing échoue lors de la préparation de la racine du dossier. Lorsqu’un chemin parent est un lien symbolique ou est résolu différemment à l’intérieur du conteneur, l’application peut rencontrer un objet du système de fichiers là où elle attendait un chemin de répertoire normal.
Le diagnostic le plus rapide ne consiste donc pas à supprimer et recréer le même répertoire. Il faut comparer :
- le chemin résolu sur l’hôte ;
- le chemin visible à l’intérieur du conteneur ;
- les montages bind du conteneur ;
- les valeurs numériques du PUID/PGID avec la propriété de destination.
Pour partir sur une base propre, la configuration de Syncthing avec CasaOS présente un flux normal de synchronisation avec le même chemin avant la personnalisation pour plusieurs disques. La plateforme d’applications ZimaOS est utile pour comparer d’autres outils de sauvegarde ou de synchronisation de fichiers. Si l’objectif final est de regrouper plusieurs disques physiques plutôt que de les relier par des liens symboliques, le ZimaCube 2 est l’option matérielle axée sur le stockage.
FAQ
Dois-je résoudre ce problème en remplaçant le propriétaire root par casaos ?
Pas à lui seul. La propriété n’a d’importance qu’une fois que le conteneur peut accéder au véritable chemin de destination. Vérifiez d’abord le montage bind et les valeurs numériques du PUID/PGID.
Pourquoi un chemin direct fonctionne-t-il alors que le lien symbolique vers un autre disque échoue ?
Un chemin direct sous un répertoire monté dans le conteneur existe dans les deux systèmes de fichiers. Un lien symbolique peut pointer vers un emplacement de l’hôte qui n’a jamais été monté dans le conteneur, laissant Syncthing avec un chemin qu’il ne peut pas parcourir.
Syncthing suit-il les liens symboliques pour synchroniser le répertoire cible ?
Non. La documentation de Syncthing indique que les liens symboliques ne sont jamais suivis. Utilisez un véritable chemin de dossier visible par le processus Syncthing.
Que dois-je modifier en premier ?
Résolvez le lien symbolique, inspectez les montages du conteneur Syncthing et montez le véritable répertoire du disque externe. Vérifiez ensuite le PUID/PGID et les permissions.
