I’m trying to setup SyncThing on Windows as a service with nssm.
I prepared a dedicated user and assign this user to all shared folders having FullControl permission, and to service logon user.
As I started the service and accessed Web UI, I see “Filesystem Watcher Errors” message at the top of Web UI, with " NAME_OF_SHARE Access is denied."
I’m sure that this dedicated user has access to the shared folder, the service logon user is this user. I couldn’t find any related log in syncthing.log.
I’d appreciate if anyone can help me to identify the issue.
For example, is there any additional requirement regarding permission this dedicated user should have?
As you suspect, this service user does have access for the share folder but doesn’t for the parent and upper folder of the share folder. Does it need to have access up to the root?
Sure, if it can’t read the parent(s), it can’t access the children (at least that’s the case on linux, and semantically I would expect the same regardless of OS). If there is a special permission required for stating directories, it will need that too.
Seems like Windows doesn’t require permission up to the root if it only accesses file under the specific folder with appropriate permission. Actually, scan itself works good now.
Assuming it uses ReadDirectoryChangesW API, I tried the sample code with the following condition:
e:\test : user A has full access (user B has no access)
e:\test\test : user A and B has full access
as user B, both dir command and ReadDirectoryChangeW sample to e:\test\test works good, where as dir command to e:\test as user B fails.
Also I tried to add read access to the parent folder of the shared folder, but SyncThing still complains. I assume the current implementation requires permission up to the root.
Hope it’s improved in the future, but at this moment thanks for your help.
The library used for the watching for changes feature internally checks the full path for stuff like symlinks, that’s why I mentioned needing to be able to stat directories on the full path. What’s wrong with adding read access all the way to the root?
By default, assigning permission to the specific folder by Windows Explorer make this new permission inherited to all child/children items. Therefore, at the file server, I normally assign only administrative right to folder structure, and assign access for allowed user to the folder to be shared.
In my case trying SyncThing, I planned to sync just one of shared folders to the remote location, so only added SyncThing user access to the specific folder because I thought SyncThing should not have access other folder nor upper folder structure. Then encountered this issue.
It’s possible to add folder-only(not inherited to children) permission with Advanced menu of Explorer, so I may try that later.
After adding Read&Execute permission only to folders the shared folder is related, up to the root, Filesystem Watcher error disappears.
The advice worked. Thank you for all of your help!
Theoretically, I’m still not quite sure why “The library used for the watching for changes feature internally checks the full path for stuff like symlinks”. Because full scan, not filesystem watcher works good. If filesystem watcher needs to check the full path, full scan might need it too and not work in my scenario.
Anyway, thanks for your help, my system works good now. Thanks again!
I understand that confusion, I probably shouldn’t have mentioned that internal detail in the first place. Now that I have done it anyway let me try to explain:
The full scan is done fully in Syncthings code and based on its “view of the filesystem”. It doesn’t care if you have symlinks or any other weirdness in the folder root path. Watching for changes is done by an external library, that for internal housekeeping needs the watched paths to be “canonical”, and thus checks and potentially mangles the full path - that requires these permissions.