Awasu » Managing permissions in Open Media Vault
Sunday 4th October 2015 6:39 PM []

Managing file permissions, to control access to files on the NAS, is probably the trickiest thing to understand about OMV. The definitive articles on the subject are this one and this one, but they're fairly dense and a bit difficult to grok, even if you're a techie.

The TL;DR is this: files on the NAS can be accessed in 2 different ways:

  • Access is made via OMV i.e. using Samba, FTP or AFP[1]Apple Filing Protocol..
    Users have to pass two levels of security, firstly OMV permissions, then the Linux file-system permissions on the files themselves (discussed below).

  • OMV is bypassed i.e. via NFS[2]The Network Filing System is how Linux computers usually access files over a network. or by logging into the bPi and managing files from the console.
    Access is controlled solely via the Linux file-system permissions[3]Since we're accessing the files directly, bypassing OMV, it has no chance to check for permissions..

Accessing files via OMV

The first case is straight-forward to manage; we saw in the previous tutorial how to set permissions on the top-level shared folders in the web admin interface.

I set all my shared folders to be read-only, then applied ACL's to give the special taka-w user write access.

As long as we always manage files via OMV, it will take care of setting the underlying Linux file-system permissions so that everything works properly.

Accessing files outside of OMV

On the other hand, problems will arise if we create files outside of OMV, because the file permissions will be set incorrectly.

First, a quick explanation of how file permissions work under Linux. There are 3 types of permission - read, write and execute - and these can be set individually for 3 classes of user:

  • the owner (typically, the user who created the file)
  • the file's group[4]An administrator can create groups of users, then set file permissions that apply to anyone in that group.
  • everyone else


This is a fairly coarse-grained method of assigning permissions, so many file systems also allow ACL[5]Access Control List's to be applied, which allow very precise permissions to additionally be set for a file e.g.

  • joe has write permission
  • everyone in the managers group has also write permission
  • fred has no access whatsoever
  • everyone else has read permission


Now, let's say we log in to the bPi as the root super-user and create a file in a shared folder that is normally readable by everyone - we won't be able to access that file from another machine, even though it's in a folder that everyone has read access to.

This is because while OMV's Samba and shared folders permissions might say we're allowed to read the file, we also have to pass the file-system security, and the permissions on the file say that only root is allowed access[6]Because root created the file., and so we will be denied access. This can be quite confusing for a user, since they think they should have read access to everything in the folder, and they can read everything in that folder, except for this one particular file.

Fixing up file permissions

There isn't really any way of avoiding the problem described above - if you create files outside of the OMV framework, it's almost inevitable that you're going to do it incorrectly (in OMV's mind), thus causing problems. To work-around this, I wrote a script[7]This script assumes that symlinks have been set up in the /shares/ directory. that resets the permissions on everything in a folder:

#!/bin/bash

# We need this script to fix up permissions for files that have been uploaded
# outside the normal framework e.g. upload to a public share, then moved to
# a protected share via the console, or files that have been scp'ed up.

