Syncthing - Receive Only Folders

Jakob Borg

In Syncthing v0.14.50 we’re adding the initial implementation of “receive only” folder types. This makes the set of folder types the complete trio - send only, receive only, and the default send-plus-receive. This has been an oft requested feature for quite some time but nailing down the exact mechanics of how it was supposed to work has been a bit tricky.

There are many different expectations on how this type of folder should work and some of them have been incompatible with Syncthing core values. First and foremost we do not want to automatically undo changes a user makes to their files.

The current implementation is sort of the “minimum viable” one - as little as possible to be able to check the feature checkbox. This is intentional because we’re not really sure how it will be used in practice, and it allows us room for further enhancement in the future.

In short, a receive only folder will not prevent the user on that device from making changes to files and it won’t automatically, immediately, undo any such changes. It will however avoid sending the changes to the rest of the Syncthing cluster, and it gives the user an option to undo local changes manually.

We think receive only folders will work well for people using Syncthing as a component in their content distribution or backup solution. It prevents mistakes at the individual client level from propagating onwards while still allowing the individual user control over their files.

Footnote, sort of: if you really want to immediately undo any local changes, stick this script in your crontab to run every few minutes. Replace the host, API key and folder ID as appropriate. It checks the API for changes to the folder and does a revert when there are changes.


if ! curl -skH "X-API-Key: $apikey" "$host/rest/db/status?folder=$folder" \
  | grep -q 'receiveOnlyChanged.*": [1-9]' ; then
  exit 0

curl -X POST -skH "X-API-Key: $apikey" "$host/rest/db/revert?folder=$folder" | +46 (0)10-551 70 80
Malmö, Sweden

© 2014 – 2021 Kastelo Inc.