In-the-Lab: Default Rights on CIFS Shares

December 6, 2010

Following-up on the last installment of managing CIFS shares, there has been a considerable number of questions as to how to establish domain user rights on the share. From these questions it is apparent that the my explanation about root-level share permissions could have been more clear. To that end, I want to look at default shares from a Windows SBS Server 2008 R2 environment and translate those settings to a working NexentaStor CIFS share deployment.

Evaluating Default Shares

In SBS Server 2008, a number of default shares are promulgated from the SBS Server. Excluding the “hidden” shares, these include:

  • Address
  • ExchangeOAB
  • Public
  • RedirectedFolders
  • UserShares
  • Printers

Therefore, it follows that a useful exercise in rights deployment might be to recreate a couple of these shares on a NexentaStor system and detail the methodology. I have chosen the NETLOGON and SYSVOL shares as these two represent default shares common in all Windows server environments. Here are their relative permissions:


From the Windows file browser, the NETLOGON share has default permissions that look like this:

NETLOGON Share permissions

Looking at this same permission set from the command line (ICALCS.EXE), the permission look like this:

NETLOGON permissions as reported from icacls
The key to observe here is the use of Windows built-in users and NT Authority accounts. Also, it is noteworthy that some administrative privileges are different depending on inheritance. For instance, the Administrator’s rights are less than “Full” permissions on the share, however they are “Full” when inherited to sub-dirs and files, whereas SYSTEM’s permissions are “Full” in both contexts.


From the Windows file browser, the NETLOGON share has default permissions that look like this:

SYSVOL network share permissions

Looking at this same permission set from the command line (ICALCS.EXE), the permission look like this:

SYSVOL permissions from ICACLS.EXE
Note that Administrators privileges are truncated (not “Full”) with respect to the inherited rights on sub-dirs and files when compared to the NETLOGON share ACL.

Create CIFS Shares in NexentaStor

On a ZFS pool, create a new folder using the Web GUI (NMV) that will represent the SYSVOL share. This will look something like the following:
Creating the SYSVOL share
From the NMV (Data Management/Shares), select the CIFS checkbox to share with defaults (including anonymous read/write). Edit the share and rename it SYSVOL – uncheck “Anonymouns Read-Write” before saving.

Login to the NexentaStor appliance and enable a root shell. From this shell, determine the GID of your Domain Admins (or equivalent) super group:

root@san01:/export/home/admin# idmap dump -n | grep Domain
wingroup:Domain Users@solori.local	==	gid:2147483653
wingroup:Domain Users@san01	==	gid:2147483651
wingroup:Domain Admins@solori.local	==	gid:2147483650

From this output, it is clear that the GID for the Windows “Domain Admins” group is 2147483650. [NOTE: Your UID/GID will be different, this is an example only.] We’ll use this information to enable our administrator user to modify the share permissions, but first the GID must be applied to the root share from NexentaStor. To do so, we select the share folder (opens-up the share parameters) and select “Add Permissions for Group.”

Add group ACL to share

Within the “Create New ACL Entity” control box, we insert the GID of our “Domain Admins” group, and check all of the extended “read” permissions. Additionally, we check the “delete” permission, and intentionally leave the “inherit” permission disabled.

Add domain admin group to share

With these permissions applied, we can begin adding additional permissions from the Windows browser. Why is this an important shift of administrative control? Not all permutations of ACL options are available from the NMV. For instance, it would be impossible to set the complex permissions for Administrator on NETLOGON from the NMV since there are actually two sets of permissions for the same user at that level.

As a Windows domain administrator (group), use a file browser to find the share (i.e. \\NAS_NAME) and right click on the “sysvol” share and select the security tab. You may note that there are three unexpected group permissions already enabled on the share: Everyone, Current Owner and Current Group. Do not delete these NAS permissions until later.

We can start with deleting the extra SAN-based permissions – Everyone, Current Owner and Current Group. Next, we’ll add permissions for Authenticated Users, SYSTEM and CREATOR OWNER. Do so by clicking the “Advanced” button, then the “Edit” button on the Advanced Security Settings window, and finally “Add…” on the resulting pop-up requester.

Type in “Authenticated Users” and click the “Check Names” button to confirm the spelling, then click “OK.” Make sure the “Apply to” section lists “This folder, subfolders and files” and check the following: Traverse folder, List folder, Read attributes, Read extended attributes, Read permissions – then click OK. The “Authenticated Users” group should now show “Read & execute” permissions for this share.

Next, click “Add…” again and enter SYSTEM as the selected object. Check the “Full control” box and all other boxes should auto-fill, make sure the “Apply to” selector shows “This folder, subfolders and files” before clicking “OK.”

Finally we’ll add the “CREATOR OWNER” user and apply permissions to “Subfolders and files only” using all permissions except: Full control, Delete subfolders and files, Delete. Once applied, the permissions box should look like this:

The NexentaStor appliance will not have an analog to “Server Operators” from the Windows Server built-ins. To see the NexentaStor built-ins, click the “Locations…” button and select the NAS at the top of the tree, then, select the “Advanced…” button and click “Find Now…” on the subsequent pop-up.  It does have an Administrators group and a Backup Operators group – we’ll use these to stand-in for our remaining groups.

Next page, Comparing and Overriding Permissions…

Pages: 1 2


  1. Collin,

    This is an excellent post covering one of the most frustrating setup steps of Nexenta. Thanks for the assistance on our clients configuration, I believe that following what you had already provided me with I have managed to put a working solution in place. I’m definitely going to be in touch again when we start those larger projects.



  2. Excellent post. You shed light on a very confusing and sparsely documented aspect of using a Nexenta box in a Windows environment. Thanks!


    • Thanks! Any insights you have garnered with your deployment would be welcome.


Comments are closed.

%d bloggers like this: