Our thinking


Recursively Propagate Permissions on a Synology NAS with synoacltool

Synology DSM lets you do some pretty complex things with permissions on files and folders, however occasionally things can get a bit mixed up and it’s difficult to see what’s happening and even more difficult to recover from it.

Whilst you can go into the DSM web interface and check the permissions at the top level of each share point in Control Panel > Shared Folder, it’s difficult to see what’s going on below this.

To dig deeper we need to get into the command-line, so you first have to enable ssh access. Go into Control Panel > Terminal & SNMP and Enable SSH service

You can now ssh into the Synology as an admin user (provided your firewall rules on the NAS allow it)

I found that if you modify the permissions on a file or folder with chmod then this seems to wipe out the ACL information. Never mind, there’s another utility called synoacltool that lets you modify ACLs. Unfortunately however synoacltool doesn’t have a switch to operate recursively.

Unix find to the rescue!

What I was able to do however was use find to run it on each and every file and folder in a given folder – this likely isn’t the most efficient way to do it, but you (hopefully) don’t need to do this too often anyway…

First, wipe out the ACLs and set the unix permissions with chmod

chmod -R a+rwX /volume1/Share\ Point

Set the permissions on your share point in DSM and check it in the terminal

ls -ale /volume1/Share\ Point

I got this far, however when I checked the permissions on the files and folders inside Share Point they still had plain ol’ unix permissions and no acls

cd /volume1/Share\ Point

ls -ale

no ACLs. Let’s get them happening.

find . -execdir synoacltool -copy /volume1/Share\ Point {} \;

What this does is find each file and folder and then run the exec command on the given file or folder – so it copies the ACL from our top-level folder onto every single file and folder in the Share Point folder.

There’s quite a lot of overhead in doing it this way, but hopefully you only need to do this once and then the permissions will work…

9 thoughts on “Recursively Propagate Permissions on a Synology NAS with synoacltool

  1. Wouldn’t it make more sense to not copy the ACLs but to inherit them? I personally prefer

    find /volume1/Share\ Point -mindepth 1 -execdir synoacltool -enforce-inherit {} \;

    I additionally would recommend to exclude some dirs like @eaDir, #recycle, #snapshot

    find /volume1/Share\ Point -mindepth 1 ! -path '*/@eaDir*' ! -path '*/#recycle*' ! -path '*/#snapshot*' -execdir synoacltool -enforce-inherit {} \;

  2. Hello and greetings from Holland.

    When using large amounts of data, you may suffer buffer-overflows by ‘find’. I personally prefer sticking the result of ‘find’ into while-loops and not the exec. As the find-command will be put into 1 array, which often does not fit when using big data. Better is to use line-by-line.

    Like:
    find . whatever_you_want | while read line; do synoacltool -enforce-inherit “$line”; done

  3. So I’ve got a really weird problem. I moved a folder from /volume1/old_share to /volume1/homes/myuser/old_share because I wanted to look at it, then delete it. Thought that would be a little simpler.

    Sure enough, no ACLs and I can’t delete the directory. Your post was super helpful. I added ACLs. I can see that my old_share directory now as the same ACLs as other directories in my user directory. (Using ls -le, the ACLs are the same, down to the letter. I’ve copied and pasted them into a text editor to look at each character.)

    But I still can’t delete the directory. I get:

    rm: cannot remove ‘old_share’: Operation not permitted

    I’m at a loss. I even logged out and back in via ssh. No luck.

    Is there something else? Am I supposed to reboot the NAS?

    Feeling dumb and clueless…

  4. Revisiting this – the “proper” way to do it is with xargs, so that whitespace and other funky characters are handled properly:

    find /volume1/Shared\ Folder/Foldername -print0 | xargs -0 -n1 synoacltool -enforce-inherit

    or, if running it at the top level…

    find /volume1/Shared\ Folder/ ! -path ‘/@eaDir‘ ! -path ‘/#recycle‘ ! -path ‘/#snapshot‘ -print0 | xargs -0 -n1 synoacltool -enforce-inherit

  5. So again, I’ve tried the method in your original post and the the “proper” way you’ve outlined. As far as I can see, the directory has exactly the same permissions and ACLs as it’s parent. The owner is root. I’m logged in as root. When trying to delete, both with rmdir (it’s empty) and rm -rf, I get the message: ‘Operation not permitted.’ I’m at a total loss and ready to give up. I guess an empty directory won’t hurt me. Weirdest thing.

  6. Revisiting this – I had a synology recently where the permissions where completely out of whack. After a couple of attempts at repairing it from the command line, which took over an hour each time to recursively run and didn’t work 100%, I then had a go at doing it in the GUI in DSM.
    I logged into DSM and went to File Station > Shared Folder Name > Right-click > Properties > Permission on the top-level folder inside the shared folder.
    I set the permissions as I wanted them to be and ticked the checks to Apply to this folder, sub-folders and files.
    This ran considerably quicker than the recursive jobs in the Terminal and, so far, it seems to have actually propagated the permissions correctly.

    So, for future reference, don’t bother with doing it in the Terminal unless you absolutely have to – just use the GUI.

Leave a Reply to Jay Cancel reply