Sun ZFS Storage 7320
 
Sun Storage 7210 Unified Storage System
 
Sun Storage 7410 Unified Storage System
 
Sun ZFS Storage 7420
 
Sun Storage 7310 Unified Storage System
 
Sun Storage 7110 Unified Storage System
 
Sun ZFS Storage 7120
 

PLA-Support>Sun Systems>DISK>ZFS Storage>SN-DK: 7xxx NAS
 

In this Document

Symptoms

Cause

Solution

Created from <SR 3-7085192869>

Applies to:

Symptoms

Problem Description: Unable to set Root Directory ACL for a share via the CLI

System: Sun ZFS Storage 7x20 Systems and Sun Storage 7x10 Unified Storage Systems

Symptoms:
-> In BUI, when creating a new share (under the menu Shares -> create Filesystem), there is an option for the "Permissions" field to set Windows default permissions.

If "Use Windows default permissions" is selected, the Permissions section is greyed out and the permissions are automatically set to:
  RWX (Read, Write, Execute) for user
  RX (Read, Execute) for group
  RX (Read, Execute) for others
  #### See the attachment Share_BUI_Windows_default.jpg

  Windows Default Permissions can be checked in BUI, under the menu Shares -> select share -> Access Tab -> Root Directory ACL
  #### See the attachment Share_BUI_Root_Directory_ACL.jpg

-> In CLI, when creating a new share, there is no "Windows default permissions" option. However, there is an option that can grant the same privileges, this is root_permissions.
  The equivalent of the "Windows Default Permissions" is 755 - RWX (Read, Write, Execute) for user, RX (Read, Execute) for group and RX (Read, Execute) for others

-> The problem is that there are different Root Directory ACLs when setting the "Windows default permissions" from BUI and when setting the 755 for root_permissions in CLI.
  So setting 755 privileges from CLI does not provide the same access rights as "Windows default permissions" does, so this option should be included in the CLI also

-> As an example, a share that is created under BUI, with "Windows Default Permissions", gets the following privileges:

Share created under BUI:

Share created under CLI:

  If a share that is created under CLI, using root_permissions 755, it gets the following privileges:
 

TEST CASES

TEST 1 - Create filesystem "test" from CLI using the root_permissions 755

I got the following Root Directory Access:

The following Root Directory ACL:

The following ACL Behavior:

TEST 2 - Create filesystem "test2" from BUI

Root Directory Access:

The following Root Directory ACL:

The following ACL Behavior:

So we have a difference between the BUI creation and the root_permissions 755 from CLI:

The fact that the owner has different access privileges and the ACL behavior on mode change

Cause

The "Windows default permissions" option is not available in the CLI, and it can only be used from BUI.

By selecting "Use Windows Default Permissions" in the BUI, a different set of permission bits is granted than the 755 option used in CLI.

The root directory ACL displayed in the BUI can be a little confusing.

In the "Access" column, it can only be seen a text description of the ACL if it's an exact match for one of the Windows named permission sets: "Full Control", "Modify", "Read & Execute" or "Read".

In the case of an owner with RWX (7) permissions, we are one bit away from the Windows full control set, so no description is displayed.

Despite the minor difference, the ACL for the owner is effectively almost identical to full control.

The following example of a full control ACL and a "RWX" ACL can be found below:
  -> RWX ACL:

  -> Full Control ACL:

Solution

At this moment, there is no solution to this problem, but there has been raised an Enhancement Request for this issue:

BUG 15547207 - SUNBT6814333 want ability to modify ACLs from the CLI

This solution has no attachment