Syncthing 2.1.3: Mehr Ordnung, weniger Ballast

Was Syncthing 2.1.3 tatsächlich liefert

Syncthing 2.1.3 wurde am 5. August 2026 veröffentlicht. Das klingt zunächst nach einem kleinen Wartungsschritt, doch die Release-Seite verbindet den Patch mit den wichtigsten Änderungen der 2.1-Linie. Für Self-Hoster und Administratoren ist das nützlich: Sie bekommen nicht nur Fehlerkorrekturen, sondern mehrere Stellschrauben für Übersicht, Netzwerkzugang und Ressourcenverbrauch.

Die offizielle Liste ist konkret. Sie umfasst elf als Fixes geführte Änderungen, fünfzehn weitere technische Anpassungen und vier neue Mitwirkende. Unter den Fixes finden sich ein möglicher Deadlock rund um Datenbankverbindungen und Puller-Parallelität, ein korrigierter Health-Check für aktuelle Ordner, robustere Ignore-Patterns und mehrere Absicherungen gegen leere oder unerwartete Eingaben.

Die Zahl der Einträge sagt allerdings nichts über die Wirkung in Ihrer Umgebung aus. Ein korrigierter Randfall kann wichtiger sein als mehrere Optimierungen, die Ihr Setup nie berühren. Deshalb sollten Sie das Release nicht als pauschales Leistungsversprechen lesen, sondern als Anlass für einen kontrollierten Test mit Ihrer Konfiguration, Ihren Ordnergrößen und Ihren Netzwerkwegen.

Die maßgebliche Quelle bleibt die offizielle Release-Seite von Syncthing 2.1.3. Dort stehen auch die einzelnen Pull Requests und das vollständige Changelog. Damit lässt sich vor einem Upgrade prüfen, ob eigene Workarounds oder bekannte Probleme betroffen sind.

Notieren Sie vor dem Rollout außerdem Ihre Ausgangsversion und die aktuell gesetzten erweiterten Optionen. Nur mit dieser Basis lässt sich später unterscheiden, ob ein beobachteter Unterschied aus dem Programmupdate, einer gleichzeitig geänderten Konfiguration oder einem ohnehin anstehenden Scan stammt. Diese kleine Inventur spart mehr Zeit als ein hektischer Vergleich nach dem Update.

Gruppen bringen Ruhe in große Installationen

Wer zwei Rechner und einen Ordner synchronisiert, braucht kaum zusätzliche Ordnung. Anders sieht es bei einem Heimlabor, mehreren Familiengeräten oder einer kleinen Firmeninstallation aus. Mit der 2.1-Linie können Geräte und Ordner über das neue Attribut group in der Weboberfläche zusammengefasst werden. Die Gruppennamen sind lokal, lesbar und beschreibend.

Das ist bewusst eine Darstellungsfunktion. Eine Gruppe verändert keine Berechtigung, keine Freigabe und keine Synchronisationsbeziehung. Sie schafft lediglich Struktur in der GUI. Genau diese Trennung ist wichtig: Ein Ordner in der Gruppe „Archiv“ erhält dadurch weder einen anderen Schutzstatus noch eine andere Versionsstrategie. Operative Regeln bleiben an den eigentlichen Ordner- und Gerätekonfigurationen hängen.

Die offizielle Konfigurationsdokumentation erlaubt, dass Gruppennamen auf jedem Gerät unterschiedlich, leer oder mit anderen Gruppen identisch sind. Sie können eine Installation daher nach Standort, Zweck oder Verantwortungsbereich sortieren, ohne dieselbe Ansicht auf alle Teilnehmer zu zwingen.

Für die Einführung empfiehlt sich ein schlichtes Schema. Beginnen Sie etwa mit „Produktiv“, „Archiv“ und „Test“ oder mit eindeutigen Standorten. Vermeiden Sie Namen, die eine technische Sicherheitseigenschaft vortäuschen. „Verschlüsselt“ als Gruppenname wäre missverständlich, wenn die zugrunde liegende Ordnerkonfiguration diese Aussage nicht trägt.

Erstellen Sie vor der Gruppierung eine kurze Liste aller Geräte- und Ordnernamen. Doppelte Anzeigenamen, ausgemusterte Knoten und pausierte Freigaben werden in einer hübsch sortierten Oberfläche sonst nur besser versteckt. Bereinigen Sie erst das Inventar und gruppieren Sie danach. So bleibt die GUI eine verlässliche Betriebsansicht statt einer kosmetischen Ablage.

CONNECT-Proxys öffnen einen kontrollierten Netzwerkweg

Syncthing unterstützte bereits SOCKS-Proxys. Neu hinzu kommen HTTP- und HTTPS-Proxys, sofern sie die CONNECT-Methode unterstützen. Das erweitert die Einsatzmöglichkeiten in Netzen, in denen ausgehende Verbindungen nicht direkt erlaubt sind, sondern einen zentralen Proxy passieren müssen. Die Release-Information nennt dafür ausdrücklich auch die Umgebungsvariable all_proxy=https://….