# parse the arguments
if [ $# -eq 0 ]; then
    shares="music movies backups public" # <== change these to your shared folders
else
    shares=$*
fi

# fix permissions for the specified shares
for share in $shares; do
    echo "`date "+%Y-%m-%d %H:%M:%S"` | Fixing permissions for `echo $share | tr "[:lower:]" "[:upper:]"`..."
    dir=`readlink -e /shares/$share`
    chmod g+s "$dir"
    chown -R root:users "$dir"
    if [ "$share" == "public" ]; then
        chmod -R 770 "$dir"
    else
        chmod -R 750 "$dir"
        setfacl --recursive --modify user:taka-w:rwx --modify mask:rwx "$dir"
    fi
done
echo "`date "+%Y-%m-%d %H:%M:%S"` | All done."
echo

This script does the following:

  • sets the sticky bit on the top-level shared folder, so that all files and directories underneath it inherit the group owner of the folder i.e. users.
  • sets the owner of every file and directory to root, and the group to users. This locks down access to files if OMV is being bypassed (since they are owned by root), but OMV can still apply its own permissions to them (since every user create in the web admin interface is added to the users group).
  • for the public share, everything is set to have 770 permissions i.e. root and the users group both have read/write/execute permissions.
  • for every other share, everything is set to have 750 permissions i.e. root has read/write/execute permissions, the users group (i.e. all OMV users) have write/execute permissions.
  • for every other share, we also set an ACL on everything that gives our special taka-w user read/write/execute permissions.

The net effect is:

  • all users have read access to everything, except the public share, which everyone can also write to.
  • the special taka-w user has write access to everything.
  • everything is owned by the root super-user, to lock things down if OMV is bypassed[8]Although if you log in to a console using an OMV account, you will have the normal read-only access..

Making sure file permissions stay fixed

We can now get OMV to run this script on a regular basis by scheduling a job in the System/Scheduled Jobs tab of the web admin interface.

I've configured my job to run 15 minutes past every hour. It also logs any output to a file.

Now, if I create files or directories from the console, the permissions will be wrong but some time in the next hour, the script will be run to fix everything up. Not great, but acceptable.

« Configuring Open Media Vault

Tutorial index

Managing a Banana Pi without an internet connection »

   [ + ]

1. Apple Filing Protocol.
2. The Network Filing System is how Linux computers usually access files over a network.
3. Since we're accessing the files directly, bypassing OMV, it has no chance to check for permissions.
4. An administrator can create groups of users, then set file permissions that apply to anyone in that group.
5. Access Control List
6. Because root created the file.
7. This script assumes that symlinks have been set up in the /shares/ directory.
8. Although if you log in to a console using an OMV account, you will have the normal read-only access.

23 Responses to this post

Thanks for this page, it really helped. Now I just run a nightly job to reset my permissions, I didn't use your script as my needs are way simpler but it taught me the way OMV handles file permissions and what they need to be to work.

No worries, glad it helped :)

Thanks for this nice tutorial.
However, as I am a Noob in Linux, I do not found how to use your script. where to save it and what extension ?
I use OMV 3.0.46 and gave full access for a little NAS HD in Fat32 used by two persons - Read Write -.
Work fine the first time I created the Nas, but after a clean reboot, I lost permissions to write from Windows 7 or 10.
smb.conf revert to 644 ..
Can you explain me how to insert the script ?
Thanks

You can save the script wherever you want; I usually put it in a sub-directory under my home directory (~/bin/).

The extension doesn't matter, it's the first line of the script (#!/bin/bash) that tells the system how to run it. Just make sure the file is executable (chmod +x).

It works !
Thanks a lot for clarification. Just make it 3 hours ago and after reboot and waiting I am able to write on my HD... :)

No worries, glad you found it useful :)

Hi,
I see that this thread is a couple of years old, but I need some help, so maybe I'll get lucky.

I am new to Openmediavault, and have installed a Plex server, which is running ok. My previous Plex server is running on my Windows PC, and I am trying to move my libraries over to the Openmediavault as soon as I can to free up resources on the Windows PC.

I am trying to use a Windows mapped network drive to read/write to the shared folders on the OMV server. They work, but it has become apparent that file permissions is going to become an issue. File permissions are set via the Windows login to the mapped drive, so as is, the plex server can play the media files, but can't delete them. And, just to make this interesting, I want to use a Windows file conversion app called MCEBuddy, which monitors traffic on a windows folder and converts .ts files to .mkv files on the fly. That's why I want to use the mapped drive on Windows.

So, your script above looks like a likely fix for getting this working, periodically going to my shared folder and changing permissions, in this case to owner=plex group=users (or maybe plex). However, I can't get your script to work. It seems not to find the directories or files, and gives me errors...chmod: cannot access `': No such file or directory. setfacl: Option -m: Invalid argument near character 6. I'm lost.
Thanks

My first guess would be that the script has hit a file with a funny name that's causing problems.

Add a "-v" to the chmod command, so that it prints out the name of each file as it's processed, and you'll be able to see if it fails on the every file, or if it processes a lot of files, but fails on just a few. In the latter case, you can change the script to be able to handle them (or just rename them :-)).

