Yes it can, just needs credentials
So is that not the obvious and easy solution?
There was discussion about having Syncthing run as a service, then having a separate tray utility running as another usr, which communicates with Syncthing. This was tied into the ârunning Syncthing as a service to sync files for multiple usersâ and ârunning Syncthing privileged, but let a user have a tray utilityâ ideas.
If you run Syncthing as a a non-logged-in user (think server), then I donât see the use of a tray utility. If you run Syncthing as a logged-in user (think desktop), it probably wants to be start-on-login and no a serice. Either way, I donât see much application for the âSyncthing as a service, but communicating with a tray utilityâ idea.
1 Like
Jakob, I think canton summed it up well.
LocalService / LocalSystem are ways for SyncThing to exist on Windows in a manner like a Linux âdaemonâ that starts on boot, and is running whether anyone logs in or not (just like how apache starts when u boot in linux whether you log in or not).
I think one of the points of contention is that if SyncThing is running in âdaemonâ mode (think Windows Server) , then any user on the machine can connect to localhost:8080 and overwrite files that might not be their own ⌠ie. on a mult-user machine where one person uses syncthing, and someone else wants to hack their files.
The simple solution (I think) is to either (A) on windows install synchting as the âuserâ and have it start-on-login (like Desktop0 , or (B) on windows instal syncthing as LocalService/LocalSystem, but make sure you enable http username / password for localhost and the web services.
But honestly I donât see a big problem here because most of the use-cases are going to be users running Syncthing on login. Very few of the user-base will demand the ability to install on Windows Server 2008 with custom security.
So I think this is not super critical issue right now, but maybe Iâm misunderstanding it.
This would require some major changes to Syncthing to work properly and securely, much more than simply running it under a shared account. So I recommend against it for the time being.
But then we go back to what I said above with regard to having to setup Synthing for each user on each machine with different IDs because Iâm not sure how Syncthing would react to the same user logging in on 2 machines with the same ID?
You should probably think of the ID being tied to the files on disk and the accompanying index. You should not have a âroamingâ ID that moves from one machine to another, unless the synced files, index and config also roam like that. If they do, then itâs really just the hardware that changes from time to time and thatâs fine.
Multiple connections from the same device ID are not supported. That way lies confusion.
But isnât that what Iâm saying? i.e. One ID per machine which seems like the most sane solution instead of an ID per user on each machine? Thatâs just an IT headache/mess.
Well, presumably each user has their own set of files to sync? With a shared ID and configuration, you give each user on that machine access to every other users files and so onâŚ
Not in a company scenario, the company I implemented it for previously used Office 365 OneDrive for Business and it was terrible⌠Kept losing files, moving them where they shouldnât be, stopped syncing completely several times a month. Not only that it was a HDD killer, they had 5GB worth of data to sync yet OneDrive for Business was performing around 300GB worth of reading AND writing to the hard disk on initial sync and around 100x the size of a new file once it was added.
They all access the same set of documents on each machine.
So is that a use case where syncthing syncs something like c:\shared stuff on the machine, and the users have their stuff in there? If so, that sounds fine.