CONNECT baut einen Tunnel durch den Proxy auf. Das bedeutet nicht, dass jede Unternehmensrichtlinie automatisch erfüllt ist. Authentifizierung, erlaubte Ziele, Zertifikatsprüfung und Protokollierung hängen weiterhin von Proxy und Umgebung ab. Prüfen Sie deshalb nicht nur, ob eine Verbindung zustande kommt, sondern ob sie dem vorgesehenen Netzwerkpfad folgt und nach einem Neustart reproduzierbar bleibt.

Ein sauberer Test trennt drei Fälle: direkte Verbindung, bisheriger SOCKS-Weg und neuer HTTP- beziehungsweise HTTPS-CONNECT-Weg. Dokumentieren Sie, welche Umgebungsvariable der Dienst tatsächlich erhält. Bei systemd, Containern oder NAS-Paketen reicht es nicht, eine Variable in einer interaktiven Shell zu setzen; sie muss im Kontext des laufenden Syncthing-Prozesses ankommen.

Verwechseln Sie Proxy-Unterstützung außerdem nicht mit einem Relay. Der Proxy ist ein kontrollierter Ausgang aus Ihrem Netz, während Syncthing-Relays eine andere Rolle bei der Verbindung zwischen Geräten übernehmen. Wenn Ihr Setup bisher nur über Umwege funktionierte, sollten Sie nach dem Wechsel die beobachteten Verbindungsarten in der GUI und in den Logs prüfen.

Planen Sie auch den Fehlerfall. Ein nicht erreichbarer Proxy, eine abgelaufene Anmeldung oder eine restriktive CONNECT-Zielliste muss in Logs und Monitoring erkennbar sein. Halten Sie fest, wie Sie kurzfristig auf den bisherigen Pfad zurückwechseln, ohne mehrere Variablen gleichzeitig zu ändern. Ein dokumentierter Rückweg gehört zu jedem Netzwerkumbau.

Blockindizierung wird zur bewussten Abwägung

Eine der technisch interessantesten Neuerungen ist blockIndexing. Syncthing kann die Blockindizierung für einzelne Ordner abschalten. Laut offizieller Beschreibung ist das für Fälle gedacht, in denen eine kleinere Datenbank und weniger Overhead wichtiger sind als eine möglichst geringe Transfermenge.

Der Zielkonflikt ist klar: Mit Blockinformationen kann Syncthing Änderungen feiner erkennen und unnötige Übertragungen vermeiden. Ohne diese Informationen sinkt der Aufwand für die lokale Datenhaltung, dafür kann mehr über das Netz gehen. Welche Seite wichtiger ist, hängt von Dateitypen, Änderungsmustern, Speicher und Bandbreite ab. Die Dokumentation nennt keine pauschalen Prozentwerte, also sollte auch Ihre Entscheidung nicht auf erfundenen Einsparungen beruhen.

Geeignete Kandidaten für einen Versuch sind klar abgegrenzte Ordner, deren Verhalten Sie beobachten können. Ändern Sie nicht alle Freigaben gleichzeitig. Wählen Sie einen unkritischen Ordner, erfassen Sie Datenbankgröße, Scanverhalten und übertragenes Volumen vor und nach der Umstellung und behalten Sie dieselbe Dateilast bei. Erst dann lässt sich beurteilen, ob der geringere lokale Aufwand den möglichen Mehrtransfer rechtfertigt.

Für knappe Systeme kann diese Option attraktiv sein, etwa auf kleinen Servern oder Geräten mit begrenztem Speicher. In Netzen mit teurer, langsamer oder volumenbegrenzter Verbindung kann dagegen die minimale Transfermenge wichtiger bleiben. Syncthing 2.1.3 nimmt Ihnen diese Entscheidung nicht ab; es macht sie lediglich pro Ordner konfigurierbar.

Definieren Sie vor dem Versuch eine Rückkehrbedingung. Steigt der Transfer sichtbar an oder verlängert sich ein typischer Abgleich, setzen Sie die Option für diesen Ordner zurück und lesen den Zustand erneut aus. Ohne vorher festgelegte Kriterien wird aus einem Test schnell eine dauerhafte Sonderkonfiguration, deren ursprünglicher Grund später niemand mehr kennt.

Dieses Bild wurde komplett mit KI generiert

Providerhiggsfield

Modellseedream_v4_5/high/2K

PromptAt a Linux server desk, an administrator compares two Syncthing folder configurations on a monitor, one with block indexing enabled and one disabled, beside a compact NAS with active network lights. The screen uses a clean readable settings panel and a simple transfer-flow graphic to show the trade-off between database overhead and network traffic without inventing benchmark numbers. Photorealistic style image. Mood: deliberate, analytical, and resource-conscious. Avoid: watermark, signature, blurry, low quality, distorted, deformed.

GUI-Sitzungen brauchen eine klare Sicherheitsregel

