Privileges and permissions explained under OMV
The current guide is provided to explain how OMV controls user access to the remote shares.
OMV provides in their default core four file sharing subsystems. These subsystems are:
NFS Network File Sharing, standard *nix network file sharing since very old times
Samba (CIFS/SMB) – Server message block (SMB)is a file sharing protocol developed by IBM in the eighties to provide read/write files to remote shares in a LAN environment.
Common internet file protocol (CIFS) is Microsoft own implementation of the SMB protocol. Since Vista 2006, Windows versions now come with SMB 2.x. version of the protocol. Samba is another implementation of SMB developed for UNIX machines to allow windows clients to access UNIX folders in LAN environment. To the day, Samba has been ported to run on multiple environments and is a standard in most Linux distros by default. OMV comes with Samba services for sharing. This sharing protocol is intended to use in local network environments, but they can easily cross networks with the aid of a VPN.
FTP – File transfer protocol, Standard network access file protocol across external (Internet) and internal networks (LAN’s)
AFP - Apple Filling protocol, is a file sharing protocol developed by Apple. Is believed that Apple will drop AFP towards SMB, in future releases.
The last three of these file sharing systems provide user/password authentication to control access to shares. NFS relies on remote – local UID/GID matching to control RW permissions. For that effect NFS will not be covered in this guide.
Users in OMV:
Every new user created under OMV webUI, is incorporated into their primary group users. This is default behavior, and cannot be changed from the webUI.
Every user created under the OMV webUI requires creating also a password. This password creation and/or post modification will transverse all of the three file sharing systems. OMV will sync them automatically. For general knowledge purposes OMV syncs passwords with smbpasswd only. FTP and Netatalk use a PAM module.
Every user can change to their own custom password accessing a trimmed version of OMV at the webUI interface when they use their login credentials.
Privileges under OMV:
For every share created in OMV you can setup their basic privileges. Under those privileges you can select three options: read-write (rw), read only (ro) and no access (-)
You can notice either you can set privileges under shared folder section or under the user sections. A change in User section will be reflected in Shared Folders sections and vice versa. We can always see at the bottom privileges window a little note that states:
“These settings are used by the services to configure the user access rights. Please note that these settings have no effect on filesystem permissions.”
That’s right, these privileges have absolutely no effect in the core file system layer where they belong (let that be ext3, ext4, xfs, or jfs). Every change you do in privileges section, OMV will not execute a single chmod or a chown over that folder. For general knowledge purposes every share created under OMV webUI is created with default 2775 permission, with a root:users folder ownership. The number 2, is the setgid bit. This will cause all files and directories underneath to inherit the group owner of the folder, in this case users.
When users access a sharing service they have to pass two levels. First the the directives from the services apply for login and read write access, then the standard POSIX permissions apply as usual into folders and files.
This is very important, OMV works with those previous default permissions for the shares, any changes to the group permission bit and ownership will turn into a non-working share. So we recommend that DO NOT CHANGE THIS.
Also to notice is that every user password change in OMV is going to transverse across the three sharing systems. OMV syncs the passwords automatically. The reality is that OMV syncs the password only with smbpasswd, ftp uses a PAM module so does AFP
How is OMV controlling user access then? For every rw, ro or no access tick box, OMV will perform a change in the configuration file that controls each particular daemon (AFP, SMB or FTP). These services provide their own layer of restrictions on top of the file system.
In this case OMV will look in particular for smb.conf, proftpd.conf and AppleVolumes.default configuration file to set up their respective permissions in their system.
Let’s pick the alpha folder and share it across the 3 sharing systems. Now we will give bill, steve and torvalds RW access.
Now let’s look at each configuration file. We start with ftp (proftpd.conf)
All users allowed to, no restrictions. Now let’s peek at SAMBA (smb.conf), no invalid users and write allowance
And finally netatalk (AppleVolumes.default), looks different but we see no restrictions there. If we must deny access then to others users different than steve, bill or torvalds then you should mark as deny access in privileges. A better option would be to put them in a group.
Let’s deny bill access to the alpha share and set torvalds read-only. We go to the share privileges, mark, save and apply. Will need to restart all the daemons for proper configuration reload.
Let’s look at netatalk again. Self-explanatory
Now let’s look at smb.conf and proftpd.conf below
Notice that in FTP, the user bill has been removed from the configuration, he will still be able to log into ftp, but he won't see the share.
Groups and Users
You can assign privileges to groups the same way we do with users. Group’s privileges have different behaviour in the three systems; some of them prevail over the user privilege in different scenarios.
The next contingency table shows the behaviours across them. For example row 4, if we set the share folder with read only for group and no access for user, then proftpd will let the user see the share, samba will not allow displaying it. This happens because Samba and Netatalk use deny lists for No Access. FTP doesn't have that option but it can be achieved with non-default OMV directives.
Group permission prevalence
This guide is intended to explain the simplified privileges concept that OMV tries to achieve. Is not the scope of the current guide to explain ACL, which they can provide much more granular access control and is also more intended to use within LDAP environments.
As we mentioned before, granular permissions are somehow tricky in this simple privilege scenario. For example let’s say we have a share, inside that share we have several folders containing different projects for each folder. Each folder contains documents inside, but let assume inside one of each project folders, we have a sub-directories containing null documents, non-valid or obsolete files. Let the hierarchical folder structure screenshot below explain:
We will hide every single folder named null_docs and their contents. If we go to Samba share settings, we can look at their individual share settings (edit button). We have a text box down below. In that text we can input more samba configuration directives. In this case we are using one named called veto files (you can take a look at samba.org for more directives)
Now we save, apply, restart the daemon (simply adding the directive won’t make any effect) and check our mounted drive, every single folder name null_docs is now going disappear from the user using the share in SMB. Notice here that you won’t have access, even by filling the path.
If you want exclusive access to those null_docs folder just share again the same folder in SMB with another name, without putting that directive.
All files submitted by different users to the shares will have different ownership and just read only permission for the other users. Is like having the sticky bit in the folder. Your files won't be able to be deleted or edited by others, that behavior can be enabled or disabled with the Inherit Permissions directive.
In FTP we can achieve the same using the HideFiles "(\null_docs)$" directive inside the share folder configuration. Notice to put two spaces in front to apply the correct indentation inside the directive
Let’s look then with WinSCP,
For netatalk, in the extra options we can input veto:null_docs/