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

(Andy) #1

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 :frowning:

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. :slight_smile:

Kind Regards Andy

(Simon) #2

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.

#3

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

See :

(Andy) #4

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 :slight_smile:

Hope someone will come up with the solution.

(Reto) #5

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.

(Andy) #6

Hey Reto,

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

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:

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

Regards Andy

(Reto) #7

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!

#8

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 ?