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 AFPApple 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 NFSThe 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 permissionsSince 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 groupAn 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 ACLAccess 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 accessBecause 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 scriptThis 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 bypassedAlthough 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
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.|