Filesystem Watcher Errors on Synology Subfolder

[Moisie]

Hello:

Apologies if this is more of an OS question rather than a Syncthing question, but I’m seeing an error on a couple of my Syncthing installations on Synology NAS:

“Filesystem Watcher Errors … error while traversing /volume1/FolderName/SubfolderName: permission denied”

Looking at ACLs for the folders in question:

• FolderName: has an explicit R&W ACL for the sc-syncthing group (as Syncthing runs under on the Synology);
• SubfolderName: has an inherited R&W ACL for the sc-syncthing group.

I note the POSIX owner:group for this subfolder (sc-syncthing:syncthing) is different for some neighbouring subfolders (100:users) - but there are other neighbouring subfolders which have the same owner:group as the problematic one, and aren’t reporting any problem.

I’ve already increased the inotify limit - so I don’t think that’s the problem - but I can’t find which logging option would show more information about the error (e.g. is there a subfolder inside this subfolder which has spurious permissions?).

I’d rather not just do a blanket chown/chmod across the whole folder (which is rather large), as I presume this will prompt a resync across all my connected devices.

Any ideas?

Thanks!

[AudriusButkevicius]

Listing a directory requires execute permission rather than read and write.

[Moisie]

Hi Audrius:

Thanks for the input. Good thought - but unfortunately I don’t think that’s what’s happening here.

Here’s Synology’s Permissions Inspector for the subfolder I’m having the problem with:

And here’s the same thing, for a neighbouring folder which I’m not having a problem with:

[AudriusButkevicius]

Anyways, it’s clearly a permissions issue as stated by the error message.

I guess synology forum is more appropriate for support with their permissions model.

You can try disabling acl’s and move to a more simple permission model.

[Moisie]

Thanks Audrius - I appreciate the attempt to help resolve this.

Do you know if there’s a way to find the exact file/folder that’s prompting the error?

I’ve looked at each of the children of Subfolder, and they all appear to have no permissions restrictions for the sc-syncthing user.

You can try disabling acl’s and move to a more simple permission model.

Unfortunately this is how the Synology software sets up shared folders - and I’m loathed to (potentially) break things too much…

[imsodin (Simon)]

The error occurred on the path reported: /volume1/FolderName/SubfolderName. I believe getfacl -e *path* returns all unix and acl permissions.

[Moisie]

Hi Simon:

Thanks for chipping in. It looks like getfacl isn’t included on Synology - but they have a synoacltool instead.

Here’s the output from the ‘broken’ folder:

# synoacltool -get /volume1/FolderName/SubfolderName/
ACL version: 1 
Archive: is_inherit,is_support_ACL 
Owner: [sc-syncthing(user)] 
--------------------- 
	 [0] user:adam:deny:rwxpdDaARWcCo:fd--  (level:1)
	 [1] group:administrators:allow:rwxpdDaARWc--:fd--  (level:1)
	 [2] group:workshop:allow:rwxpdDaARWc--:fd--  (level:1)
	 [3] group:office:allow:rwxpdDaARWc--:fd--  (level:1)
	 [4] group:sc-syncthing:allow:rwxpdDaARWc--:fd--  (level:1)
	 [5] group:machines:allow:rwxpdDaARWc--:fd--  (level:1)

And the output from a neighbouring working folder:

# synoacltool -get /volume1/FolderName/Subfolder2Name/
ACL version: 1 
Archive: is_inherit,is_support_ACL 
Owner: (user) not found 
--------------------- 
	 [0] user:adam:deny:rwxpdDaARWcCo:fd--  (level:1)
	 [1] group:administrators:allow:rwxpdDaARWc--:fd--  (level:1)
	 [2] group:workshop:allow:rwxpdDaARWc--:fd--  (level:1)
	 [3] group:office:allow:rwxpdDaARWc--:fd--  (level:1)
	 [4] group:sc-syncthing:allow:rwxpdDaARWc--:fd--  (level:1)
	 [5] group:machines:allow:rwxpdDaARWc--:fd--  (level:1)

The only difference I can see is the owner of the ‘broken’ subfolder is the sc-syncthing user - but, as I say, there are other neighbouring folders which have the same owner, and they’re not reporting a problem…

[imsodin (Simon)]

Yeah, no clue what might be going on. However you aren’t alone, Synology problems come up all the time. Here Jakob suggested a sledge-hammer approach (remove acls) which apparently worked: Permissions error on Synology

[Moisie]

Thanks Simon - I appreciate your time and efforts! I’m reassured to see it’s obviously not me just being stupid…

[Moisie]

Hello:

Could I ask for a word of advice if you please:

I’m looking to fix this permissions error - but I’m wary of causing problems by performing this operation on a large folder on a slow device:

• Will modifying the permissions on a folder prompt Syncthing to re-sync all the files inside it? I have Ignore Permissions set - but will the modification make Syncthing consider it has newer files now available? (I appreciate none of the blocks will have changed - but I presume there would be a massive index update)
• If it will prompt a re-sync, how best should I do this, considering the files might be being actively modified on another device in the cluster, whilst this (slow) device rescans the folder?

Sage words appreciated - thanks!

[AudriusButkevicius]

It might resync the metadata (permissions, times etc), but it won’t resync data if that has not changed.

[imsodin (Simon)]

Using chmod does not update the mod time - and that’s what Syncthing cares about. Now if you use some syno-tool to do ACL stuff, all bets are off whether mod time gets bumped (I’d expect not, but it’s syno). I’d try it with a single file and check whether the mod time changes. If it doesn’t, go ahead doing it on everything.

[calmh (Jakob Borg)]

Unless ignore permissions is set we do sync permissions as well, and rehash on change I think.