My setfacl doesn't have a verbose option, but yours might. A thought: have you maybe typed in "-modify" instead of "--modify"...?

I copied it to the editor, so there were few chances to mistype. I did finally notice your footnote about having symlinks set up. Doing that allows the script to complete. I still get setfacl: Option -m: Invalid argument near character 6. I don't really understand the setfacl command, but the help info on my system appears to use -R and not --recursive, and -m and not --modify. Is this something I could try safely?

chmod -v seems to list every file as retained. Of course I've run it several times. No files have changed.

I did revise the chown to chown -R PlexUser:users. This is running now, but just a bit kludgey.

ACL's control access to files, over and above the normal read/write/execute permissions that chmod handles. In the script I wrote, I use "--modify" to change the ACL's on each file - if your version of setfacl uses "-m" (and that's common), you should be OK.

As luck would have it, I'm setting up an OMV server right now, and got exactly the same error you did (option -m: Invalid argument near character 6). Turns out, it was an invalid user name i.e. I was trying to assign permissions to a user that hadn't been created yet.

Pretty woeful error message :-/

In my case it was erroring on the user taka-w, as I had cut-and-pasted your script in.

Hello!
First of all thank you for this very well written tutorial.
This is quite an old post, but hopefully you are still around and this script still works in the newer version of OpenMediaVault.
I seem to have some permission errors and it's one of the main reasons I'm still not 100% commited to OpenMediaVault for my media server OS.
This is all started when I created my shared folders and created sub-directories inside them via WinSCP. At the time SMB wasn't working (due to the latest windows update and SMB 1.0 not being installed by default). So once I got SMB working, I saw the main shared folders in windows explorer that I created via the OpenMediaVault but not the sub-directories. After some reboots, I didn't even see the sub-directories in WinSCP. Now I can see them only via Cloud Commander which is a very useful file browser that I added via docker. So I am sure that these sub-directories exist as I can see them on Cloud Commander and are even being read by PLEX.

I assume the reason is basically what you described in your post.
I've tried doing what you mentioned but it doesn't seem to be working.
I will describe to you what I did and hopefully you can find an error and I can get this up and running just how I like it (do bare in mind, I'm a complete linux newbie, so I can access my server via terminal, but any specific commands you want me to run you will have to type out exactly):

1) Add the script you wrote and changed the shares to the names of my shared folders in OpenMediaVault; also changed taka-w to the user I use in OpenMediaVault (which has read and write permissions in all shared folders). I created a file in /bin/ with the name fix-permissions.sh and copied the edited script inside it and saved it.

2) Added the scheduled job (system -> scheduled jobs) like this: https://i.imgur.com/Jn9uB9y.png
The text in the command field is: /root/bin/fix-permissions.sh 1>>/tmp/fix-permissions.log 2>&1

3) Pressed save and apply.

I would REALLY appreciate any help you can give me, as this has been giving me a headache for quite a while and as I previously mentioned it's the reason I haven't completely migrated over to OpenMediaVault for my server needs.

Thank you for your time.

Yah, I'm still here. I'll be Awasu'ing until the end of time... :-)

I suspect you haven't set up the symlinks in /shares. It's not enough to just change the name of the shared folders in the script, there must also be a symlink /shares/XXX for each shared folder XXX.

Otherwise, does the script work if you run it manually? You should see log messages of the form:
Fixing permissions for XXX...

Also, your scheduled job runs /root/bin/fix-permissions.sh, but you said you put the script in /bin/.

BTW, I should point out that you don't necessarily have to run this script. I use it because I'm constantly moving files around outside of OMV, but if you only ever use Samba and WinSCP and Cloud Commander - and this is how you *should* be doing things - then you won't need it. OMV will take care of everything for you, and it will all Just Work (TM).

