Access permissions are set at two levels:
- Share (done through MCM)
- Filesystem (done through Windows ACLs)
Share Permissions
Share permissions control how a share can be mapped by a user or group (read/write, read-only, no access).
In the following examples, we'll only use groups for simplicity, but users can also be used for even finer-grained access control.
Scenario
Let's use the Accounting share shown above as an example. In the above screenshot, the Accounting share has default read/write access with no user/group restrictions, which means that anyone can connect to the share with read/write permissions (note that the user will still need read/write permissions to files and folders, but we'll cover this in the filesystem section).
Guest access is also enabled. This means that if the user does not have a valid username, they will be able to connect to the share as the guest user.
Generally, accounting has sensitive information, so perhaps a more reasonable permissions setting would be:
- Read-only for members of the g_engineering, g_support, and g_testing groups.
- Do not allow guest access.
We can do this by using the settings in the screenshot below:
If we expect the number of groups to grow but we only want g_accounting and g_administrative to have write access, we can make the Default Access read-only and specify which groups can write. In the real world, this is the preferred way to make a share read-only with read/write access for specific users/groups.
For a more realistic example, consider a situation where accounting has very sensitive information, so this would be more appropriate:
- g_accounting has read/write access.
- g_administrative may need read access.
- All other groups have no access.
We can configure the share like this:
Frequently Asked Question: In the above scenario, if a user is a member of both g_accounting and g_administrative, will he have read/write or read-only access?
Answer: The user will have read/write access to the share.
Frequently Asked Question: My users/groups are not appearing in the Exception area. What do I need to do?
Answer: If you are using Active Directory, Azure, or LDAP modes, you will need to import users and groups before they can be used here. The process is similar for all non-Morro Users authentication modes.
For more information, see the "Import Users and Groups from Active Directory" section of this article:
Filesystem Permissions
Permissions at the file and folder level can be set with Windows File Explorer.
To change the permissions on files or folders:
- Go to Windows File Explorer.
- Navigate to the file or folder.
- Right click on the item.
- Select Properties, then the Security tab.
For Morro devices in Morro Users mode, the users/groups created in MCM will be shown. Morro devices in Active Directory, Azure, or LDAP mode will show users created in their respective security domains.
Click the Edit button to add/remove users from the ACL or to modify their permissions.
Frequently Asked Question: If the user has read/write access to a file, but read-only access to the share, can the user write to the file?
Answer: No, because the share-level permissions take precedence. In fact, if the share can only be mapped read-only, then access to the entire share is read-only regardless of filesystem permissions.
Frequently Asked Question: If the user has read/write access to a share, but read-only access to a file, can the user write to the file?
Answer: No. While the user has the ability to write to the share, the file itself it not writeable by the user.
Frequently Asked Question: In terms of filesystem permissions, which user is guest?
Answer: Guests are mapped to the "nobody" user.
What About Advanced -> Security?
Generally, this section should be left alone. It allows the user to configure the permissions for the root folder of the share and is normally not needed. If you feel that changes are needed here to fix a specific problem or to fulfill an unusual permissions requirement, please consult with Support.