23_Syncthing

Dernière vérification complète : 2026-08-11. Syncthing assure la synchronisation de fichiers entre le VPS Jux (hub), les postes Windows et Ubuntu, le téléphone et la tablette.

Le container sur le VPS

Image	`syncthing/syncthing:latest`
Version	v2.1.2 « Hafnium Hornet » (go1.26.5, build `noupgrade`)
Container	`syncthing` — running (healthy), démarré le 2026-07-31
Politique de redémarrage	`unless-stopped`
Projet compose	`33` (l'ID de stack Portainer, pas `syncthing`)
Réseau	`33_syncthing_net`
URL	https://syncthing.juxjux.ovh
Clé API	`KWwkF5dD5CxeyGwFJ9ejFLHiohALysyF`
Device ID	`HKY4MM4-3ACZXNE-PVUUI6W-4MEYOR4-SYRXXHG-F4U6EPO-OWBDE62-ZBVHJQ3`
Source	github.com/syncthing/syncthing

Ports

Hôte	Container	Rôle
8384	8384/tcp	interface web / API REST
22000	22000/tcp + udp	protocole de synchronisation (BEP)
21027	21027/udp	découverte locale

Volumes

Source (hôte)	Destination	Type
volume anonyme	`/var/syncthing`	volume
`/home/debian/Documents`	`/var/syncthing/Documents`	bind
`/home/debian/Public`	`/var/syncthing/Public`	bind
`/home/debian/docker/syncthing/config`	`/var/syncthing/config`	bind
`/home/debian/docker/syncthing/data1`	`/var/syncthing/data1`	bind
`/home/debian/docker/syncthing/data2`	`/var/syncthing/data2`	bind
`/home/debian/joplin-data`	`/var/syncthing/joplin-data`	bind

Plusieurs volumes sont montés mais un seul est réellement partagé (voir ci-dessous).

Le maillage

Un seul dossier partagé

ID	`afltj-njyuy`
Libellé	Tablette VPS Syncthing
Chemin VPS	`/home/debian/Documents`
Chemin Windows	`D:\Syncthing`
Type	`sendreceive`
Contenu	1 284 fichiers, 495 dossiers, 1 061 Mo

Point d'attention fréquent : Jux_univers, komga-pdf, Jux_Obsidian, Ouvrages… ne sont pas des partages Syncthing distincts — ce sont des sous-dossiers de l'unique dossier afltj-njyuy. Il n'y a rien d'autre à configurer pour qu'ils se synchronisent.

Appareils (état au 2026-08-11)

Nom	Device ID (début)	État	Dernier contact
syncthing-vps	`HKY4MM4`	hub, toujours actif	—
PC-Julien 08/2026	`XLNMUWS`	connecté	2026-08-11
XIAOMI15Pro	`ITCNNE7`	connecté	2026-08-11
Jux_Ubuntu	`Y3FSVEF`	hors ligne	2026-08-08
PCNexte	`QF2XTKM`	hors ligne	2026-08-07
SM-T720	`UUB72GL`	hors ligne	2026-07-23
NAS SASNEXTE	`SBLUVCW`	hors ligne depuis 6 mois	2026-01-30

Le VPS sert de hub : deux appareils qui ne se voient jamais directement restent synchronisés en passant par lui.

Le poste Windows « PC-Julien 08/2026 » (2026-08-10)

Machine	`DESKTOP-B7J2KGP`, utilisateur `julie`
Device ID	`XLNMUWS-P23BMTA-CJPC52K-VOS733O-YGBB2QF-GDA4EI6-YH7TZGP-FENRWA2`
Interface	SyncTrayzor 2.2.0, winget `GermanCoding.SyncTrayzor` — le fork maintenu
Home Syncthing	`D:\SyncthingHome`
Interface web	`http://127.0.0.1:8384` — clé API `PhAm5RvM9gJEzVEosHUWp9fPg2hKLhwr`
Démarrage	clé `HKCU:\…\CurrentVersion\Run`, entrée `SyncTrayzor -minimized`

Trois pièges rencontrés

1. Ne pas prendre SyncTrayzor.SyncTrayzor (1.1.29). Ce paquet winget est le projet d'origine, abandonné depuis 2021 et antérieur à Syncthing 2.x. Le fork maintenu est GermanCoding.SyncTrayzor (2.2.0). Il embarque son propre syncthing.exe (v2.1.2) et le pilote.

2. Le home Syncthing ne doit pas être sous %LOCALAPPDATA% sur ce poste. Claude Code s'exécute dans un conteneur MSIX : ce qu'il écrit dans %LOCALAPPDATA% atterrit en réalité dans …\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Local\. Le profil créé depuis une session Claude était donc invisible pour SyncTrayzor, qui a démarré sur un profil vierge — le poste est resté déconnecté du maillage sans qu'aucun message ne le signale. Symptômes : API locale en 403, plus aucune ligne écrite dans syncthing.log, appareil vu hors ligne côté VPS. Correctif : profil déplacé dans D:\SyncthingHome et <SyncthingCustomHomePath> renseigné dans %APPDATA%\SyncTrayzor\config.xml.

Get-CimInstance Win32_Process -Filter "Name='syncthing.exe'" | Select-Object CommandLine
# doit afficher --home=D:\SyncthingHome

3. Ne jamais faire tourner deux instances sur le même home. Le binaire winget Syncthing.Syncthing avait d'abord été lancé par tâche planifiée ; il a fallu l'arrêter et supprimer la tâche avant d'installer SyncTrayzor, sous peine de verrouillage de la base.

Faire rejoindre le maillage à un poste dont la copie locale est périmée

Méthode à reproduire telle quelle. Un poste qui arrive avec des fichiers vieux de plusieurs jours peut, en sendreceive, ressusciter des fichiers supprimés ailleurs et générer des conflits en série sur toutes les machines.

Sauvegarder hors de l'arbre synchronisé tout fichier modifié localement (voir plus bas).
Ajouter le dossier en receiveonly : l'état du maillage fait autorité, les divergences locales sont retenues sans être poussées.
Attendre needFiles = 0 — ici 229 fichiers / 547 Mo rapatriés.
Basculer en sendreceive : PATCH /rest/config/folders/afltj-njyuy avec {"type":"sendreceive"}.

Constaté lors de cette bascule : la synchronisation a écrasé CLAUDE.md par la version du maillage et déposé les modifications locales dans CLAUDE.sync-conflict-20260810-230652-I4M5WXU.md. Rien n'est perdu, mais il faut penser à rouvrir le fichier de conflit. Contrôle : GET /rest/db/localchanged?folder=afltj-njyuy.

Identité perdue : « PC-Elio+Jux » (supprimé le 2026-08-11)

Ce même poste Windows préexistait dans le maillage sous le nom PC-Elio+Jux (I4M5WXU-…), vu pour la dernière fois le 2026-08-07 à 22:16.

Un device ID Syncthing est sa clé privée (cert.pem / key.pem, rangés dans le home sous le profil Windows). Le profil C:\Users\eliob ayant disparu, la clé a disparu avec lui : l'identité est irrécupérable, et l'appareil ne pouvait pas être « reconnecté » — seulement remplacé par un nouvel ID. Le disque D:, lui, a survécu intact mais figé au 2026-08-06.

Leçon : sauvegarder cert.pem et key.pem hors du profil Windows si l'on tient à conserver l'identité d'un appareil au travers d'une réinstallation.

L'entrée a été retirée du VPS (appareil + liste de partage du dossier) par PUT /rest/config, après sauvegarde de la configuration complète. Elle subsiste sur les autres appareils (Xiaomi, PCNexte, SM-T720, Jux_Ubuntu, NAS), où elle apparaît hors ligne : à retirer à la main sur chacun.

Piloter Syncthing depuis Claude

Il n'y a plus de MCP Syncthing. Le script mcp_syncthing.py ne vivait que dans C:\Users\eliob\.claude\, hors périmètre Syncthing — il a disparu avec le profil. Passer par l'API REST directe, qui couvre tout ce que faisait le MCP.

Authentification : en-tête X-API-Key. Base VPS : https://syncthing.juxjux.ovh/rest. Base locale Windows : http://127.0.0.1:8384/rest.

Besoin	Appel
Configuration complète	`GET /config` — et `PUT /config` pour la remplacer
Appareils connectés	`GET /system/connections`
Dernier contact par appareil	`GET /stats/device`
État d'un dossier	`GET /db/status?folder=afltj-njyuy`
Divergences locales	`GET /db/localchanged?folder=afltj-njyuy`
Appareils en attente d'acceptation	`GET /cluster/pending/devices`
Modifier un dossier	`PATCH /config/folders/{id}`
Identité de l'instance	`GET /system/status` → `myID`
Lancer un scan	`POST /db/scan?folder={id}`

Appairer un appareil sans toucher à l'interface : ajouter l'entrée dans devices et dans la liste devices du dossier, puis PUT /rest/config. C'est ainsi que « PC-Julien 08/2026 » a rejoint le maillage. L'appareil distant doit toutefois accepter le nouveau venu de son côté, sauf si un appareil introducer s'en charge.

Points de vigilance

Aucune alerte en cas de décrochage. Un appareil peut rester des jours hors du maillage sans que rien ne le signale — c'est ce qui s'est produit ici du 2026-08-07 au 2026-08-10. Le seul contrôle fiable est GET /stats/device sur le VPS.
NAS SASNEXTE n'a plus donné signe de vie depuis le 2026-01-30. À diagnostiquer.
L'interface web du poste Windows n'a ni utilisateur ni mot de passe. Sans danger tant qu'elle n'écoute que sur 127.0.0.1 ; à corriger si le port venait à être exposé.
UPnP saturé sur la Livebox (PinholeSpaceExhausted dans les journaux) : sans conséquence, la connexion sortante TCP vers le VPS suffit.
Ne pas confondre le nom du projet compose et celui du service : la stack s'appelle 33, pas syncthing. Pour un redéploiement : docker compose -p 33 -f /var/lib/docker/volumes/portainer_data/_data/compose/33/docker-compose.yml up -d.