@camsam I’ve just released v1.0.6, which contains a 32-bit build. Could you let me know if it works? No hurry - I’ve got to get up in 4 hours so I’m going to hit the sack.
Just migrated over from NSSM - absolutely brilliant! And I think the file watcher functionality sounds compelling.
As we are in the middle of a cataclysmic event with BT Sync, I think it might be an opportune time to advertise this prominently on the main syncthing page, to capture the Windows users. (As it is now, I think they have to dig around on a wiki and investigate several options, and I am afraid we might lose some people if they aren’t tech savvy enough.)
1 Like
Any thoughts on supporting syncthing’s web GUI username/password? I created a feature request on github. I am thinking it may be nice to allow wrapper apps like this to log into the web GUI using the API Key (and a username of “APIKey” or something), so that they don’t have to store the web username/password.
So I guess the only missing feature is installing as a service, and service control.
I’ve replied on github, and opened an issue with Syncthing (#1420). If we can get some extra support in Syncthing for this, then fantastic. If not, we can just prompt the user.
EDIT: Fixed in code, will be in the next release (Monday? Tuesday? Sometime around then). I don’t want to release too often, as it causes a prompt to be raised for everyone who’s already installed it!
1 Like
I have reservations about installing as a service. My take on it is that Syncthing is an inherently user-level application. It synchronizes the user’s files, with the user’s permissions, using configuration from the user’s AppData. It therefore needs to be run at the user, when the user logs in. Running it with elevated (LOCALADMIN) permissions is just asking for trouble in all sorts of places: file permissions, security - you’ve just opened an attack vector for people to edit previously-uneditable files, someone erroneously trying to sync Program Files or C:\Windows, etc. I’m not prepared to accept that level of responsibility. Configuration is another aspect: per-user configuration becomes nie-on impossible, unless I’ve missed a trick.
On the flip side, running a service as a particular user kind of defeats the point of services, and doesn’t support multi-user computers (only the user the service is running as will be able to use Syncthing).
I think the ‘Install Syncthing as a service with NSSM’ craze started because a service is the most obvious way to start an application when the computer starts, assuming the original proponent forget about start-on-login.
If you can explain why those reservations are mis-founded, then I’m open to the possibility of installing a service. However this would take a while: I’d need to support tray utilities that both ran everything in one process (for the portable users - there are a few of them), and one that could get all the data it needs from IPC with a windows service. Not impossible by any means, but give me a couple of months 
2 Likes
Personally I completely agree with you. I am just relaying all the craze in the previous months, people insisting that syncthing should run as service.
I think what people are really asking for it “I want to install Syncthing using an installer, and have it start automatically”. Marketing a start-on-login solution as just that may work? If that fails for the more stubborn, then a big list of reasons why a service is a Very Bad Idea (complete with little red crosses next to each bullet point, etc) may be in order!
EDIT: If it helps, Bittorrent Sync doesn’t run as a service either - or at least didn’t when I last used it.
1 Like
@canton7 Thanks for your great work! I agree that a service is probably not the right tool for the job. Just go on doing it the way it’s done now and if someone makes an incredibly compelling argument, you can still think about it.
1 Like
I don’t need a service, but I can see why a few people might. (For perhaps irrational reasons, I like services a teeny bit better, except perhaps for the weaker security, but @canton7, your arguments for a per-user tray app are good.)
Say there is a family of 3 that uses 2 computers: A, and B. User A1 shares some folders, and user A2 shares some folders. B is a laptop that is only on sometimes. When B turns on his/her computer, either the A1 folders or A2 folders (or both, if the computer is sitting at the login screen!) may be out of date and unavailable. This could be compounded if there is another laptop, C, that updates files in A1 or A2: B and C have no reliable hub to act as an intermediary for when they can’t both be online at the same time.
Bottom line: the availability of files suffers in some use cases with no central hub(s). (This could become elevated from an inconvenience to a severe problem if people are doing collaborative work on the same files.)
I have an always on Linux server, (that never has any user log into it), so I don’t care, but not everyone may have this option. If there is a service, then it might also be nice if the SyncThing security model was strong enough to prevent A1 and A2 from doing Bad Things™, or from having to share the same username/password, although families share username/passwords for things like home wifi routers.
But I am guessing there might be more high priority things to do for SyncTrayzor than trying to jam service support into there. People can still use NSSM (although if I understand correctly, they’d now be missing out on the file watcher functionality).
You make good points.
The FileWatcher capabilities are moot if the user’s not actually logged in. If they’re not logged in, they’re not changing files, and there’s nothing to watch.
In the scenario you describe, service installation will have to be done per user that wants to run Syncthing all the time, with separate instances of Syncthing running for each of those users. Not impossible by any means, but it requires a bit of thinking about. The problem with using e.g. NSSM to solve it is that the Syncthing process run by NSSM will lock Syncthing’s database, and the Syncthing process started by SyncTrayzor won’t be able to access it. The solution is to get the service to launch a custom shim that 1) runs Syncthing, and 2) allows SyncTrayzor to take control of the service when it needs to.
Let’s move this to a separate discussion. It’s worth thinking about, and quite possibly implementing in the medium term, but IMO not a short-term priority, as you say.
1 Like
I don’t know if you tried the installer I created but it installs Syncthing into C:\Syncthing as well as installing it as a service. I’d also expect Syncthing shares to be stored under that Syncthing folder to make the directory path as small as possible to help prevent the user hitting the Windows character limit as discussed on here a few times.
Putting the synced files into AppData will vary on a per user basis because someone might have a really long name and someone else might not, also with Syncthing as a service it begins syncing i.e. preparing for use - as soon as the machine gets to the login screen so that once they are logged on it should be ready to use.
This is just my use case where it is in use in a company with around 18 devices.
It sounds like there’s a bit of confusion here. I’m not advocating putting synced files into AppData - AppData is used for Syncthing’s database. The synced files live wherever the user decides to put them - many people will want to share existing directories on their computer (documents, music, pictures, etc), and won’t want to relocate these. Nor is there any reason to ask them to.
In your installer solution, which user do you run the Syncthing service as? Do you force syncthing’s home dir to be a subdirectory of C:\Syncthing, or let it use its normal home dir of LocalAppData? How do you manage different users wanting to sync different folders? Do you need to run one service per user?
The Syncthing service is ran under the system account therefore multi-user setup share the same Syncthing instance which isn’t a problem for my use case which is a company with around 18 devices that all have 1 user use them.
Should another user wish to login this isn’t an issue as they require access to the same files which are under C:\Syncthing. We were previously storing the files under the users Documents which led to hitting the Windows Path Limit of 255 characters so we had to prefix the path in Syncthing’s config with \\?\
Also, as I said above, with it setup this way Syncthing is normally “Up to date” by the time the user has logged on.
@canton7: Great combined piece of software 
looks really good and you thought about many aspects like file watching and hiding/closing to tray - thanks!
@jaredthirsk: I agree this should help Windows users a lot
autoupdate I usually prefer this off, but this is just me
run as service
e.g. Crashplan uses a service, so it starts backup as soon as Windows has booted which is great. On the other hand if a computer is used at home it makes sense to autostart Syncthing to allow users to share different folders independently and to keep “family internal support requests” 
to a minimum
I agree that some users will want it on a per-user basis so on that note, could you make an option to “Run Syncthing as a service”?
As a side note, the icon on my taskbar looks fuzzy (using 1.0.6)
I have a couple of thoughts:
-
@Rewt0r’s solution doesn’t solve @jaredthirsk’s problem. The problem is the ability to sync user 2’s files while user 1 is logged in. With @Rewt0r’s solution, there is no concept of user 1 and user 2 from Syncthing’s point of view - everyone shares the same Syncthing config, and presumably the same files (but with different user accounts…). A tray utility with shared config would also solve the problem.
-
This is the big, serious one. One of the big advances in Windows security, in Vista and higher, is to run the normal user with as few privileges as possible, and require explicit permission for anything to escalate privileges. If you run Syncthing as the local admin and don’t set a GUI password, then you bypass all of the protection which Windows is providing. It’s trivial for any attacker to establish a connection with Syncthing’s REST API, add a new folder, add itself as a new device, and start changing files.
Now, on one or two machines this probably isn’t going to make much of a difference - no-one’s going to target you specifically. If it becomes the default Windows installation method, then you’re making thousands of machines vulnerable to a privilege escalation attack. That fact alone would be enough to sink Syncthing IMO - “They opened thousands of computers up to a privilege escalation attack, how can I trust them?”.
The first step to mitigating this would be to secure the GUI by default (ouch), and protect the config file from modification by any user (only modifications through the GUI are allowed). That’s a big inconvenience, and I’d still be very very nervous. Syncthing’s entire point is to silently modify files. Even if you think you’ve got it locked down, someone’s going to figure out that if you do X then Y then corrupt Z, you can gain just enough control to make it sync a file it’s not supposed to. The only thing to do is run Syncthing with the permissions of the user whose files it’s syncing: if you do that, suddenly everything’s OK and non-dangerous again.
@Rewt0r I don’t see mandating where document are stored as the responsibility for a general-purpose “official” Syncthing wrapper for Windows. We should let users put their folders wherever they want. If you want to put your files in C:\Syncthing for path length reasons then great, but most people won’t want to.
1 Like
As discussed above, supporting both having a service and a standalone utility would require a bit of work. If it’s worth doing, then let’s do it, but that’s a project for the medium term
It’s a 16x16 export of the full-size Syncthing logo SVG, and my graphics skills aren’t good enough to re-design it for low resolution (the white lines need widening, the gradient exaggerating, etc). If someone in the community can do this, or can point me towards someone who already has, I’d be very grateful!
Just to point out that although your security concerns may be valid, on most installations that is not the case as Syncthing will be setup so that only the local machine may connect to the webGUI (including REST).
For the scenario I’ve put into place with around 18 devices, one is a central server and this is the only one that has its webGUI available to the outside world but not entirely as there is a firewall in the middle only allowing mine and the Office IP addresses through.
@canton7: The 32-bit build installed easily and seems to work fine. I’m having issues with discover notifications and connecting the device (probably firewall) but I doubt these are related to SyncTrayzor.
Thanks for the amazing response. Cheers!