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…
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 {} \;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
That’s a good tip. I’m sure you could use xargs as well, but your way looks like it would work well.
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…
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
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.
This is indeed very strange – it might be worth contacting Synology support for this one…
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.
I presume this is now old information.
chmod does indeed off recursive changes to file attributes including ACLs, and is fast
checkout chmod –help for details, similar syntax to synoacltool (+/-a[#]), adds/removes ACL [# by number]
For more information abou ACLs either use synoctltool –help or visit the current relevant Synology web page
Use find to tidy up any specifics or as @Kai Howells use the GUI, which is fast than using find.
Yes, this post was originally from back in 2016, I’m glad to see that Synology have improved the situation somewhat. Thanks for the updated information.
I’d love to use this to create a scheduled task to fix a permission issue that sometimes pops up on my NAS and I’m unable to find the cause of. However the script doesn’t set permissions on files, just folders. How do I get it to inherit permissions from the main folder to all subfolders AND files?
I have a folder called docker and I need all files and folders below it to inherit all permissions, I’ve used this command:
find /volume1/docker/ -type d -exec synoacltool -enforce-inherit {} \;
I originally used the command-line to do this, as it was faster than the GUI. I had occasion to do this again recently on a new NAS with DSM 7 and found that using the GUI to perform the task was significantly faster than doing it via ssh. I know this doesn’t help you with a cron job to reset permissions, but when I was using the tool a couple of years back, I’m pretty sure it modified the ACL on files and folders.