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.

6 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 🙂

Have your say