Access Rights Management
In this section you can create, edit and access information of |omv| users, groups and shared folders.
Create or modify users information and configuration of home folders.
The configuration panel gives you options to add, edit or remove users. The grid displays all |omv| current users.
When a user is created |omv| backend executes :command:`useradd` in non-interactive mode with all the information passed from the web text fields, this command also creates an entry in :file:`/etc/passwd`, a hashed password in :file:`/etc/shadow`. Samba service is watching any changes in users database section so it also sets the password in the samba tdbsam storage backend.
The mail field is used for cron jobs when the task is selected to run as specific user. By default users are created with :command:`/bin/nologin` shell, this will prevent local and remote console access.
Add or remove users from specific groups. In linux groups can be used to control access to certain features and also for permissions.
Adding a user to the
sudogroup will give him root privileges, adding a user to
sanedwill give access to scanners, etc. By default all users created using the |webui| are added to the
- Public Key
- Add or remove :doc:`public keys </administration/services/ssh>` for granting remote access for users.
- The user profile information (except password) is also stored in the internal |omv| database, along with the public keys.
- The grid shows information from internal database and also parses information from :file:`/etc/passwd` lines with a UID number higher than 1000. A user created in terminal is not in the internal database. This causes trouble with samba, as there is no user/password entry in the tdbsam file. Just click edit for the user, enter the same or new password, now the user has the linux and samba password synced.
- A user can log into the web interface to see his own profile information. Depending if the adminstrator has setup the username account to allow changes, they can change their password and mail account.
Designed for bulk user creation. Create a spreadsheet with the corresponding data as
described in the import dialog window, save it as CSV (make sure the field separator is semicolon
;), then just
$ cat usersfile.csv
# <name>;<uid>;<comment>;<email>;<password>;<shell>;<group,group,...>;<disallowusermod> user1;1001;user1;email@example.com;password1;/bin/bash;sudo;1 user2;1002;user2;firstname.lastname@example.org;password2;/bin/sh;;0 user3;1003;user3;email@example.com;password3;/bin/false;;1 user4;1004;user4;firstname.lastname@example.org;password4;;;1
- :file:`/etc/shells` will give you a list of valid shells.
- The last field is a boolean for allowing the user to change his account.
Paste the contents into the import dialog.
The button opens a window that displays all current exisiting |sf| and their privileges for selected user from the grid. How the privileges are stored is described further down in the shared folder section.
Option to select a |sf| as root for home folders for new users created in the |webui|. Previously existing users created before enabling this setting will not have their home folders moved to this new location. You can manually edit :file:`/etc/passwd` to point them to the new location. Also existing users data in default linux location :file:`/home` has to be moved manually.
Bulk import works in similar as user account import. Just a csv text,
delimited with a semicolon
;. The dialog displays the necessary
Just to add or remove members from groups. Default groups created in the
|webui| have a
GID greater than
1000. Same as usernames, groups created
in terminal are not stored in the internal database. Just edit, insert a
comment and their information should now be stored in
When a |sf| is created using the add button, the window form displays the following options:
- Name: The logical name. This can override the path name. Typing a name here will fill the path with the same string.
- Device: The parent filesystem associated with the |sf|.
- Path: The relative path to the mounted device. To share the whole disk just type
- Permissions: The default descriptive text will create the |sf| with
Logical name Octal mode Administrator: read/write, Users: no access, Others: no access 700 Administrator: read/write, Users: read only, Others: no access 750 Administrator: read/write, Users: read/write, Everyone: no access 770 Administrator: read/write, Users: read only, Everyone: read-only 755 Administrator: read/write, Users: read/write, Everyone: read-only 775 (Default) Everyone: read/write 777
This is how a |sf| looks inside the
Some of the elements explained:
- uuid: Internal database reference number.
- name: logical name given to the |sf|.
- mntent: the associated filesystem reference. The number is in the
uuidformat, the fstab section in
config.xmlshould contain a
<mntent>reference with this number.
- reldirpath: Path relative to the parent filesystem.
- privileges: Users associated with the |sf| and their access level.
When a plugin or a service uses a |sf| it stores the uuid value only. Later on
using helper scripts or internal |omv| functions the full path can be obtained
just by using the
uuid. An example in shell:
$ . /usr/share/openmediavault/scripts/helper-functions && omv_get_sharedfolder_path 9535a292-11e2-4528-8ae2-e1be17cf1fde
More information about helper functions.
A shared folder can be used across all over the system backend. Is available to select it in sharing services (FTP, Samba, RSync, etc.) at the same time. Plugins can use them also just by using the shared folder combo class.
- A |sf| belongs to an internal |omv| database filesystem entry. Is not possible to unmount the filesystem without deleting the folder configuration from the |webui|.
- If a |sf| is being used by a service (FTP, plugins, etc.) is not possible to delete it. Is necessary to disengage the |sf| from the service(s) or section(s) that is holding it before proceeding with removal. This will also prevent to unmount a device from the |webui| in the filesystem section if there is still a |sf| associated with it.
- Due to the design of the software is not possible at the moment to know what section or service is holding which |sf|.
Edit |sf| is possible, but it has some limitations. You can only change the parent device volume. Once the parent device is changed the backend will reconfigure every service that is using a |sf| and stop/start daemons accordingly.
Be aware that changing the parent device volume will not move the data from one filesystem to another.
NFS Server: Editing the parent device will not descent into :file:`/etc/fstab`. Make sure you edit the share in the NFS section so the bind can be remounted.
As you can see from the code block in the add section privileges are expressed in the internal database in the same manner as permissions in Linux, simplified using the octal mode: read/write(7), read-only(5) and no access(0).
If a privilege is changed, it means a change in the |sf| database section. This database event will trigger a reconfiguration of SMB, FTP and AFP, it will also restart all the above daemons. A plugin using |sf|, but not the privilege information from the database entry should not get reconfigured/restarted if a change occurs just in privileges.
ACL (Access Control List)
Provides fine grained permission control besides the standard POSIX permissions. The usage of ACL is not recommended for the average home user. If a server is using an extensive list of users then ACL could suit better  .
The expanded ACL window displays three panels. Left one is a browser of the selected |sf|, so you can see the apply ACL to the current folder or a subdirectory and so on.
The left panel displays all current |omv| users and system accounts and their current ACL of the selected folder. This panel actually reads ACL from the selected folder.
The bottom panel displays the standard POSIX permission of the selected folder or subfolders in a user friendly interface.
If you want just to reset linux permissions, just use the recursive checkbox and change options only in the bottom panel, and not selecting any ACL user/group in left panel.
- |omv| mounts all Linux filesystems with ACL enabled. Only native linux POSIX filesystems support ACL. The button gets disabled for HFS+, NTFS, FAT, etc.
- ZFS provides ACL support, just need to enable the pool/dataset property.