How to nicely setup syncthing to allow group write permissions, especially for new folders?

I have the following setup:

There is a /data directory on my server. It has group file:rw-/dir:rwx permission for the group hdd-data on absolutely everything under it.

This is because it contains, for example:

  1. /data/music for my music service (navidrome)
  2. /data/documents for opencloud
  3. Folders throughout /data are hosted on samba for windows machines in this house
  4. The entire /data itself are exposed on a web hosting service (copyparty) for nice browser uploads
  5. Many many other services

As such, every service running as it’s own user (for security) makes new files with permissions for servicename:hdd-data. Belonging to the group hdd-data is what binds all these system users together and allows them to write over each other if needed (e.g. upload file using opencloud in browser, but then edit the file in samba network mount).

The Issue: If I use syncthing gui to make a new folder, it creates:

drwxr-x---   - syncthing:hdd-data  4 Apr 16:17 sync

User does not matter, and group ownership is set fine with a system service. However, it does not allow group write, which means e.g. a window user through a samba network mount cannot edit a synced file on the server.

I want syncthing to be able to create arbitrary folders all throughout /data via the gui.

This also applies to new files it creates when syncing. The files may come from a windows device.

Is there any (preferably nice) way to make that happen? Or is there an alternative setup I should consider?

Is my only option to set default facl’s on everything to have group +write?

Thank you =)

As for right now, I have done:

cd /data
sudo fdfind --hidden --no-ignore --type=dir --absolute-path --exec setfacl --default --modify g::rwx {}

To modify default acl’s on every directory under the /data folder.

And then the same on the /data folder itself too, after.

This setup is not ideal, as I (and everyone using syncthing) need to not forget to check “Ignore Permissions” on every single new sync folder I create. Which - I absolutely, inevitably will and then have to go and fix all the permissions up.

(In fact I forgot it during my second folder sync already…)

Ideal world, at least “Ignore Permissions” would be available in the settings to be turned on by default for folders.

Suggestions for better setups very much still welcome.

Welcome here @gremious !

It seems to me that you need to have a “bigger” umask for the Syncthing user. See Umask command in Linux with examples - GeeksforGeeks for more info about umask.

If you’re starting syncthing through systemd, the default systemd service that comes with syncthing sets a very restrictive umask: syncthing/etc/linux-systemd/system/syncthing@.service at 1a3cbca0170306541d3d1877cc1a9efbd8d8c017 · syncthing/syncthing · GitHub. You may need to adjust this to your needs, especially if you’re using Ignore Permissions (since all folders created by syncthing will then use very restrictive permissions by default). You can use the systemctl edit syncthing@ command to create overrides for systemd settings without touching the main service file.

You absolutely can, it’s under Actions → Settings → General → Edit Folder Defaults → Advanced → Ignore Permissions. Altough I should say that not syncing permissions is not the common use case, it’s much more standard to sync permissions as well. But syncthing doesn’t force you to.

2 Likes

Thank you very much!

Editing the umask did let me do it without using acl’s, and while “Ignore Permissions“ still needs to be always on, having it on by default makes it a non-issue. I now have a nice setup where multiple services can modify synced files. Appreciated! =)

1 Like

I’m in a similar situation but decided to run all services (docker containers) as the same UID/GID when they need access to the files synced by Syncthing. What is the added security benefit of running these with different UID/GID if these too will be granted access to the same set of files? I do run containers which don’t need access to these files using dedicated IDs for security but didn’t see the benefit when they need access to a common set of files. Perhaps that insight may simply your setup.

Since you also use Samba, you can force SMB to write as a specific UID/GID. Even when the user who authenticates has a different UID/GID

2 Likes