The setup in brief
Brown keeps one shared folder in sync across four devices:
- a Windows desktop
- a Windows laptop
- an Ubuntu NAS
- an HTPC connected to a TV
The HTPC is set to receive-only, since all it does is play video files. Syncthing runs as a background service everywhere. On Windows he sees it as a taskbar icon. On the headless Ubuntu box, a systemd service starts it at boot. He says he hasn't had to reconfigure anything since the initial setup.
Everything above is one admin's firsthand experience. It isn't a benchmark, and it doesn't guarantee that every network will behave the same way. He gives no Syncthing version, no Windows build, and no transfer measurements.
How Syncthing moves files, and where "like rsync" goes wrong
Brown says Syncthing uses the same delta-transfer method as rsync. The official documentation doesn't describe it that way. Syncthing uses its own block-based approach, as its synchronization documentation explains.
Files are split into blocks of 128 KiB to 16 MiB, depending on file size. Each block gets a SHA-256 hash. To update a file, Syncthing compares the block list of the current version with the block list of the desired one. It then fetches only the blocks that differ, either by copying a matching block already on disk or by requesting it from another device.
So the practical claim holds: appending to a large file doesn't force a full re-transfer. Two caveats apply:
- The documentation says it's impossible to know which parts of a file changed without reading the file and computing new hashes for each block. Detection still costs disk reads.
- Changes aren't instant. The filesystem watcher batches changes for about 10 seconds, deletions wait about a minute longer, and by default a full scan runs hourly. A short delay before a file shows up elsewhere is expected behavior.
Relays and privacy: "end-to-end encrypted" isn't the whole story
For devices that aren't on the same network, Brown says Syncthing uses relay servers and that there's no risk of them snooping. The first half needs a qualifier, and the second half is true only for file contents.
The relay documentation says relays are a fallback, used only when two devices can't connect directly. Syncthing periodically retries a direct connection and drops the relay if one succeeds. The trade-off is that relayed transfers are much slower than direct ones.
On privacy, the contents of your files stay encrypted between your devices. But a device must register with a relay to be reachable through it, so the relay learns the device's IP address and device ID. It can also see how much traffic flows between devices. The security documentation adds that if two devices connect through a relay, it learns the other device's ID too.
Discovery has its own metadata trail:
- Global discovery is on by default. Devices announce their device ID and listening port to discovery servers, which can map device IDs to IP addresses. The documentation says the operator can deduce which devices connect to each other.
- Local discovery is also on by default. It broadcasts the device ID and port to the local network every 30 seconds. That is why Brown's LAN devices found each other instantly.
None of this exposes file contents. It does mean "no company's cloud" is not the same as "no third party sees anything." Readers who care can turn off global discovery or relaying, or point Syncthing at their own relay. The trade is that devices with dynamic addresses off the local network may no longer be reachable.
The HTPC and receive-only mode
Receive-only is a real, documented folder type. In this mode, changes from the cluster are applied and passed along, but local changes are not sent to other devices. That suits a playback box that should mirror a library and never originate edits.
The mode is a convention, not a lock:
- If someone modifies or adds a file on the receive-only device, Syncthing preserves it locally.
- The documentation says that device then looks out of sync on other devices, because it no longer has the expected version of the file.
- Syncthing shows a "Revert Local Changes" button. Using it deletes added files and re-syncs modified or deleted ones from the cluster.
- If a locally modified file is later changed by the cluster, the cluster version wins the conflict.
Brown's phrasing, that the HTPC "can't write changes," is a little stronger than the documentation. The accurate version is that it won't send its changes to the others.
Conflicts: both copies survive, but you still have to decide
Brown's few conflicts came from an offline device editing a file. The documentation describes the behavior. If a file is modified on two devices at once and the content differs, one copy is renamed to a .sync-conflict-<date>-<time>-<modifiedBy> name that keeps the extension. The copy with the older modification time becomes the conflict file. If the times are equal, the device ID breaks the tie. A modification competing with a deletion can also produce one.
Two details matter:
- Syncthing does not merge edits, and it can't judge which version you'd prefer. Manually reviewing both files, as Brown does, is the right workflow.
- Conflict files are treated as normal files after creation, so they propagate to other devices. Delete the loser everywhere it landed, and don't leave it lying around to confuse someone later.
Windows users also get a case-sensitivity wrinkle. Syncthing treats file.txt and FILE.txt as different files, while Windows can't hold both. If a Linux box like Brown's NAS ends up with both, the Windows machines will report a case conflict. You'll need to settle on one name by hand.
Sync is not backup
Brown says so himself, and it's the most important caveat here. Four synced copies are not four backups. A deletion or a bad edit propagates to peers like any other change. Syncthing offers file versioning, but you have to configure it, and it still isn't a substitute for a separate backup. Treat the NAS as a sync node unless you've set up snapshots or versioned copies for it.
Housekeeping for Windows users
- Protect the config and keys. The security documentation says anyone with access to Syncthing's TLS keys and config file can impersonate your device and reach your synced files. If you encrypt a laptop's disk against theft, keep the Syncthing config folder on that encrypted disk too.
- Revoke lost devices. If a device goes missing, remove it from your other devices.
- Check connectivity. Brown notes that firewalls and NAT rules can block devices from reaching each other. The default sync port mentioned in the security documentation is 22000.
- Expect default network chatter. Automatic upgrade checks are on by default, and the GUI asks once about usage reporting, which defaults to off.
Verdict
Brown's central point stands: once a peer-to-peer sync tool is configured, it can fade into the background. That suits people comfortable administering their own machines, especially those who already run a home lab. The trade-off is that you own the reachability, the conflict cleanup, the metadata choices, and the backups. His experience is real, but "zero maintenance" describes his network, not a guarantee for yours.