It is my current understanding that permissions on the native Synology package are being configured by configuring the permissions of the system-internal user sc-syncthing and the internal group by the same name.
Some of these folders don’t even exist anymore on the source. Yet, syncthing doesn’t remove them from the processing list. Is that a known bug? I am quite sure that this has worked on older releases (<1.25). This is kind of an unusual scenario. Basically, a folder plus content got synchronized, and then the owner changed the folder name. The updated folder is now on both systems and neither system still has the original folder. Maybe it is some kind of caching problem?
I am still researching the last error on the list. It is for a different object.
Last, but not least, a properties screenshot of the same share from my windows desktop.
Weird! The numbers don’t seem to add up. Same share in syncthing.
The sc-syncthingGROUP is what should be used to manage access AFAIK. Have you checked that these permissions actually propagate downwards through the hierarchy? There is a Permission Inspector tool built into File Station that will help showing actual results of the existing ACLs.
It’s good you have “Ignore Permissions” enabled on the Synology (which should be the default), otherwise Syncthing would set the POSIX permission bits and thereby erase any existing ACLs on the files.
Sorry no idea about the mismatching numbers yet. Let’s first examine the permissions problem.
I have just checked permissions using file station and found that the permissions for the shared folder didn’t get applied to any folders or files showing in file station. So, I reapplied them there and propagated them using the “apply to this folder, sub-folder and files”.
For good measure, I have now restarted syncthing on Synology. Sadly, it failed with the same six objects again. Why does it even want to create objects that no longer exists anywhere?
I have opted to reapply permissions to the user sc-syncthing using file station and, once it did a rescan, it actually worked. So, it seems that my system is using the user sc-syncthing and not the group.
Well it appears to all have changed with DSM 7, which I wasn’t aware of. My boxes all still use DSM 6 for some good reasons.
On DSM 6:(You shouldn’t assign user permissions at all, only for the group. Otherwise the user permissions probably override the group ones. Just clear out the user ACLs for that internal user and keep using the group from now on.)
