The problem is slightly more complex, and stems from two facts:
- Syncthing needs to be able to read and write the files it is synchronizing.
- By default, Syncthing can be configured by any user on the local machine.
These mean that, by default, any user on the local machine has access to any file which the user running Syncthing has access to.
If Syncthing is running as SYSTEM, then any user on the machine (including malware which hasn’t yet got administrative rights) can access virtually any file on the filesystem. That’s basically a rootkit. This is bad.
If Syncthing is running as LOCAL SERVICE, then by default it won’t have access to any files. Giving it access to files gives access to any process running as LOCAL SERVICE. This is bad. LOCAL SERVICE is meant to be a very restricted account.
Also remember that files created by Syncthing will be owned by the user Syncthing is running as. Having your files owned by a system or service account may or may not cause issues for you.
The only sensible thing to do when running Syncthing as a service is to run it as the user whose files you want to synchronize. This obviously makes the setup process a bit more complex, and makes multi-user setup a bit harder.
At the end of the day, starting Syncthing on login is a much more safe and user-friendly approach, particularly for new users. This is what all the major wrappers do.
All of this is explained in the docs, and there’s also this thread which is linked just a little further up in this thread.
(Setting a GUI password mitigates some of the issues listed above to a degree. However, 1) You’re now relying on there being no undiscovered vulnerabilities in Syncthing, 2) This isn’t particularly newbie-friendly, and 3) I saw no mention of the very pressing need to do this in @maxwelleite’s project instructions).