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).
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.
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
@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.
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.
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).
It’s another attack vector. Correct me if I’m wrong, but I think any local software running under a non-admin user account can open a port on 127.0.0.1:8090, create a share from say C:\Windows\System to some hacker’s share and start replacing files with trojans. The net result is that Windows’ entire security architecture is nullified, if a malware author can get any software onto a users machine.
If syncthing is only running on a user account, the worst that could happen is all the user’s files could be deleted/stolen (cryptolocker), which is still bad. Running syncthing with no webGUI password scares me.
Still, I can quickly switch it over to running as the LocalService account which I shall do in a moment. Then what would be the issue? I think you’re reading too much into it, anything can be broken, depending on how easy the user makes it.
My understanding, which could be wrong, is that localservice has very few filesystem permissions, meaning it wouldn’t be able to sync a user’s personal files?
@jaredthirsk understands what I’m trying to get across. The danger isn’t that someone connects to syncthing from another computer. The danger is that a trojan executing with user permissions can completely bypass the protection provided by UAC, which is considerable, and be allowed to alter the system.
Anything can be broken, sure, but that doesn’t mean you should turn off UAC on every new computer…
To a large degree it doesn’t matter how “real” the threat is. What matters is that if it becomes known that Syncthing distributed software which contained this vulnerability - even after being made aware of the issue - not a single authoritative source would recommend it. It only takes one little security lapse to put off potential new users: “yeah I heard about Syncthing. Isn’t that the one that shipped that vulnerability?” etc.
What ultimately becomes the recommended approach to using Syncthing on Windows is in the hands of the maintainers. The best I can do is make my views on security clear.
Anyway we’ve completely derailed the topic from “hey, look, a tray utility” to “are services a good fit for Syncthing?”. Can we move this discussion to another thread?
When a new device connects I’ve noticed it gives me notifications for each folder I share that it has “Finished Syncing” when there was nothing to sync. Could it not just inform me that a device has connected?
looks really good and you thought about many aspects like file watching and hiding/closing to tray - thanks!
to a minimum
