Installs the appropriate 32-bit or 64-bit version of Syncthing using a single installer
Supports administrative (all users) and non administrative (current user) installation
When installing for all users, installs Syncthing as a Windows service using NSSM
When installing for the current user, supports creating a scheduled task that starts Syncthing at logon
Supports adding a Windows Firewall rule
Supports silent (hands-free) installation
New in 1.19.2: For improved security, administrative (all users) installation mode now runs the Windows service using a local account (SyncthingServiceAcct by default). This necessitated a move of the Syncthing configuration folder to the CommonAppData\Syncthing folder (e.g., C:\ProgramData\Syncthing). (If you are upgrading an administrative installation from an older version, no extra steps are needed as Setup automatically migrates the configuration folder for you.)
Problems with this installer? Please file an issue on the issues page.
One question: How does it handle SyncTrayzor (or better: Does it cover SyncTrayzor at all)? SyncTrayzor comes with its own Syncthing installation in a different dir than a raw Syncthing (and it also updates this one). It also has an option to launch Syncthing on login. Of course it would be great to only have one version of Syncthing, all done in one installation.
This installer is a separate project. As I understand it, SyncTrazor is a per-user install only, whereas this project (Syncthing Windows Setup) supports both per-machine and per-user installs. This project’s per-user installation includes no “extra” software (just Syncthing and automatic configuration of launching, etc.).
and somewhere there is also such a path for SyncTrazor.
Back up the contents completely and uninstall or stop SyncTrazor and install Syncthing Windows Setup. This data path also exists for this installation. Then stop the new installation, delete the data path contents. Then copy all over from the previous installation, above example, to the new folder, start the new Syncthing again and everything should work as before.
It might also be worth mentioning that the user “SyncthingServiceAcct” receives the appropriate rights in the corresponding sync directories, then it works perfectly …
That is correct. This is noted in the documentation:
After upgrading from version 1.19.1 or older, you must follow the steps in Granting Folder Permissions for the Service Account to grant the local service user account permission to each synchronized folder in your Syncthing configuration. Until you do so, the Syncthing GUI configuration page will report “access denied” errors because the local service user account does not have “Modify” permissions to the folder(s).
Sorry, I don’t understand your question. Automatic updates can occur if the local service user account has “Modify” permissions on the installation folder. If you manually modified the installation folder’s permissions, this can break the automatic update process. A reinstall should correct the permissions.
This means that I have not changed the permissions in the program directories and in this areas all is still installed by default during setup of Windows 10.
Unfortunately I don’t have access to this Windows 10 computer at the moment, at the moment I have a Windows 11 PC in whose program directories no local service appears as an authorized user. The SyncthingServiceAcct as user would also have to be stored there.
What does “in whose program directories no local service appears as an authorized user” mean? (Services are not users, but they do run using a user account.)
What does “The SyncthingServiceAcct as user would also have to be stored there” mean? Stored where? (User accounts are stored in the SAM [Security Account Manager] database.)
If you are asking why you are getting access denied errors: This is because the service now runs using the SyncthingServiceAcct user instead of LocalService like before. This means that if you are running the service and you previously granted access to LocalService, that won’t work because the service now runs as SyncthingServiceAcct instead. As noted in the documentation, you must grant the SyncthingServiceAcct account access to the folders you want to sync (this is a manual step; the installer does not do this part for you).
FWIW I just tested an install of 1.19.2 on a Windows 11 machine, and the service works exactly as expected, and I saw the same access denied errors, so I had to go to each folder using the file explorer and update the permissions to give access to SyncthingServiceAcct instead of LocalService. All indications are that the installer works exactly as documented and expected.
Yes, this issue is discussed in the documentation in the section titled Upgrading Administrative Installations from Version 1.19.1 or Older. Here is a quote from there:
After upgrading from version 1.19.1 or older, you must follow the steps in Granting Folder Permissions for the Service Account to grant the local service user account permission to each synchronized folder in your Syncthing configuration. Until you do so, the Syncthing GUI configuration page will report “access denied” errors because the local service user account does not have “Modify” permissions to the folder(s).
As the documentation says, this is normal: You will get “access denied” errors until you give the local service user account permissions to the folders in your Syncthing configuration.
