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.
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…
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
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?
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.