# 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

<table id="bkmrk-imagesyncthing%2Fsynct"><tbody><tr><th>Image</th><td>`syncthing/syncthing:latest`</td></tr><tr><th>Version</th><td>**v2.1.2** « Hafnium Hornet » (go1.26.5, build `noupgrade`)</td></tr><tr><th>Container</th><td>`syncthing` — <span style="color:#008000;">running (healthy)</span>, démarré le 2026-07-31</td></tr><tr><th>Politique de redémarrage</th><td>`unless-stopped`</td></tr><tr><th>Projet compose</th><td>**`33`** (l'ID de stack Portainer, pas `syncthing`)</td></tr><tr><th>Réseau</th><td>`33_syncthing_net`</td></tr><tr><th>URL</th><td>[https://syncthing.juxjux.ovh](https://syncthing.juxjux.ovh)</td></tr><tr><th>Clé API</th><td>`KWwkF5dD5CxeyGwFJ9ejFLHiohALysyF`</td></tr><tr><th>Device ID</th><td>`HKY4MM4-3ACZXNE-PVUUI6W-4MEYOR4-SYRXXHG-F4U6EPO-OWBDE62-ZBVHJQ3`</td></tr><tr><th>Source</th><td>[github.com/syncthing/syncthing](https://github.com/syncthing/syncthing)</td></tr></tbody></table>

### Ports

<table id="bkmrk-h%C3%B4tecontainerr%C3%B4le-83"><thead><tr><th>Hôte</th><th>Container</th><th>Rôle</th></tr></thead><tbody><tr><td>8384</td><td>8384/tcp</td><td>interface web / API REST</td></tr><tr><td>22000</td><td>22000/tcp + udp</td><td>protocole de synchronisation (BEP)</td></tr><tr><td>21027</td><td>21027/udp</td><td>découverte locale</td></tr></tbody></table>

### Volumes

<table id="bkmrk-source-%28h%C3%B4te%29destina"><thead><tr><th>Source (hôte)</th><th>Destination</th><th>Type</th></tr></thead><tbody><tr><td>*volume anonyme*</td><td>`/var/syncthing`</td><td>volume</td></tr><tr><td>`/home/debian/Documents`</td><td>`/var/syncthing/Documents`</td><td>bind</td></tr><tr><td>`/home/debian/Public`</td><td>`/var/syncthing/Public`</td><td>bind</td></tr><tr><td>`/home/debian/docker/syncthing/config`</td><td>`/var/syncthing/config`</td><td>bind</td></tr><tr><td>`/home/debian/docker/syncthing/data1`</td><td>`/var/syncthing/data1`</td><td>bind</td></tr><tr><td>`/home/debian/docker/syncthing/data2`</td><td>`/var/syncthing/data2`</td><td>bind</td></tr><tr><td>`/home/debian/joplin-data`</td><td>`/var/syncthing/joplin-data`</td><td>bind</td></tr></tbody></table>

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

---

## Le maillage

### Un seul dossier partagé

<table id="bkmrk-idafltj-njyuy-libell"><tbody><tr><th>ID</th><td>`afltj-njyuy`</td></tr><tr><th>Libellé</th><td>Tablette VPS Syncthing</td></tr><tr><th>Chemin VPS</th><td>`/home/debian/Documents`</td></tr><tr><th>Chemin Windows</th><td>`D:\Syncthing`</td></tr><tr><th>Type</th><td>`sendreceive`</td></tr><tr><th>Contenu</th><td>1 284 fichiers, 495 dossiers, 1 061 Mo</td></tr></tbody></table>

**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)

<table id="bkmrk-nomdevice-id-%28d%C3%A9but%29"><thead><tr><th>Nom</th><th>Device ID (début)</th><th>État</th><th>Dernier contact</th></tr></thead><tbody><tr><td>syncthing-vps</td><td>`HKY4MM4`</td><td>hub, toujours actif</td><td>—</td></tr><tr><td>PC-Julien 08/2026</td><td>`XLNMUWS`</td><td><span style="color:#008000;">connecté</span></td><td>2026-08-11</td></tr><tr><td>XIAOMI15Pro</td><td>`ITCNNE7`</td><td><span style="color:#008000;">connecté</span></td><td>2026-08-11</td></tr><tr><td>Jux\_Ubuntu</td><td>`Y3FSVEF`</td><td>hors ligne</td><td>2026-08-08</td></tr><tr><td>PCNexte</td><td>`QF2XTKM`</td><td>hors ligne</td><td>2026-08-07</td></tr><tr><td>SM-T720</td><td>`UUB72GL`</td><td>hors ligne</td><td>2026-07-23</td></tr><tr><td>NAS SASNEXTE</td><td>`SBLUVCW`</td><td><span style="color:#b00000;">hors ligne depuis 6 mois</span></td><td>2026-01-30</td></tr></tbody></table>

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)

