inotify on Synology NAS with DSM6 - How to get it up and running ??

TerrorSnake11 · April 29, 2019, 8:51am

Hello Community,

this thread is about

error while traversing /volume1/path/to/share (shared): permission denied

when running Syncthing on a Synology NAS

Since inotify was implemented in Syncthing this feature is essential for a smooth sync-experience. I got very positive experience with it on an ASUSTOR NAS, but now switched to Synology DS918+ that throws errors

Fact is, that inotify is not working “out of the box” with Syncthing on a Synology NAS. The problem is caused by Synology. It is not an error in Syncthing itself!

There have been several threads about that issue in several forums but none described a working solution for me.

I am pretty sure there are many Syncthing-Users, that face the same problem with Synology Hardware.

If anybody got a solution for this, PLEASE BE SO KIND AND SHARE IT WITH ME AND OTHERS HERE!

Thank you.

Kind Regards Andy

imsodin · April 29, 2019, 9:40am

In principle the solution is simple, in practice I donät know Sznologz NAS, it might make it more complicated: Check which user Syncthing is running at, then make sure that user has permissions to access the share directories - done. So as probably already mentioned in the threads you mention, if you have problems with these permissions, you might get more/better help when asking on a support venue of Synology.

fulstop · April 29, 2019, 11:08am

Make sure that your share has read/write permissions for sc-syncthing group

See :

github.com

SynoCommunity/spksrc/blob/fba7e8b4fe137270fcf173f17acc377cb06385af/spk/syncthing/src/wizard/install_uifile

[{
    "step_title": "Attention! DSM6 Permissions",
    "items": [{
        "desc": "Permissions for this package are handled by the <b>'sc-syncthing'</b> group. <br>Using File Station, add this group to every folder Syncthing should be allowed to access.<br>Please read <a <a target=\"_blank\" href=\"https://github.com/SynoCommunity/spksrc/wiki/Permission-Management\">Permission Management</a> for details."
    }]
}]

TerrorSnake11 · April 29, 2019, 1:03pm

Thank you for the replys.

Permisions to the synced folders are OK. I am aware of the sc-syncthing group and the corresponding user. Thats why syncronisation IS working. But the inotify-feature is NOT working. Without that I have to fallback to scheduled rescans, which causes delayed sync of changed files and massive load to the filesystems I sync. I really need inotify get working.

In Synology-forum I found posts up to 12 years old but support did not answer. Seems like the vendor is not interested to solve user requests. And… I just feel better in this forum

Hope someone will come up with the solution.

ludos · April 29, 2019, 2:30pm

I am currently in the setup process of syncthing on 2 synology 918 and a notebook. I have experienced similar problems and a very curious behaviour on the synology nas.

In my case 2 folders which had exactly the same permissions according to “ls -ad xyz” and “synoacltool -get xyz” as well as in the web-ui would still cause problems with one folder in inotify. I assume that the unix permissions are in use by inotify, however the tools available only list advanced acls used on the synology nas.

The good thing is that i was able to use chmod and chown to fix those problems. I wrote a script that fixes all my folder permissions at once.

The individual commands i used are:

chmod 777 -R folder_name
chown -R yourUserName:yourGroupName folder_name

To fix multiple folders at once you could use something like this. But only use this if you understand what it does!

for folder in /volume1/folder_1 /volume1/folder_2 /volume1/folder_3; do
  echo "--- $folder ---";
  find $folder/* -maxdepth 0 -type d ! -name '\#*' ! -name '\@*' -exec ls -ld {} \; -exec chmod 777 -R {} \; -exec chown -R YOURUSERNAME:users {} \;
done

If you are in a multi user environment, you should really check wether the permissions (777) are still restricting folder access to others. If you have improvements over my process i’d be happy to hear about them.

TerrorSnake11 · April 30, 2019, 7:12am

Hey Reto,

thanks for your input man! You got the solution for my inotify-problem!

First thing I did was to check permissions in Synology File Station. Everything looked OK. Owner was me, Group sc-syncthing got read/write permissions but inotify-errors in Syncthing.

Looking at the Unix-Permissions, only the Owner got full access (Mode 700).

Then I changed UNIX-permissions to 777 CHMOD 777 -R

Result: After Syncthing-restart inotify-error is gone. Hurray!

Looking again in Synology File Station permissions, the use of CHMOD replaced all former ACL permissions. User “Everyone” got all rights. No big surprise I guess…

I afterwards set the permissions in Synology File Station exactly the same as it was before the CHMOD and everything still was OK.

Conclusion: Setting ACL-permissions in Synology File Station does NOT affect the Unix-Permissions but setting Unix-permissions DOES affect ACL-Permissions!

Solution for inotify:

Take a note of the ACL-Permissions in File Station if you dont want to lose them.
Set Unix file permissions of the sync-folder to 777.
Restore ACL-Permissions in Synology Disk Station.

Regards Andy

ludos · May 7, 2019, 9:16am

Nice you got it working. A important side note:

The commands chown and chmod should only be run on shares, not on the root directory.

chmod 777 -R /volume1/share_name/*

chown -R yourUserName:yourGroupName /volume1/share_name/*

Othervise you may encounter massive problems with your system.

UPDATE!

Also i am not completely sure this fixes all problems, i also had to add sc_syncthing user and group with all permissions to the shares. In my case after new folders were synced, those new folders could not be watched by inotify.

To do this go to the Control Panel:

Shared Folders
Right Click Share, Select Edit
Select Permissions

Switch Local Users to Local Groups (for sc-syncthing group permissions) / … to System Internal User (for sc-syncthing group permission)
for both check Custom and check all Permissions (Admin, Read and Write)

This might even be the only thing you need to do, so you could skip the chown and chmod steps.

For me it seems to work fine now, but do this on your own risk!

Arano · May 8, 2019, 6:10pm

No, it is not the only thing to do. We would not had the problem if it were.

I confirm that the following command work :

find /volumeX/share/ -mindepth 1 -type d ! -path "*/@*" ! -path "*/#*" -exec chmod 777 {} \;

But destroy all SynoACL settings on all subfolders.

The ACL are not destroyed on the root shared folder. Reapply the ACL from this root (use the “Apply to this folder, these sub-folders and files” case from the FileStation permissions GUI) and all is back the way it was, but with Syncthing working !

A minimal script to save all ACL via synoacltool , execute command then re-apply saved ACL might be welcomed for those who have a lot of specifics ACL subfolders. But the behavior might be different from GUI.

BTW : it seems to me that the problem only occurs on BTRFS volumes ?

system · June 7, 2019, 6:10pm

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.