I have had syncthing running on my servers in the past as a system service, which involves creating a service that runs as a specific user. Initially this posed a challenges as I was only able to synchronize files and folders created or owned by the user under which the service was running.
In order to give permissions to that same user to a folder that wasn’t owned by that user, I would have to add them to the file/folder structure by altering the ACL.
setfacl -Rm u:someuser:rwx file
Etc.
Only then would creating a new sync folder actually work (.stfolder marker, etc.)
I’m setting up a new system and I’m wondering if there’s a way to create a user that doesn’t need to be explicitly added to each intended sync location like this. I suppose it’s not much different than having the service run as root, which is not recommended. Just wondering if there’s an easier way.
Come to think of it, here’s an ACL permissions question:
If I create a folder /thisfolder and I add the user whomever to that folder using setfacl, if I add folders beneath that /thisfolder/folder (for example) do the ACL permissions propagate to the new content? If that’s the case then I could simply make sure that all of my sync’d folders reside under a single folder root and just apply the ACL settings to that folder tree.
I believe the generally recommended way to do that is to run multiple instances of syncthing. The systemd system unit is per-user, so doing that is trivial. Is there something specific that prevents that?
Wouldn’t that mean needing to keep track of multiple ports, user permissions, etc.?
In the past, I simply created a syncthing user and then any time I needed to give access to a specific folder sync, I’d just add them through ACL’s to the required folders…
I haven’t ever considered compartmentalizing syncthing into multiple instances, one for each user on the server…seems that would become resource intensive.
Syncthing is pretty good at figuring out ports, but the GUI listen port needs to be dealt with. As for the permissions, depends on the setup. I’d expect it to just fold into the system permissions - you run syncthing as the user that owns a specific folder to share it. Of course, if you have a complex multi-user setup that’s a pain in itself.
While I won’t disagree, I also live in a world where people use Docker to run single applications and spin up Chromium as a text editor. Multiple process instances seems positively frugal in comparison.
I’m sorry about that, but if you’re looking for systems that are designed to handle server-based user-segregated syncing, there are a few available. Syncthing isn’t one of them - it’s built for peer-to-peer syncing without user segregation.
I have a use case with a multi-user setup. I use syncthing-fork on an Android device as main source of sync. I also have a shared laptop with 4 users. I want to have a single setup so that all users can access the synced dirs, and the laptop will have only a single identifier for the Android syncthing instead of four separate ones.
Maybe the below is a wrong approach?
What would be the right one then?
Here is my setup:
Laptop with 4 users.
Arch Linux.
Group syncthing created. All users added.
Directory /home/syncthing created. Group syncthing owns the directory.
Syncthing running as a system service user syncthing. Member of group syncthing. The service account’s home directory is /var/lib/syncthing.
File creation mask set to:
[Service]
UMask=0002
Which should allow the service to create dirs that can be opened by the group.
However, when syncthing receives a dir to sync, it creates it with permissions:
drwx--S--- - which allows only owner to access, i.e. the user syncthing
Expected permissions:
drwxrws--- - allowing the group syncthing to access.
Am I doing something wrong here?
Happy to provide more information.
I did try playing with “ignore permissions” as well. To no avail.
It’s not my case because:
the sending side is Android with syncthing-fork which sets no permissions by default and does not even expose this option in folders
AFAIK the permissions only apply to the objects within the folder, and those perms are all set correctly, as expected: with owner and group syncthing
The problem is, that the folders themselves (i.e. the top level in syncthing home folder, i.e. /home/syncthing) are created with perms only for the owner, but not for the group, i.e. drwx--S---:
# ls -la
total 16
drwxrws---+ 1 root syncthing 74 May 3 22:58 .
drwxr-xr-x 1 root root 26 May 3 14:00 ..
drwx--S--- 1 syncthing syncthing 2060 May 3 23:14 766gb-g6df9
drwx--S--- 1 syncthing syncthing 1430 May 3 23:01 95zwm-9fkhl
Ah. Yeah, we don’t get that one from the other side so a conservative default is used. Feel free to chmod it after creation, or create it yourself beforehand.
Thanks. Is there a way to change the conservative default? I will need to repeat the setup on another machine like that and I’d love to have a reproducible approach.
update:
Just to confirm. The umask 0002 set in the service - does it play any role at all?