<table id="bkmrk-machinedesktop-b7j2k"><tbody><tr><th>Machine</th><td>`DESKTOP-B7J2KGP`, utilisateur `julie`</td></tr><tr><th>Device ID</th><td>`XLNMUWS-P23BMTA-CJPC52K-VOS733O-YGBB2QF-GDA4EI6-YH7TZGP-FENRWA2`</td></tr><tr><th>Interface</th><td>**SyncTrayzor 2.2.0**, winget `GermanCoding.SyncTrayzor` — le fork maintenu</td></tr><tr><th>Home Syncthing</th><td>**`D:\SyncthingHome`**</td></tr><tr><th>Interface web</th><td>`http://127.0.0.1:8384` — clé API `PhAm5RvM9gJEzVEosHUWp9fPg2hKLhwr`</td></tr><tr><th>Démarrage</th><td>clé `HKCU:\…\CurrentVersion\Run`, entrée `SyncTrayzor -minimized`</td></tr></tbody></table>

### 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.

1. **Sauvegarder hors de l'arbre synchronisé** tout fichier modifié localement (voir plus bas).
2. Ajouter le dossier en **`receiveonly`** : l'état du maillage fait autorité, les divergences locales sont retenues sans être poussées.
3. Attendre `needFiles = 0` — ici 229 fichiers / 547 Mo rapatriés.
4. 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`.

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

**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`.

---

## ⚠ Syncthing n'est pas une sauvegarde — corrigé le 2026-08-30

Constat de départ : le dossier `afltj-njyuy` est en `sendreceive` avec **`versioning = AUCUNE`**(vérifié par `GET /rest/config/folders`, aucun `.stversions` sur le VPS). Syncthing fait de la **réplication** : une suppression ou un écrasement sur l'un des 7 appareils se propage partout en quelques secondes, sans retour arrière possible. Sept copies d'un fichier effacé font zéro copie.

Ce n'était pas théorique — c'est arrivé deux fois : le `CLAUDE.md` écrasé par le maillage le 2026-08-10, et les 308 suppressions provoquées par un simple renommage de dossier le 2026-08-28. **C'était le seul trou de l'architecture de sauvegarde** : les 6 services sauvegardés chaque nuit sont des bases de données, et `~/Documents` n'y figurait pas.

### Ce qui a été mis en place

Un septième service dans `/opt/backups/vps_backup.sh`(cron `0 2 * * *`), sur le modèle de `backup_baikal` : tar de `~/Documents` → `7z -mx=1` → upload vers le dossier kDrive `1485489`, rotation `documents_day{1-7}.7z`. **Plus une copie mensuelle** le 1er de chaque mois (`documents_month{01-12}.7z`, dossier kDrive `1486390`), qui donne une **année glissante** de recul. Sauvegarde du script avant modification : `/opt/backups/vps_backup.sh.bak-260830`. Le bilan de fin de log passe de `6/6` à `7/7`.

Deux garde-fous dans la fonction :

- **Contrôle d'espace sur `/tmp`** avant de commencer — l'incident du 2026-06-24 (disque à 100 %, tout le VPS à terre) est parti d'un fichier temporaire.
- **`tar` renvoyant 1 est traité comme un avertissement**, pas comme un échec : Syncthing peut écrire pendant la sauvegarde et `tar` signale alors « file changed as we read it ». Seul un code &gt; 1 fait échouer le service.

### Le périmètre, mesuré le 2026-08-30

Après le rangement fait par Julien le même jour (retrait de `APK temp`, des conflits de `komga-pdf`, et déplacement de `Suretés` vers le NAS), l'arbre est passé de **1,6 Go à 493 Mo**. Maillage cohérent : 1 267 fichiers des deux côtés, `needFiles = 0`, aucun `.stignore`.

