Rescan interval of 0

Quick question, if the rescan interval for a folder is set to 0, then it only scans on startup and if you manually initiate a scan. Is there anyway to disable the scan on startup? Such as a command line option, -no-scan or something like that.

Reason being, some machines I want to be strictly manual. If I want to do an update but keep the database the way it is so I can compare manually, I’d like to do so without the update restart causing a rescan. Leaving the control in my hands, whether they are capable or not :stuck_out_tongue:

1 Like

Currently, no. Syncthing can’t really do its job unless it can perform scans. It can’t sync files if it doesn’t know the current state on disk. Are you looking for rsync instead?

Nah, rsync is nice. But syncthing is strides better. A cryptographically secure mechanism for syncing. A single protocol that exposes only filesystem commands. Predictable authentication based on certificates. These are important things to me.

Syncing two machines with rsync is either over SSH or rsync. Rsync isn’t encrypted, and SSH gives access to a full shell. Also, to automate syncing with rsync over SSH, you need to either store the key’s passphrase in the script, or create keys without a passphrase. No thanks.

With these criteria, I’d much rather round out the edges to this square peg to fit in the round holes. Square peg as it might be, it’s beautiful in all the ways that count.

So if it can’t skip the scan on startup, I’ll find a way to work it as needed. Thanks again for a wonderful solution to my quirkiness.


SSH doesn’t have to offer a shell. You can configure the remote end to only run a specific command (such as the rsync receiver) when you connect with your key. The man page for authorized_keys (8) has information on how to do this.

With this method, you can also restrict the filesystem access of rsync on the remote.

Using a passphraseless SSH key that is restricted on the remote end to only run rsync over a particular directory would require you to expose less than with Syncthing, since the Syncthing “key” is not restricted to any particular remote directory but rather allows access to anything that Syncthing can read or write to.

Comparing the two methods, it comes down to controlling access to either:

  1. the remote authorized_keys file and the local rsync invocation
  2. both ends’ Syncthing configuration files

Just some more information to help you make your choice…

Plus, you can make your ssh daemon spawn a docker container only with that directory mounted at root with no privileges.

Thank you for this. I have never seen it be done this way. For one specific subset of requirements, the restricted rsync method may fit better. For my other use case, I was wanting to do sync at a specific time.

My thought process was to use a scheduled task to launch a powershell script. Powershell would then launch the syncthing utility. Syncthing would check my private syncthing repository for an update ( that I curate and make available ). If there is an update, apply it and restart. Then start up again. Then I was hoping to be able to kick off the /rest/db/scan. Continue to monitor the scan progress via /rest/db/completion. Once the return is “100” 5 times in a row 60 seconds apart, then /rest/system/shutdown. Something like that. I am using windows and currently using Synctoy. I don’t like how the client scans the remote to see what files are there. Takes too long. Much better to have the remote do its own scans and provide diffs.

Within that scenario, I was hoping to be able to control when the scan started. Make things as predictable as possible. This leads me to the question: if syncthing is set to check for upgrades automatically, does it do so at startup? If so, does it postpone the initial scans of folders until the upgrade procedures have finished?

It does the upgrade in the backgroud, and it will upgrade regardless what it’s doing. I still think rsync/unison is a better tool for your usecase.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.