Die Login-Sitzung der Weboberfläche lässt sich über sessionCookieDurationS anpassen. Der dokumentierte Standard beträgt eine Woche. Administratoren können die Dauer verkürzen, verlängern oder auf unbegrenzt setzen. Zusätzlich lässt sich mit sessionCookiePath der Cookie-Pfad verändern.

Mehr Komfort ist nicht automatisch die bessere Wahl. Eine unbegrenzte Sitzung spart wiederholte Anmeldungen, verlängert aber auch den Zeitraum, in dem ein vorhandenes Sitzungscookie nutzbar bleibt. Auf einem gemeinsam verwendeten Rechner oder einer nicht ausreichend geschützten Admin-Station ist das eine unnötige Angriffsfläche. Eine kürzere Dauer verlangt mehr Logins, begrenzt dafür die Lebenszeit der Sitzung.

Setzen Sie die Dauer passend zum Zugriffspfad. Eine nur lokal erreichbare GUI auf einem dedizierten Administrationsgerät hat ein anderes Risikoprofil als eine Oberfläche hinter Reverse Proxy, VPN oder zentralem Zugangssystem. Prüfen Sie nach Änderungen, ob Anmeldung, Abmeldung und Ablauf wie erwartet funktionieren. Ein konfigurierbarer Cookie-Pfad ist besonders dann relevant, wenn mehrere Anwendungen unter derselben Domain oder einem gemeinsamen Proxy-Pfad betrieben werden.

Die neue Flexibilität ersetzt keine Grundhygiene. Beschränken Sie die Erreichbarkeit der GUI, verwenden Sie starke Zugangsdaten und halten Sie den administrativen Browser sauber. Die Release-Notiz verspricht keine zusätzliche Sicherheitswirkung; sie gibt Ihnen lediglich mehr Kontrolle über die bestehende Sitzungspolitik.

Testen Sie nicht nur den positiven Login. Öffnen Sie eine Sitzung, melden Sie sich gezielt ab, starten Sie den Browser neu und prüfen Sie anschließend den konfigurierten Ablauf. Bei einer verkürzten Dauer sollte ein abgelaufenes Cookie tatsächlich eine neue Anmeldung verlangen. Bei einem geänderten Pfad darf es nicht versehentlich für andere Anwendungen gelten.

So führen Sie das Update kontrolliert ein

Vor dem Update auf Syncthing 2.1.3 sichern Sie Konfiguration und Datenbankverzeichnis entsprechend Ihrem Installationsweg. Prüfen Sie anschließend die Release-Seite auf Änderungen, die Ihre Plattform betreffen. Ein kontrolliertes Basissystem ist dabei ebenso wichtig wie der Anwendungspatch; der Debian-Upgrade-Leitfaden für Self-Hoster zeigt das Prinzip für die Betriebssystemebene. Dazu gehören in diesem Patch unter anderem Android-amd64-Unterstützung für inotify, geschlossene HTTP-Verbindungen sowie Optimierungen bei Umbenennungserkennung, fsync-Aufrufen und casefs-Caching.

Führen Sie das Update zuerst auf einem weniger kritischen Knoten aus. Kontrollieren Sie, ob alle erwarteten Ordner und Geräte erscheinen, keine unerwarteten Rescans starten und die Verbindungsarten plausibel bleiben. Wenn Sie Gruppen verwenden, testen Sie nur die Darstellung. Wenn Sie Proxy, Blockindizierung oder Sitzungsdauer ändern, behandeln Sie jede Option als eigenen Konfigurationsschritt mit separatem Readback.

Mehrere Fixes zielen auf robuste Fehlerbehandlung: leere API-Pfade, ungültige leere Versioner-Kommandos, Ignore-Patterns mit leerem Ergebnis und Zugriffe außerhalb eines gültigen String-Index. Besonders relevant ist die verbesserte Behandlung von Datenbankverbindungen und Puller-Parallelität, die einen Deadlock vermeiden soll. Das sind gute Gründe für ein Update, aber kein Ersatz für Ihre eigenen Betriebschecks.

Erfassen Sie nach dem Rollout die aktive Version, den Zustand aller Ordner und die vorgenommenen Konfigurationsänderungen. Syncthing 2.1.3 liefert sinnvolle Werkzeuge für größere und stärker kontrollierte Installationen. Der Gewinn entsteht jedoch erst, wenn Gruppen nur ordnen, Proxywege dokumentiert sind, Blockindizierung bewusst gewählt wird und GUI-Sitzungen zu Ihrem tatsächlichen Zugriffsmodell passen.

Beobachten Sie den Knoten mindestens über einen vollständigen regulären Synchronisationszyklus. Prüfen Sie Warnungen, wiederholte Verbindungsaufbauten, Datenbankaktivität und ungewöhnlich lange Scans. Wenn der Testknoten stabil bleibt, rollen Sie das Update schrittweise weiter aus. So bleibt im Fehlerfall immer ein bekannter Vergleichsknoten mit der vorherigen Version verfügbar.