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 are three lines each, due to the increased number of available permissions beyond the traditional rwxc.

The first line has several parts separated 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.
    Means to allow (or permit) those permissions that have been selected with an 'X'.
    Means to not allow (or deny) those permissions that have been selected with an 'X'.
  • The fourth and final part is a list of flags indicating inheritance.
    Valid flag values are:
    Indicates that the ACL entry should be included in the initial ACL for subdirectories created in this directory (as well as the current directory).
    Indicates that the ACL entry should be included in the initial ACL for files created in this directory.
    Indicates that the current ACL entry was derived from inherit entries in an NFS v4 ACL of the parent directory.
    Indicates that the current ACL entry should not apply to the directory, but should be included in the initial ACL for objects created in this directory.
    Indicates that the ACL entry should be included in the initial ACL for subdirectories 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 may be allowed or denied, based on the ACL type specified on the first line. A permission is selected using an 'X'. Permissions that are not specified by the entry should be left marked with '-' (minus sign).

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:
  2. A Directory ACL is similar to this. It may include inherit ACL entries that do not apply to the directory itself, but instead become the initial ACL for any objects created within the directory.
  3. A complete NFS V4 ACL is similar to this:
    #NFSv4 ACL
    Note: In IBM Spectrum 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.