<table id="bkmrk-dossierfichierstaill"><thead><tr><th>Dossier</th><th>Fichiers</th><th>Taille</th></tr></thead><tbody><tr><td>`Jux_univers`</td><td>609</td><td>380,5 Mo</td></tr><tr><td>`Ouvrages`</td><td>6</td><td>72,1 Mo</td></tr><tr><td>`Kobo`</td><td>1</td><td>34,4 Mo</td></tr><tr><td>`Jux_Obsidian`</td><td>649</td><td>3,2 Mo</td></tr><tr><td>`Vocaux`</td><td>1</td><td>2,9 Mo</td></tr><tr><td>`Alteris`, `PDF temps`, `komga-pdf`, `komga-compressed`</td><td>1</td><td>~0</td></tr></tbody></table>

**À retenir : 73 % de tout l'arbre Syncthing est le coffre Cryptomator « Vault 2603 »** — 513 fichiers `.c9r`pour 359,5 Mo, à l'intérieur de `Jux_univers`. Le reste de `Jux_univers` (Jux-scripts, Claude-pcelio+jux, 2026, EMOA) ne pèse que 6,2 Mo. Trier cet arbre par taille ne donne donc plus rien : le seul arbitrage réel est de savoir si le coffre reste ou non dans l'arbre répliqué. Décision de Julien le 2026-08-30 : **il reste**, et il en existe par ailleurs une copie sur kDrive.

Seules exclusions du `tar` : `.stfolder` et `.stversions`, qui sont des métadonnées Syncthing. Tout le reste est sauvegardé, y compris les dossiers de transit `komga-pdf`et `komga-compressed` — un PDF qui y attend son traitement n'existe nulle part ailleurs.

### Restauration — vérifiée, pas supposée

Une sauvegarde jamais restaurée n'est pas une sauvegarde. Test complet fait le jour même :

1. archive re-téléchargée depuis kDrive — attention, `curl -L` obligatoire, voir la page *A\_liens entre Claude et le KDRIVE* ;
2. `7z t` → *Everything is Ok* ;
3. tar extrait : **1 760 entrées**, et surtout `masterkey.cryptomator` bien présent — sans lui le coffre serait irrécupérable ;
4. un fichier témoin (`CLAUDE.md`, 151 849 octets) extrait puis comparé à la source : **identique à l'octet près**.

### Profondeur de rétention (2026-08-30)

Deux séries indépendantes, toutes deux sans purge — la suppression via l'API kDrive ne fonctionne pas, donc on se contente d'écraser un nom qui revient :

<table id="bkmrk-s%C3%A9rienomreculpoids-t"><thead><tr><th>Série</th><th>Nom</th><th>Recul</th><th>Poids total</th></tr></thead><tbody><tr><td>Quotidienne</td><td>`documents_day{1-7}.7z`</td><td>7 jours</td><td>~3,4 Go</td></tr><tr><td>Mensuelle</td><td>`documents_month{01-12}.7z`</td><td>1 an</td><td>~5,9 Go</td></tr></tbody></table>

Le tar est produit par une fonction commune `documents_tar()`. Le 1er du mois il est construit deux fois (~33 s de plus) : les deux séries restent ainsi indépendantes, un échec de l'une n'empêchant pas l'autre. Les autres jours, la fonction mensuelle sort en succès sans rien faire, pour ne pas inscrire un faux échec au bilan.

### Ce que cette sauvegarde ne couvre pas

- **Entre deux copies mensuelles, le recul retombe à 7 jours.**Un fichier créé le 5 puis supprimé le 20 n'apparaît dans aucune des deux séries : il n'a jamais existé un 1er du mois, et les 7 jours glissants l'ont déjà dépassé. C'est la limite structurelle d'une rotation par écrasement de nom, assumée ici.
- **Le versioning Syncthing reste désactivé.** Une corbeille (`trashcan`, 30 jours, via `PATCH /rest/config/folders/afltj-njyuy`) protégerait *immédiatement* contre une fausse manœuvre, là où la sauvegarde ne rattrape que ce qui existait à 2 h du matin. Non fait à ce jour.