NFS V4 ACL Syntax

An NFS V4 ACL consists of a list of ACL entries. Where traditional ACLs can display one entry per line, the GPFS representation of NFS V4 ACL entries is of three lines each, due to the increased number of available permissions beyond the traditional rwxc.

The first line separates the multiple parts by colons (':').
  • The first part identifies the user or group.
  • The second part displays a rwxc translation of the permissions that appear on the subsequent two lines.
  • The third part is the ACL type. NFS V4 provides both an allow and deny type.
    allow
    Means to allow (or permit) those permissions that are selected with an 'X'.
    deny
    Means to not allow (or deny) those permissions that are selected with an 'X'.
  • The fourth and final part is a list of flags that indicate inheritance.
    Valid flag values are:
    DirInherit
    Indicates that the ACL entry must be included in the initial ACL for subdirectories that are created in this directory (and the current directory).
    FileInherit
    Indicates that the ACL entry must be included in the initial ACL for files that are created in this directory.
    Inherited
    Indicates that the current ACL entry was derived from inherit entries in an NFS v4 ACL of the parent directory.
    InheritOnly
    Indicates that the current ACL entry must not apply to the directory, but must be included in the initial ACL for objects that are created in this directory.
    NoPropagateInherit
    Indicates that the ACL entry must be included in the initial ACL for subdirectories that are created in this directory but not further propagated to subdirectories created below that level.

As in traditional ACLs, users and groups are identified by specifying the type and name. For example, group:staff or user:bin. NFS V4 provides for a set of special names that are not associated with a specific local UID or GID. These special names are identified with the keyword special followed by the NFS V4 name. These names are recognized by the fact that they end with the character '@'. For example, special:owner@ refers to the owner of the file, special:group@ the owning group, and special:everyone@ applies to all users.

The next two lines provide a list of the available access permissions that can be allowed or denied, based on the ACL type specified on the first line. A permission is selected by using an 'X'. Permissions that are not specified by the entry must be left marked with '-' (minus sign).

Start of changeStarting from IBM Storage Scale 5.1.7, IBM Storage Scale supports setting the extended system.nfs4_acl attribute as another method for manipulating NFSv4 ACLs. This enhancement is added to support the Linux NFSv4 ACL command-line tools. You can employ the syntax of these tools to manage NFSv4 ACLs in IBM Storage Scale. For requirements and limitations, see Q.2.41 in IBM Storage Scale FAQ.End of change

These are examples of NFS V4 ACLs.
  1. An ACL entry that explicitly allows READ, EXECUTE and READ_ATTR to the staff group on a file is similar to this: 
    group:staff:r-x-:allow
 (X)READ/LIST (-)WRITE/CREATE (-)APPEND/MKDIR (-)SYNCHRONIZE (-)READ_ACL  (X)READ_ATTR  (-)READ_NAMED
 (-)DELETE    (-)DELETE_CHILD (-)CHOWN (X)EXEC/SEARCH (-)WRITE_ACL (-)WRITE_ATTR (-)WRITE_NAMED
  2. A Directory ACL is similar to this. It can include inherit ACL entries that do not apply to the directory itself, but instead become the initial ACL for any objects that are created within the directory. 
    special:group@:----:deny:DirInherit:InheritOnly
 (X)READ/LIST (-)WRITE/CREATE (-)APPEND/MKDIR (-)SYNCHRONIZE (-)READ_ACL  (X)READ_ATTR  (-)READ_NAMED
 (-)DELETE    (-)DELETE_CHILD (-)CHOWN (X)EXEC/SEARCH (-)WRITE_ACL (-)WRITE_ATTR (-)WRITE_NAMED
  3. A complete NFS V4 ACL is similar to this: 
    #NFSv4 ACL
#owner:smithj
#group:staff
special:owner@:rwxc:allow:FileInherit
 (X)READ/LIST (X)WRITE/CREATE (X)APPEND/MKDIR (-)SYNCHRONIZE (X)READ_ACL  (X)READ_ATTR  (-)READ_NAMED
 (X)DELETE    (X)DELETE_CHILD (X)CHOWN (X)EXEC/SEARCH (X)WRITE_ACL (X)WRITE_ATTR (-)WRITE_NAMED

special:owner@:rwxc:allow:DirInherit:InheritOnly
 (X)READ/LIST (X)WRITE/CREATE (X)APPEND/MKDIR (-)SYNCHRONIZE (X)READ_ACL  (X)READ_ATTR  (-)READ_NAMED
 (X)DELETE    (X)DELETE_CHILD (X)CHOWN (X)EXEC/SEARCH (X)WRITE_ACL (-)WRITE_ATTR (-)WRITE_NAMED

user:smithj:rwxc:allow
 (X)READ/LIST (X)WRITE/CREATE (X)APPEND/MKDIR (-)SYNCHRONIZE (X)READ_ACL  (X)READ_ATTR  (-)READ_NAMED
 (X)DELETE    (X)DELETE_CHILD (X)CHOWN (X)EXEC/SEARCH (X)WRITE_ACL (-)WRITE_ATTR (-)WRITE_NAMED
    Note: In IBM Storage Scale 5.0.3, a difference in the handling of the NFSv4 ACL bit SYNCHRONIZE can cause access issues for Microsoft Windows clients. The change is that when ACL data is returned to the SMB client, the SYNCHRONIZE bit on ACL "allow" entries is passed unchanged. But Microsoft Windows clients require the SYNCHRONIZE bit to be set for renaming files or directories. Files that are written by Microsoft Windows clients usually have the SYNCHRONIZE bit set.
    To restore the pre-5.0.3 behavior, issue the following command for each SMB share that is affected by the problem:
    /usr/lpp/mmfs/bin/net conf setparm <SMBShareName> 'nfs4:set synchronize' yes
    In the long term, it is a good idea to change the ACLs for all files and directories that are missing the SYNCHRONIZE bit instead of modifying the SMB configuration.