I created a one-way synchronization pipeline from Windows 10 to Synology NAS. At Windows side, the Syncthing Folder is set as send-only, at NAS side it is set as receive-only. Several problems emerged.
The first synchronization resulted in directories with incorrectly set privileges at NAS side. All directories had the Delete privilege disabled (folder > Properties > Permission). On the contrary, the NAS directory corresponding to the ST Folder Path has all Read/Write privileges inherited and enabled.
Hence I set the privileges for the whole tree, now they are inherited everywhere. This resulted in that all(?) items at NAS are now marked as Locally Changed.
Moreover, at Windows side, I moved content of a directory somewhere else, and when realizing the mistake, I returned the files back. Now, all the moved (and returned) files and folders are marked at NAS side as Failed Items. The detail shows that “directory contains unexpected files, scheduling scan”.
I created another sync pipeline with the same result as in 1. But after fixing the privileges as in 2., the folder is “Up to Date”.
I don’t know what “Delete privilege” is and Syncthing doesn’t sync anything like that. Syncthing only deals with “unix permissions”, i.e. read/write/execute for user/group/other. As windows doesn’t support that model, we remove write bits on group and other there and try to infer executability from extension (and whether the previously existing file was executable).
That’s expected.
That may indeed be a current limitation. The comment where this error is emitted looks like it predates receive only folders:
Ad 1. I don’t know how Synology NAS determines the privilege it assigns to the files and folders that are created by Syncthing. But I can repeat this behaviour every time I create a new pipeline:
At Windows side a send-only folder, at NAS side a receive-only folder, no other folder setting modified (in particular “Ignore Permissions” remains unchecked on both sides). The Folder Path at NAS side is “/volume1/Syncthing/test/etc/SyncTest”, and this folder has these inherited privileges (the folder was created by Syncthing too!):
But all files and folders below it have privileges set explicitly (not inherited). Folders:
Files:
I don’t know what Syncthing does while creating the files and folders so that the privileges are set explicitly.
Ad 2. How should I have set the ST Folder so that change in privileges does not result in locally changed items? Ignore permissions at NAS side?
Ad 2. When I force the inheritance of permissions for the whole directory tree, ST Folder shows Locally Changed Items, as described above. But when I press the Revert Local Changes button, the explicit permissions are returned back. I deduce from this that the permissions are inferred from the data send from Windows, somehow.
When I check Ignore Permissions at NAS side first, and then enforce the privilege inheritance, Syncthing doesn’t show any Locally Changed Items, everything remains “Up to Date”.
When Ignore Permissions is checked from the beginning at NAS side, the privileges are set correctly.
On NAS you should simply enable ignore permissions, they do their own thing regarding access control, so you don’t want Syncthing to mess with that. On windows it should not hurt to not ignore permissions, but it won’t do much either (if all the connected devices ignore permissions, it won’t do anything).
Thanks for the explanation. I never had Ignore Permissions set when syncing from Android, and I’ve never had any problem. But for Windows, the situation seems different.
The topic is of interest in principle, since I basically run all peers on all my Synologys with “Ignore permissions” checked.
Why it works then is not finally clear to me either. However, it also seems to me that there are conflicts between the Windows ACLs and the Synology ACLs. This makes logical to activate the option.
Since the Web GUI can also be called up on the Smartphones, I have found that all peers created already by default with “Ignore permissions” checked, ie without intervention. It therefore seems to me that there should also be a decoupling between the ACL systems in the same way.
Synology does its entirely own thing with ACLs. There’s a closed source kernel module and a corresponding mount option synoacl. This provides some sort of ACL layer on top of regular unix permissions, and these ACLs are entirely invisible at the filesystem layer. This is something entirely different than “normal” rich ACLs as used in for example FreeNAS. As far as I can tell it’s not even stored on the filesystem itself, rather provided from some other place / database.
There’s also a tool synoacltool that’s mostly inscrutable. It’s totally not clear to me when these ACLs take effect, to what extent they inherit, etc. Googling it makes clear that not many other people understand this either.
Frankly this is a really weird environment where I don’t think you can seriously expect any tool like Syncthing to work well.
It’s not really a Linux system more than Android is a Linux system. Abandon all normal expectations upon entry.
If you get it to work, great, but don’t expect to be able to debug permission errors like this was a normal system. It’s not. The permissions you see have very little correspondence to what is actually enforced.
What is a use case for syncing ACLs between different devices? Different devices have different users and groups, how Syncthing handles this?
IMO there’s no use of syncing ACLs between different platforms (Android, Linux, Synology, Windows). Moreover, syncing ACLs probably works only on Linux. Does syncing ACLs have any other use than when syncing between Linux computers for the purpose of sharing folders? (Cross-platform syncing is probably used for backuping purposes only?)
I mean, if there is really no other use case for syncing ACLs, shouldn’t the Ignore Permissions option be set by default?
Syncthing doesn’t sync ACLs. Permissions are about the Unix permissions bits, or in the Windows case only the read only bit mapped to the corresponding bits of the Unix permission set.
OK, so only unix(-like) permission bits are synced?
In that case, if I return to the problem 1.: ST is able to create files on NAS without causing Synology to create user/group permissions. The user/group permissions are created only when Ignore Permissions is not checked.
If I remember well, ST has a specific code for Synology that - at least - is aware of the special group sc-syncthing. It seems to me that it must be this module that doesn’t work well when creating the user/group permissions.
Syncthing has zero code anywhere to deal specifically with Synology. “ignore permissions” does precisely one thing on the receiving end, it avoids a chmod after creating a file or directory, instead leaving the permissions whatever they happened to be by default.
How this interacts with Synology’s ACL system I don’t know.
I’ve played with chmod on Synology NAS a little bit. Synology uses ACLs, ls -le displays them:
$ ls -led x
drwxrwxrwx+ 1 sc-syncthing syncthing 530 May 14 14:28 x
[0] user:sc-syncthing:allow:rwxp-DaARWc--:fd-- (level: 0)
[1] everyone::allow:r-x---a-R-c--:fd-- (level: 0)
[2] group:syncthing:allow:r-x---a-R-c--:fd-- (level: 0)
[3] group:administrators:allow:rwxpdDaARWc--:fd-- (level: 4)
[4] group:sc-syncthing:allow:rwxpdDaARWc--:fd-- (level: 4)
The + sign at the end of the attributes denotes that there are extended attributes present (the ACL), which can be displayed with the -e flag. “level:4” denotes that the privilege is inherited from /volume1 directory, “level:0” privileges are set for x directory explicitly.
The important thing is that whenever you perform changes using normal chmod, you loose the + sign and the ACL. You cannot reset to the initial state (with inherited ACLs) using normal chmod. (You can manage ACLs using chmod, though.)
$ chmod 777 x
$ ls -led x
drwxrwxrwx 1 sc-syncthing syncthing 530 May 14 14:28 x
When you create a new directory, its privileges are inherited:
$ mkdir z
$ ls -led z
drwxrwxrwx+ 1 správce users 0 May 15 09:23 z
[0] group:administrators:allow:rwxpdDaARWc--:fd-- (level: 4)
[1] group:sc-syncthing:allow:rwxpdDaARWc--:fd-- (level: 4)
So, indeed, whenever Syncthing uses chmod, it breaks the ACLs and privilege inheritance, and it has no means how to revert this. Hence, Ignore Permissions should be always checked on Synology NAS. (However, when syncing from Android, ST does NOT execute chmod for some reason, so in this case the privileges are set correctly.)
If the file from the other side has the ignore permissions bit, because that side has ignore permissions enabled, we also skip the chmod. (Because there are no sensible permissions to set.)
I don’t think there’s a reason for it to be always / default checked for Windows. There it mostly means we sync the read only bit, and other ACLs take effect as usual.
