I just found out about Syncthing and must say it is awesome! I have set up several “regular” shares but have a use-case not sure how/if it can be covered and wanted to ask.
I am part of the board of a sport community (but can be other types of organizations). Such communities usually have several subgroups (e.g. football section, table tennis section, …) and the members come and go (new board every year).
So, how to set up a share for this. Ideally we’d have Something like
|__ Football section
|__ Table tennis section
In this folder structure I’d like to share Main folder with “everyone” and then Board with a selected subgroup of everyone and so on. Regular Unix permissions would of course solve this. But This needs to be shared between arbitrary and non-tech people. Further, I need to be able to remove people as they leave a role and remove their access to the folder structure.
One idea I have is to have a “hub” share with many others. I guess that would solve the add/remove users issue, but not the firs one with limited access. Is there a way to solve that with current Syncthing implementation?
If the answer to that question is “no”, which I think it is as far as I can tell. I would like to propose a feature: add something like groups to Syncthing; defined locally on each sharing device, and e.g. set in some hidden file, like .stgroups. Would that be possible?
Thanks for any advice!
You can have a central device that acts as a hub for everyone, and where you remove people when they leave. As for your folder structure you should only share with people that which they should be able to access. So only share the top level with people who should be able to access everything, and instead share only subfolders with those who are part of those groups.
Yes thanks, this is certainly a (partial) solution. But it becomes cumbersome to manage when there are multiple users with access to different (subsets of) folders. I understand that I am asking for a full ACL-type of feature and that that is a huge thing to implement. But the use-case is probably quite wide and Syncthing could make a big difference for this type of organization due to multiple factors such as “automatic” GDPR compliance, (extremely) low cost (which is quite important to voluntary organizations with low budget), …
Anyway, thanks for the quick reply and for the great software - and a happy new year
I have previously solved this by “every sub group is a share”. So people who have access to everything accept a lot of shares at setup.
This is exactly how my org is doing it now.
Every level/project/department is a share. People who need to see everything (hub server, President/Owner, SysAdmin) get access to everything. Everyone else gets access to their department share, as well as a “z-Temp-Share” folder that’s used by everyone for sending files between departments.
Hope this helps, OP.
Thanks for all replies. One thing I was thinking of in this regard; is there then some way to hinder one user from sharing on to others. To make this work, it seems one would like to have a single hub that shares to all users. Then one can stop sharing with whoever when they leave the organization. However, how do I stop the users from sharing with others, and is there some way to detect if they do?
There’s nothing built in to enforce what the other user can do. They can also drag and drop the files to an USB drive or Dropbox, for that matter.
The question might also be whether every user in such a sports community has their own device. Or whether users share a device. Then a separate instance should run for each device user so that this individualization is retained via the devices, e.g. 3 device users means 3 sync instances. Then the admin would have the possibility to control the users via the devices. If he takes out a device in his head office, there is no longer any access.
I am now thinking, however, with the Windows user control glasses, where something like this could be made relatively clear.
If that were not the case, i.e. a complete device is shared with 3 users, for example, it would actually be difficult, but it will also be via the usual ACL assignment of rights.
Just a mind game: the problem could maybe be solved with several hub instances in which different ignore lists are stored. This could make it possible to control individual access in a very coarse cluster.
Example: Instance 1 allows access to all contents of a folder. Instance 2 excludes e.g. the files
*foo from the same folder. The users concerned then have access to either instance 1 or instance 2.
However, I cannot say whether it will run smoothly, it can only be tested.