Differences

This shows you the differences between two versions of the page.

--- nas_permmissions_in_omv [2021/02/22 20:38] – [A Workstation Logon] crashtest
+++ nas_permmissions_in_omv [2021/04/27 21:37] – [NAS Permissions In OMV] crashtest
@@ Line 1: / Line 1: @@
-{{ :underconstruction.jpg?400 |}}
 <html><center><strong>Getting Started with:</strong></center></html>
@@ Line 8: / Line 5: @@
-====== NAS Permissions In OMV - A Primer ======
+====== NAS Permissions In OMV ======
 \\
 \\
-If preferred, this document is available in PDF form at this location → [[https://github.com/OpenMediaVault-Plugin-Developers/docs/blob/master/Getting_Started-Permissions.pdf|Getting Started - Permissions]]
+This document can be converted to a PDF file, in the user's language of choice (see the following), on Windows, Mac's and popular Linux desktop platforms. Simply select the printer icon on the upper right corner of this web page. When prompted at the client, select “print to PDF”, name and save the file.\\
+\\
+[[https://translate.google.com/|Google Translate]] kann Wiki-Dokumente in Ihre Sprache übersetzen. Fügen Sie die Wiki-URL in das linke Fenster ein und öffnen Sie den übersetzten Link rechts.\\
+[[https://translate.google.com/|Google Translate]] puede traducir documentos wiki a su idioma. Pegue la URL de la wiki en la ventana izquierda y abra el enlace traducido a la derecha.\\
+[[https://translate.google.com/|Google Translate]] peut traduire des documents wiki dans votre langue. Collez l'url du wiki dans la fenêtre de gauche et ouvrez le lien traduit sur la droite.\\
+[[https://translate.google.com/|Google]]翻訳はwikiドキュメントをあなたの言語に翻訳することができます。 左側のウィンドウにwikiのURLを貼り付け、右側の翻訳されたリンクを開きます。\\
 \\
 ----
@@ Line 92: / Line 94: @@
 ===== Shared Folder Permissions =====
 \\
-By default, the majority of files and folders on the OMV file server are owned and accessed solely by the root user account.  Since that is not useful in a networked environment, user access to a NAS server storage location is changed by the creation of a “**Shared Folder**”.  Creating a shared folder is covered in the New User's Guide under [[https://openmediavault.readthedocs.io/en/5.x/new_user_guide/newuserguide.html#setting-up-a-sf|Setting up a Shared Folder]]. This process physically creates the folder and assigns usable permissions to the folder, that allow regular user access.\\
+By default, the majority of files and folders on the OMV file server are owned and accessed solely by the **root** user account.  Since that is not useful in a networked environment, user access to a NAS server storage location is changed by the creation of a “**Shared Folder**”.  Creating a shared folder is covered in the New User's Guide under [[https://openmediavault.readthedocs.io/en/5.x/new_user_guide/newuserguide.html#setting-up-a-sf|Setting up a Shared Folder]]. This process physically creates the folder and assigns usable permissions to the folder, that allow regular user access.\\
 \\
 The default permissions assigned to a new Shared Folder, in OMV's GUI, are:\\
@@ Line 101: / Line 103: @@
 These permissions directly correlate to the following:\\
 \\
-{{ :6-perms-sharedfolderperms.jpg?400 |}}
+{{ :6-perms-sharedfolderperms.jpg?600 |}}
+\\
+As previously noted and illustrated, all users are added to the Group users by default.  In the example provided above, **Fred**, **Mary**, **Johnny** and **Betty** will be able to “**write**” to the folder “**Test**”.\\
+\\
+**In the interests of clarity**:
+  * What is shown as **Extra options** (above) are **standard Linux permissions**.
+  * For home server use and to keep server permissions simple, **use standard Linux permissions**.
+  * What is labeled as **User/Group permissions** (above) are **ACL's (Access Control List)**.  **Do not mix ACL's** with standard Linux permissions, without understanding the **//exact//** effects.
+  * “**Others**” means any user that is not **root** or any user that is NOT in the Group users.  This includes members of other Groups and **anonymous** login's.  **Others**, in this example, have **Read**.\\
+\\
+----
+\\
+===== Samba (SMB) Network Shares =====
+While a **Shared Folder** is a “base” for sharing files, it is only one part of sharing data.  A Shared Folder allows for local access, at the server, but it doesn't allow for network sharing.  Network sharing requires a Samba share known as “**SMB/CIF**” in OMV's GUI.
+(There are other network sharing techniques, such as **NFS** shares, that are not covered in this document.)\\
+\\
+{{ :7-perms-shared-smb-layers.jpg?600 |}}
+\\
+As noted in the illustration, a SMB share is layered onto a Shared folder to allow network access to LAN clients.\\
+\\
+----
+\\
+**In the following; Samba**, under **Services**, **SMB/CIF**, in the **Settings** tab is assumed to be **Enabled**.\\
+\\
+Under **Services**, **SMB/CIF**, in the **Shares** tab, click on the **+Add** button.
+  * **Shared Folder:**
+In this case, we're layering a Samba network share on top of the “Test” Shared Folder, previously created.
+  * **Public:**
+In this case, the entry selected is No.\\
+\\
+{{ :8-perms-samba-share.jpg?600 |}}
+\\
+  * In the **Test** Shared Folder, we allowed** Others** “**Read**” access.  The SMB (Samba) network share is layered on top of the “**Test**” Shared Folder.  **Others** with **Read access**, in the Shared folder, equates to “**Guests Allowed**” in Samba.  However, the SMB setting “**Public - No**” will stop anonymous or unknown users at the network share.  This is what was meant by, “Samba can be more restrictive” than base level Shared Folder permissions.
+  * If the SMB **Public** field is set to “**Guests Allowed**”, that would combine with the “**Test**” Shared Folder permission **Others – Read**, to allow network guests **Read** access.  (These permissions; **Others – Read** in the Shared Folder and **Guests Allowed** in Samba are appropriate for a media share.  Network guests would have read access to media, music, movies, etc.)
+  * Beyond **Public access** choices, Samba assumes that appropriate user permissions have been assigned to the bottom layer, at the Shared Folder level.
+  * If **Read only** is **ON** (green), **users** with **write** access to the Shared Folder, will not be able to add (write), modify or delete files.  (There are exceptions.  More on that later.)\\
+\\
+----
+\\
+Scroll to the bottom of the **Add share** dialog box, using the slider bar, on the right, or the down cursor key.\\
+\\
+The **Hosts allow**'ed and **Hosts deny**'ed fields are workstation level access control options.  While these options may fit some use cases, they can make permissions excessively “complicated” for some of the reasons following.\\
+Understanding permissions effects, specifically the combination of various settings, is important.  Again, Samba can further restrict but it can't override and “increase” access. Some examples are:
+  * If a “host is allowed” but the username doesn't have access, the result is **denied**.
+  * If a host is denied but the username has access, the result is still **denied**.
+  * Consumer router behavior is not always consistent.  If a host is specified by IP address, but the client uses DHCP, the IP address may change.
+  * Many consumer routers do not consistently map host names to IP address which may make “allow” or “deny” by host name inconsistent.\\
+\\
+For these reasons and more, host entries should NOT be used without closely considering their effects.\\
+\\
+{{ :9-perms-samba-share2.jpg?400 |}}
+\\
+**Extra options:**  This field presents home and small business administrators with some interesting options for share administration.  For example, in the upper half of this Samba dialog box, there is the option for **Read only**.  In a Samba share, the **Read only switch** will further restrict the group **users** to **read only** access, even if the Shared Folder below allows **write** access.\\
+\\
+However a “**write list**” will allow an administrator to selectively bypass the Samba **Read only** switch.  In this case if the statement **''write list=Fred''**  is added to the **Extra Options** field, the user **Fred** will have **write** access while the rest of the Group **users** will still be restricted to **Read only**, enforced by Samba's **Read only switch**.\\
+\\
+The same could be done for the Group **users**  with **''write list=@users''**
+Adding this statement would allow the entire Group **users**, **write** access while restricting **Others** with the **Read only switch**.\\
+\\
+----
+===== ACL's - Extended Permissions =====
+\\
+==== General ====
+\\
+**Extended Permissions** are not native to Linux.  They are “add-on's” that are stored with a file or folder in their extended attributes.  They are referred to as “Extended permissions” or “ACL's” (Access Control List), interchangeably.  Extended permissions grant or deny file/folder access based on user or group “names”.\\
+\\
+Again, note the following:\\
+\\
+{{ :10-acls_versus_standard.jpg?600 |}}
+\\
+Where possible, use **Standard Permissions** (labeled as **Extra Options**).\\
+\\
+----
+\\
+In the context of a NAS, used as a home server, ACL's should be avoided.  Mixing Standard and Extended permissions can cause inexplicable effects, if not done carefully. However, ACL's can be used, if necessary, to explicitly “deny” access to one or more users in the Group **users**.\\
+\\
+For instance, in the example group **users** we have two adults **Fred** and **Mary**, and their two children **Johnny** and **Betty**.  It's easy to envision a scenario where adults may need a network share that their children couldn't access, that my contain medical information, letters to school officials, etc.\\
+\\
+Following is a potential use of ACL's that would allow parents access to a share while denying their children access:\\
+\\
+{{ :11-perms-acls.jpg?600 |}}
+\\
+Note the check marks under **No access** for **Johnny** and **Betty**.  To be sure that all files and folders in the share are reset with the appropriate permissions, the **Recursive** switch should be **ON** (green), before Clicking on **Apply**.\\
+\\
+**Johnny** and **Betty** will have no access to the **Test** share, while the remaining users in the Group **users** will have **Write**.  Using ACL's in this way allows a home administrator to selectively set individual users to **Read-only** or **deny access**.  However, note that ACL's can not grant **increased access** that does not exist in Standard permissions.\\
+\\
+----
+\\
+===== Permissions Overview =====
+\\
+The following, moving left to right shows the hierarchy of Standard Linux permissions and the network permissions that are layered onto it, with Samba.  Once Standard permissions are set in the Shared Folder, follow on permission layers can only **//reduce//** access.  They cannot, for example, grant a user or a group **Write** access to a Shared Folder, if **Read only** is specified at the Shared Folder level.\\
+\\
+{{ :12-perms-overview.jpg?600 |}}
+\\
+----
+\\
+==== Practical Permissions Examples ====
+\\
+(In the following examples root, as the owner, is assumed.)\\
+\\
+In the examples, the list of users are as follows:\\
+Fred – IworkOT\\
+Mary – 2kids2feed\\
+Johnny – Ihatechores\\
+Betty – Iwashdishes\\
+\\
+All users are in the default Group **users**.  Fred is the server admin.\\
+\\
+----
+\\
+=== A Media Share ===
+\\
+{{ :13-perms-example1.jpg?600 |}}
+\\
+  * In the Shared Folder, the group **users** have **write**.  This is necessary so that **Fred**, who is the family server administrator, can **write** to the share from his client.
+  * Samba Public access is set to **Guests allowed** which works with the Shared Folder permission **Others: Read**   These permissions and Samba settings will allow visitors **read** access to media shares such as music or movies.
+  * **Read Only is ON**.  This will further restrict the Group users down from **Write** to **Read only** access.  With young children accessing a share, **Read only** is a good idea to prevent the possibility of an accidental deletion of media files.
+  * The Samba  **''write list''**  bypasses the Samba **Read Only** setting for one user, allowing **Fred** to **write** to the share for admin purposes.\\
+\\
+=== A Group Share ===
+\\
+(A location for sharing files among all family members or members of a group.)\\
+\\
+{{ :13-perms-example2.jpg?600 |}}
+\\
+  * The Group **users** have **write**.
+  * While **Others** have **read**, at the Shared Folder, SMB **Public** is set to “**NO**” which stops all users who are not in the Group **users**.  Guests are not allowed.  (The same effect, no Guest users, could be achieved at the Shared Folder level with **Others – None**.)
+  * **Read only** is **OFF** so Shared Folder permissions allow all members of the Group users to write to the share.\\
+\\
+=== A Restricted Share ===
+\\
+This share is for private information, for select members of the Group **users**.  ACL's can be used to remove access for users that should not see the contents of the applicable share.  In this example, Parents have access while household children are set to **No Access**.\\
+\\
+A significant point to be made about this example is that one or more users can be set to **Read only** or **No Access** without disturbing the access of the remaining members of the Group **users**.  This might be convenient and expedient for employers who might want to restrict a specific employee to **No access** or **Read-only** access, quickly, when “notice” has been given or received.\\
+\\
+{{ :14-perms-example3.1.jpg?600 |}}
+\\
+Shared Folder settings are as shown below:\\
+\\
+{{ :14-perms-example3.2.jpg?600 |}}
+\\
+After selecting group usernames for **No access** (or **Read-only**) it's important to turn **Recursive ON** (green), before clicking the **Apply** button.  This insures that new permissions are written to all files and folders within the share.\\
+\\
+**Note:**\\
+The above could also be achieved by creating a new group created under; **Access Rights Management**, **Group** and clicking on the **+Add** button.  A group named **parents** could contain the users **Fred** and **Mary**.  If the Group **parents** is used above, in the **Group** field, ACL entries to deny access to children would not be required.\\
+\\
+=== A Personal / Private Share ===
+\\
+A private share for an individual user could be created using ACL's and setting all users, but one, to **No access**.  However, creating a group with one user might be the best approach.\\
+\\
+Note the names of the newly created groups, below, and the usernames in each group.  The naming scheme keeps it simple.\\
+\\
+{{ :15-perms-example4.1.jpg?600 |}}
+\\
+In this case, the Group **Fred** (with a single user **Fred**) has **Write**.  The Samba settings noted are appropriate for this type of share.  Only **Fred** can access and write this share.\\
+\\
+{{ :15-perms-example4.2.jpg?600 |}}
+\\
+----
+===== The Bottom Line =====
+\\
+If all data is stored in a single share, assigning the appropriate permissions might range from difficult to impossible.  On the other hand, if careful thought is given to segregating data into logical sets (Shared Folders) with user access and permissions in mind, assigning the appropriate permissions becomes a much easier task.\\
+\\
+===== Permissions Notes: =====
+\\
+  * Additions of new users or changes to existing user accounts, such as password changes, would need to be replicated at the server.
+  * Some use cases may benefit from using the [[https://pureinfotech.com/credential-manager-windows-10/|Credential Manager]] built into Win10.
+  * Win10 workstations may need a few network configuration changes to access a server in a peer-to-peer network.  It a workstation can't connect to an OMV server, see this [[https://www.mediafire.com/file/5yoo25285t91l3s/HOWTO-ConnectWin10toOMV.pdf/file|document]] for settings and work arounds.
+\\
+----