Exactly that work not for me. I dont know why, the difference is, that I use after the installation my old dataset from the “normal” installation, it means done without MSI.
I guess your “non msi driven old config” has updates disabled or the web ui just displays updates as disabled because the firewall blocks outgoing requests to “releases.syncthing.net”.
After you import your old settings you have those settings in place - no matter what the MSI got as properties. The MSI fires a one-shot batch script which updates the config and the script will not run again when you for example stop the service, copy over your old config and start the service. Just one thing: If the MSI script set STNOUPGRADE env, it will block upgrades because it’s still there - no matter what you have in your old config.xml .
I’d advice you do this:
- Uninstall MSI
- Delete all files in c:/server/syncthing/appdata to start over from scratch (I expect you have backuped your files already!)
- Copy your “old” config to …/appdata
- Edit the MSI to say “STNOUPGRADE”=0
- Install MSI.
It should modify your config to enable auto upgrades (Windows env vars, config.xml).
off topic: I think it a little bit misleading if Syncthing is configured to allow upgrades and it displays “upgrades disabled by admin/packager” when the update url returns http 403. noticed this in my tests a while ago. Better would be to read “Upgrade server unreachable”
1 Like
In the config.xml was standard parameters and in that way also automatic updates enabled.
Regarding your advice, I doe also that way. Finally I imagine, that also in the database maybe are informations about parameters.
that also in the database maybe are informations about parameters.
I don’t think Syncthing records the upgrades enabled/disabled in the database from what I’ve read so far.
@Andy I’ve created a new Syncthing instance for testing purposes without the MSI. It shows this DB content “as raw”.
So the upgrade info is somehow present in the DB, but I think that is for coordinating schema upgrades and not relevant to your problem described above.
It could at least explain the behavior as observed. Nevertheless, it would not be entirely plausible because after the installation I exchanged the complete settings directory together with the database for the previous version in which the automatic upgrade was activated.
That’s why I came across the registry, as it was independent of it. But it also seems to me that there are other entries of STNOUPGRADE besides
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\The Syncthing Authors\Syncthing
I found e.g.
Computer\HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Session Manager\ Environment
Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment
I don’t know if they have any influence. However, it appears to be typically backup entries from Windows.
Maybe you could do it differently. By definition, an MSI is an installer package with no optional features. Wouldn’t it make more sense to make an EXE in which various installation options can be selected?
This is your Windows environment. E.g. run “systempropertiesadvanced.exe” from the start menu, you can click the last button “environment variables” on the dialog to edit them manually without requiring REGEDIT. Remove STNOUPGRADE “plus” a config.xml where upgrades are enabled and you’re good to go.
The database records the schema version and minimum version required to open it, as Catfriend1 guessed. It does not store anything at all related to enabling or disabling upgrades.
1 Like
On my Windows systems the MSI package is installed in
C:\Server\Syncthing\
and the database are in the subfolder there
C:\Server\Syncthing\AppData\index-v0.14.0.db
If I want to run a CLI command, e.g.
C:\Server\Syncthing\syncthing.exe -reset-deltas
not the above data folder is used, instead a folder from the official version is used
C:\Users\>user<\AppData\Local\Syncthing\index-v0.14.0.db
What is instead the right command to run syncthing.exe -reset-deltas?
Same way as you otherwise start it, just adding -reset-deltas if that’s what you want.
I need to check this to be sure… Normally the MSI sets up Syncthing to run under the LocalService account. You could try adding the “config dir” (see docs for exact param name) switch to point at the c:/server/syncthing/appdata directory and ensure your administrative (or user) command prompt has access to this directory by setting NTFS ACL accordingly. I should maybe bundle a batch script to do this so one in the need of this does not have to know all this background.
@Andy I’ve made a maintenance batch called “syncthing_cli.cmd”, bundled in the next MSI release.
Here’s a screenshot how to use it, I think it’s pretty self-explanatory. For nice look, I’ve also added a logtail so you can see whats going on with Syncthing running under LocalService. This way, running Syncthing.exe as LocalService (just as nssm would do it) for one time shot CLI commands, you don’t need to bother with granting permissions to Syncthing’s config directory. If you’d like to exit the one-shot, please go to Syncthing’s Web UI and choose Actions > Shutdown.
From administrative command prompt:
C:\Server\Syncthing>syncthing_cli.cmd --reset-deltas
2021-05-18_11:04:02: [INFO] regQueryToVar: Got SERVICE_ACCOUNT=[NT AUTHORITY\LOCALSERVICE]
2021-05-18_11:04:02: [INFO] Stopping service: Syncthing
2021-05-18_11:04:02: [INFO] Stopping process: syncthing.exe
2021-05-18_11:04:02: [NT AUTHORITY\LOCALSERVICE] Exec via task scheduler: syncthing --reset-deltas
ERFOLGREICH: Die geplante Aufgabe "Syncthing" wurde erfolgreich erstellt.
ERFOLGREICH: Es wurde versucht, die geplante Aufgabe "Syncthing" auszuführen.
2021-05-18_11:04:02: [INFO] Waiting for task to finish ...
A window with the log pops up (which is NOT syncthing.exe but powershell):
As you can see, the command “–reset-deltas” was picked up, see log row “INFO: Reinitialiazing delta index IDs”.
Now, I execute Actions > Shutdown.
EDIT: New release is up containing “syncthing_cli.cmd”.
First time I installed a modified version of MSI, that the package can run internal updates. If I install a newer version of MSI, such settings are lost or not?
If you directly modified the package with Orca, just modify it again. Basically, the first time setup routine will not run on upgrades so modifying the MSI is just necessary for new installations.
This issue brings me back to my request
as an “internal” feature to be platform independent. I have similar issues with Linux Mint and my Synology servers. Would that be possible to implement?
1 Like
Maybe the same possibility here.
That possibility seems no longer to work
I installed Windows 11 and also a new MSI and I modified the newest MSI v1.18.2 with Orca, but I can´t set the update feature as known
Maybe is a better way to implement a feature I can chosse during installation.
1 Like
Is a comment possible?
You should clarify what you are looking a comment on, given this thread is quite lenghty.
I’ll take a look, but currently I’m busy with some large deployment of something else. Maybe check if the setx env vars are set correctly on win11 by the installer!?