Ich benutze Syncthing schon eine Weile, um meine Arbeitskopie mit einem lokalen Dev-Server zu synchronisieren, genauer gesagt seit ein paar Monaten.
Anfangs habe ich es genutzt, indem ich mich eingeloggt und es manuell über die CLI gestartet habe. Das lief gut, also habe ich mir keine weiteren Gedanken gemacht, als ich es auf den Betrieb als Service umgestellt habe. Es startete, es synchronisierte ein paar Daten, alles war in Ordnung.
Bis es das natürlich nicht mehr war! 🙂
Wie sich herausstellte, hatte ich eine ganze Reihe von Fehlern in den Logs übersehen, die besagten, dass das Dateisystem auf dem Dev-Server schreibgeschützt ist, und deshalb synchronisierte Syncthing überhaupt nichts.
Ich dachte, es wäre ein Bug und es würde bei den Ordnern nur Out of Sync anzeigen, aber eigentlich würde es synchronisieren. Tja, falsch gedacht.
Nach ein paar Stunden Debugging und ein paar Google-Suchen, bei denen ich in den Foren absolut keine Hinweise fand, landete ich bei einem Syncthing-Artikel im ArchWiki, der genau meinen Fall beschrieb:
read-only file system error on /etc although run as root
Das war exakt mein Anwendungsfall, nur dass der problematische Ordner nicht /etc war, sondern /usr/local/src.
Nach dem Lesen stellte sich heraus: Wenn man Syncthing (oder irgendetwas anderes) über systemd laufen lässt und für den Service ProtectSystem auf full gesetzt ist, werden standardmäßig einige Verzeichnisse schreibgeschützt. /usr ist eines dieser Verzeichnisse.
Um das zu beheben, muss man in der Service-Konfiguration eine neue Zeile hinzufügen und den Service neu starten (und daemon-reload ausführen):
ReadWritePaths=/usr/local/src
Danach sollte Syncthing einwandfrei funktionieren.