Yeah, permission management on Synology tends to be problematic… I haven’t touched my setup in years and glad it just keeps working after the initial battle.
Apparently it doesn’t. Did it even create the subdirectory, can you see it in File Station?
One thing to note about the Synology package: You need to enable the “Ignore permissions” option for each folder. The most recent package version does that by default, but not if upgraded from a previous version. If you have that option disabled, Syncthing will try to set the simple (POSIX) permission bits on the files and folders during synchronization, which clears all the ACL based permissions.
Maybe it helps to create the folder first in File Station, assign write permissions for the syncthing group (make sure it inherits to all paths below), and finally choose the path when adding the folder in Syncthing.
Define a shared folder for it in the Control Panel or any subfolder in the Filestation. Very important: Give the respective shared folder the full rights for the system user “sc-syncthing” via the control panel.
Thanks for clarifying this @Andy and @acolomb. It’s been an area of confusion for me, too.
I’m confused about the state I’m in, which is a result of installing multiple generations of packages. Can you possibly help me understand which users and groups are actively used by the current package version?
In “User & Group”, I see the following groups:
sc-syncthing__PKG_
syncthing__PKG_
In “Shared Folder” when I look at a folder which is being synced by Syncthing, I see:
System internal user\sc-syncthing : No permissions
System internal user\syncthing.net : Read/Write
Local groups\sc-syncthing__PKG_ : Read/Write
Local groups\syncthing__PKG_ : No permissions
Can one of you possibly help explain which of the accounts I’ve mentioned above are in use by the current Syncthing package and which are obsolete and can be deleted?
Unless you advise otherwise, I’d like to use ‘synouser -del ’ to clean this up. It would be nice if installing future package updates actually did this quietly on its own, but perhaps there are good reasons not to.
It would be very impolite for a package update to remove / change anything but the users created by that same package.
The syncthing.net stuff is no longer relevant, it belongs to a no longer maintained package.
Not quite sure about the others really and in fact it might depend on the DSM version. I’d need to look it up in the source code, or on my DSM 6 installation what the owner and group of files created by Syncthing is. You might find out by looking at the running process as well, using a tool like htop for example. The wiki for the SynoCommunity packages on GitHub has some detailed information as well. Sorry I’m currently on mobile, with little occasion to look up the details or links right now.
Use that group user. Indead it seems in the past you had another package installed, maybe from Kastelo, which is no longer supported. If you have deinstalled that, there are surely fragmented data on the NAS, which are not a problem but as effect that the DSM rename the group user from the basic name sc-syncthing to sc-syncthing__PKG because there is a confusion regarding the not visible user name syncthing, which is used from both packages.
Finally all names are no problem and normally Syncthing could run anyway.