Thank you for your responses.
One thing I should add is that I'm running MergerFS and Snapraid, but all of my shared drives are in the shared pool.
I tried to run the scheduled job and got this error:
Failed to execute command 'export PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin; export LANG=C.UTF-8; export SHELL=/bin/sh; sudo --shell --non-interactive --user=M18XR2 -- /bin/fix-permissions.sh 1>>/tmp/fix-permissions.log 2>&1 2>&1' with exit code '127':

It's interesting you should say that it should work. Because I've only ever moved and created files via WinSCP, CLoud Commander and SMB and it most definitely is having an issue (as I described above). Well, now that I think of it Sonarr and Radarr also create folders as they need to for media and those are also folders I cannot see.
Hopefully you can help me find a fix and I can finally migrate all my media to the new server.

Thanks!

To add to my previous message, I changed the path in the scheduled job to /bin/ and not /root/bin/.

Scheduled jobs (i.e. cron jobs) are notorious for not working in exactly the same way as when run from a terminal. Get things working when run from the terminal first, then schedule a job.

If you only ever do things via channels that OMV officially supports (e.g. Samba, SCP, FTP, etc.), then OMV will take care of everything for you, and yes, everything should work. But you've been running my script, which is changing permissions on files and directories, which may have confused OMV.

It sounds like you're running a fairly complicated setup, with lots of moving parts, and every new thing you introduce is another thing that could possibly go wrong. Are you using a single OMV user account for all these programs you're using? My first guess would be that you've used multiple accounts, and the permissions for them are maybe not compatible with each other.

I currently 2 accounts on OMV. I will remove one of them as we speak, leaving only the M18XR2 account as the main one and M18XR2 is now the main one.
I doubt your script did anything to confuse the system more than it already was. Before using your script I already had this problem and could only access the files created via OMV through SMB and WinSCP. Cloud Commander is the only one that already showed me all the files.

I went via the web terminal (shellinabox) and logged in as M18XR2.
Inserted the following command:
sh /bin/fix-permissions

I get the following error: sh: 0: Can't open /bin/fix-permissions

Also here are the contentes of my script, just to make sure nothing there is wrong:

/bin/
/
#!/bin/bash

# We need this script to fix up permissions for files that have been uploaded
# outside the normal framework e.g. upload to a public share, then moved to
# a protected share via the console, or files that have been scp'ed up.

# parse the arguments
if [ $# -eq 0 ]; then
shares="AppData Users Virtualfolder config downloads media watched" # <== change these to your shared folders
else
shares=$*
fi

# fix permissions for the specified shares
for share in $shares; do
echo "`date "+%Y-%m-%d %H:%M:%S"` | Fixing permissions for `echo $share | tr "[:lower:]" "[:upper:]"`..."
dir=`readlink -e /shares/$share`
chmod g+s "$dir"
chown -R root:users "$dir"
if [ "$share" == "public" ]; then
chmod -R 770 "$dir"
else
chmod -R 750 "$dir"
setfacl --recursive --modify user:M18XR2:rwx --modify mask:rwx "$dir"
fi
done
echo "`date "+%Y-%m-%d %H:%M:%S"` | All done."
echo

Thanks!

The problems you've been having suggest that the script hasn't actually been running and/or doing anything. If this is the case, this is good news, since it means it hasn't made any changes to your file system.

I would strongly recommend that you stop trying to run my script, and fix the permissions problem via OMV. The most likely explanation is that you created files/folders using one account, then tried to look at them using another account, which didn't have permissions to do so. IOW, everything is still in OMV-land, and so should be fixed there. If you manage to get my script to run, the chances of fixing things are slim, and are far outweighed by the chances of messing up your file system beyond repair.

At this point I'm just going to reinstall or try something else.

Thanks for your time!

would this translate as well to the group "domain users" in a Samba4 Active Directory deployment? I want to use OMV to host the windows profiles for roaming profiles but don't understand how since the share's permissions are 777 (just for testing) and it doesn't work.

>>> I want to use OMV to host the windows profiles for roaming profiles

This might be possible, but probably wouldn't be a good idea. It's a consumer-grade file server, you should probably use something better suited for enterprise use.

Have your say