This topic describes the features of NFSv4 access control lists (ACLs) and POSIX ACLs.

Note

The NFS ACL feature is available only for NFS file systems in the following regions: China (Zhangjiakou-Beijing Winter Olympics), China (Beijing), China (Hohhot), China (Hangzhou), China (Shanghai), China (Chengdu), China (Hong Kong), Australia (Sydney), Indonesia (Jakarta), US (Silicon Valley), US (Virginia), Germany (Frankfurt), UK (London), and India (Mumbai). If the region where your file system resides does not support the NFS ACL feature, submit a ticket.

Features of Apsara File Storage NAS NFSv4 ACLs

  • Only access control entries (ACEs) of the allow type are supported. Deny, audit, and alarm ACEs are not supported.

    Deny ACEs increase the complexity of access control. In most cases, complexity leads to confusion and increases potential security risks. We recommend that you do not use deny ACEs. For more information about why deny ACEs are not recommended, see FAQ.

    Audit and alarm ACEs are unavailable for NFS file systems. However, you can audit file systems and configure alerts based on auditing results in the NAS console.

  • If no ACL is set for a file or a directory, the default ACL that corresponds to the predefined file mode creation mask is applied.
    touch file
    [root@vbox test]# ls -l file
    -rw-r--r--. 1 root root 0 May  6 14:27 file
    [root@vbox test]# nfs4_getfacl file
    # file: file
    A::OWNER@:rwatTnNcCy
    A::GROUP@:rtncy
    A::EVERYONE@:rtncy
  • An ACL is an ordered list that contains and deduplicates ACEs. This ensures that the permissions defined in an ACL are clear and informative.
    If you apply both a new ACE and an existing ACE to the same object and the existing ACE is inherited from the parent object, the permissions of the new ACE override the permissions of the existing ACE. Examples:
    • ACEs that include the principals OWNER, GROUP, and EVERYONE are queued in this sequence at the beginning of an ACL. These ACEs take precedence over other ACEs.
      [root@vbox test]# nfs4_getfacl file
      # file: file
      A::OWNER@:rwaxtTnNcCy
      A::GROUP@:rtncy
      A::EVERYONE@:rtncy
      A::1001:rwaxtTNcCy
    • Add an ACE of the read and write permissions to the following ACL for a user principal named 1009. The ACE is placed after the ACE that is defined for a user principal named 1001 based on the predefined order.
      [root@vbox test]# nfs4_setfacl -a A::1009:X file
      [root@vbox test]# nfs4_getfacl file
      # file: file
      A::OWNER@:rwaxtTcCy
      A::GROUP@:rwatcy
      A::EVERYONE@:tcy
      A::1001:rwaxtTNcCy
      A::1009:xtcy
    • Add a new ACE that includes the execute permissions to the ACL for the user principal named 1009. The system automatically merges the execute permissions to the existing ACE for the 1009 user principal.
      [root@vbox test]# nfs4_setfacl -a A::1009:W file
      [root@vbox test]# nfs4_getfacl file
      # file: file
      A::OWNER@:rwaxtTcCy
      A::GROUP@:rwatcy
      A::EVERYONE@:tcy
      A::1001:rwaxtTNcCy
      A::1009:waxtTncCy
    • Add the f and d inheritance flags to an ACE that includes a user principal named 1009. Then, the system splits the ACE into two ACEs. One ACE has an extra inheritance flag named i, which indicates an inherit-only ACE. The other ACE applies to only the file object that does not have inheritance flags. If the inheritance type of an existing ACE matches the type of one of the two ACEs, the system combines the existing ACE with this ACE into one ACE.
      [root@vbox test]# nfs4_setfacl -a A:fd:1009:R file
      [root@vbox test]# nfs4_getfacl file
      # file: file
      A::OWNER@:rwaxtTcCy
      A::GROUP@:rwatcy
      A::EVERYONE@:tcy
      A::1001:rwaxtTNcCy
      A::1009:rwaxtTNcCy
      A:fdi:1009:r
  • All ACEs can be inherited.
    1. For example, the OWNER principal has the write access, the GROUP principal has the read access, and the EVERYONE has no access to the dir directory.
      [root@vbox nfs]# nfs4_getfacl dir
      # file: dir
      A::OWNER@:rwaDxtTnNcCy
      A::GROUP@:rxtcy
      A::EVERYONE@:tncy
    2. Add an ACE that grants a user principal named 1000 the read, write, and execute access to the dir directory. The f and d inheritance flags are also specified for the ACE.
      [root@vbox nfs]# nfs4_setfacl -a A:fd:1000:rwx dir
      [root@vbox nfs]# nfs4_getfacl dir
      # file: dir
      A::OWNER@:rwaDxtTcCy
      A::GROUP@:rxtcy
      A::EVERYONE@:tcy
      A::1000:rwx
      A:fdi:1000:rwx
    3. If you create a file or subdirectory in the dir directory, the file or the subdirectory automatically inherits all ACEs from the dir directory.
      [root@vbox nfs]# touch dir/file
      [root@vbox nfs]# nfs4_getfacl dir/file
      # file: dir/file
      A::OWNER@:rwatTcCy
      A::GROUP@:rwatcy
      A::EVERYONE@:rwatcy
      A::1000:rwx
      [root@vbox nfs]# mkdir dir/subdir
      [root@vbox nfs]# nfs4_getfacl dir/subdir
      # file: dir/subdir
      A::OWNER@:rwaDxtTcCy
      A::GROUP@:rwaDxtcy
      A::EVERYONE@:rwaDxtcy
      A:fdi:1000:rwx
    Note
    • We recommend that you grant the least privilege to the EVERYONE principal. Before you run one of the preceding commands, we recommend that you run the umask 777 command. This command ensures that no access to a file or directory is granted when the file or directory is created. For more information, see Why doesn't umask change execute permissions on files?
    • When Linux calls functions to create files or directories, the predefined file mode creation mask is used as a request parameter. You can obtain the final ACL for a child object from the overlap of the inherited ACL (parent to child) and the file mode creation mask, as specified in the RFC 7530 standard. When you modify the group bits of a file mode creation mask based on the standard, the permissions included in an ACL for each group must be less than or equal to the permissions defined in the group bits. However, this results in an invalid inheritance for groups. For example, if you want the subfile to inherit Group A:RWX but the predefined file mode creation mask GROUPS:R is used as a request parameter, the ACE included in the ACL of Group A is then changed to Group A: R. In an actual business scenario, we recommend that you modify file mode creation masks only for ACLs that include the following principals: OWNER, GROUP, and EVERYONE. This prevents potential issues and ensures that semantics are clear. To remove permissions from a group, we recommend that you remove the ACE that is associated with the group.
  • You must manage the mappings between usernames or group names and user IDs (UIDs) or group IDs (GIDs) across multiple independent instances.

    Apsara File Storage NAS NFS uses IP security groups instead of usernames to authenticate users. When you configure NFSv4 ACLs, UIDs or GIDs that are included in ACEs are stored in Linux. When you print an ACL for an object in a shell, Linux automatically loads the /etc/passwd file and converts UIDs or GIDs to usernames or group names. You need to manage the mappings between usernames or group names and UIDs or GIDs across multiple instances. You must ensure that each username is mapped to its corresponding UID, and each group name is mapped to its corresponding GID.

  • You can print NFSv4 ACL by using extended attributes.
    [root@vbox nfs]# getfattr -n system.nfs4_acl file
    # file: file
    system.nfs4_acl=0sAAAABgAAAAAAAAAAABYBhwAAAAZPV05FUkAAAAAAAAAAAAAAABIAhwAAAAZHUk9VUEAAAAAAAAAAAAAAABIAhwAAAAlFVkVSWU9ORUAAAAAAAAAAAAAAAAAAAAEAAAAEMTAwMAAAAAAAAAALAAAAAwAAAAQxMDAwAAAAAAAAAEAAFgGQAAAABTEwMDAxAAAA
  • You can use tools such as cp to migrate NFSv4 ACLs.

    NAS allows you to migrate NFSv4 ACLs by using the cp, tar, and rsync tools. For more information, see How to preserve NFS v4 ACLs via extended attributes when copying file.

    The following cp --preserve=xattr file1 file2 command copies the ACL of file1 when it copies file1 to file2. The cp -ar dir1 dir2 command copies the ACL of file1 when it copies file1 to file2.
    Note NFSv4 ACLs may fail to be migrated if the version of the rsync tool is earlier than 3.1.2.
    [root@vbox nfs]# nfs4_getfacl file1
    # file: file1
    A::OWNER@:rwatTcCy
    A::GROUP@:rwatcy
    A::EVERYONE@:rwatcy
    A::1000:rtncy
    [root@vbox nfs]# cp --preserve=xattr file1 file2
    [root@vbox nfs]# nfs4_getfacl file2
    # file: file2
    A::OWNER@:rwatTcCy
    A::GROUP@:rwatcy
    A::EVERYONE@:rwatcy
    A::1000:rtncy
    [root@vbox nfs]# cp -ar dir1 dir2
  • NFSv4 ACLs can interact with file mode creation masks. If you modify the ACL of an object, the file mode create mask of the object is changed. In addition, if you modify the file mode creation mask of an object, the ACL of an object is changed.
    For example, the file mode creation mask of the file object is 0666.
    [root@vbox nfs]# ls -l file
    -rw-rw-rw-. 1 root root 0 May  3  2019 file
    [root@vbox nfs]# nfs4_getfacl file
    # file: file
    A::OWNER@:rwatTcCy
    A::GROUP@:rwatcy
    A::EVERYONE@:rwatcy
    • If you add the execute permissions to the file mode creation mask by modifying the owner bits, the execute permissions are also added to the ACE that includes the OWNER principal.
      [root@vbox nfs]# chmod u+x file
      [root@vbox nfs]# ls -l file
      -rwxrw-rw-. 1 root root 0 May  3  2019 file
      [root@vbox nfs]# nfs4_getfacl file
      # file: file
      A::OWNER@:rwaxtTcCy
      A::GROUP@:rwatcy
      A::EVERYONE@:rwatcy
    • If you add the execute permissions to an ACE that includes the GROUP principal, the execute permissions are also added to the file mode creation mask.
      [root@vbox nfs]# nfs4_setfacl -a A::GROUP@:x file
      [root@vbox nfs]# ls -l file
      -rwxrwxrw-. 1 root root 0 May  3  2019 file
    Note
    • In the interactions between ACLs and file mode creation masks, the EVERYONE principal is equivalent to the other class. When you modify the other class, the change also applies to the EVERYONE principal. This operation has a slight impact on the semantics of permissions. For example, the current file mode creation mask is 177. After you run the chmod o+r command, all users that include the file owner and group members have the read permissions. This is because the read permission is added to the ACE that includes the EVERYONE principal. If no change is applied to the default file mode creation mask, the owner and group classes still have no read permissions after you run the chmod o+r command.
    • If no change is applied to NFSv4 ACLs, the semantics of the other class of the file mode remain. If you modify an NFSv4 ACL, the semantics of the other class change to the semantics of the EVERYONE principal and the latest semantics remain. We recommend that you do not use file mode creation masks after you use NFSv4 ACLs.
  • The relationship between the file mode creation mask and NFSv4 ACEs.
    • If you run the chmod command to modify the file mode creation mask, changes are applied to the NFSv4 ACLs. The following table describes the changes.
    • If you run the nfs4_setfacl command to modify only file permissions that are included in NFSv4 ACLs, and the wa permission is not applied to all files, the w permission is not displayed in the file mode creation mask.
    • If you run the nfs4_setfacl command to modify only directory permissions that are included in NFSv4 ACLs, and the waD permission is not applied to all directories, the write permissions are not displayed in the file mode creation mask.
    • If the Dx permission is included in the NFSv4 ACLs for directories, the w permission is not displayed in the file mode creation mask. If subfiles and subdirectories can be created in the directories, the w and x permissions are still included in the file mode creation mask.
    • We recommend that you specify RWX in uppercase letters when you set permissions by running the nfs4_setfacl command. RWX in uppercase is automatically mapped to rwx in the file mode creation mask. This can prevent the compatibility issues between an NFSv4 ACL and the file mode creation mask.
    mode other NFSv4 ACL EVERYONE on file NFSv4 ACL EVERYONE on dir
    --- A::EVERYONE@:tncy A::EVERYONE@:tncy
    --x A::EVERYONE@:xtncy A::EVERYONE@:xtncy
    -w- A::EVERYONE@:watncy A::EVERYONE@:waDtncy
    -wx A::EVERYONE@:waxtncy A::EVERYONE@:waDxtncy
    r-- A::EVERYONE@:rtncy A::EVERYONE@:rtncy
    r-x A::EVERYONE@:rxtncy A::EVERYONE@:rxtncy
    rw- A::EVERYONE@:rwatncy A::EVERYONE@:rwaDtncy
    rwx A::EVERYONE@:rwaxtncy A::EVERYONE@:rwaDxtncy
    mode group NFSv4 ACL GROUP on file NFSv4 ACL GROUP on dir
    --- A::GROUP@:tncy A::GROUP@:tncy
    --x A::GROUP@:xtncy A::GROUP@:xtncy
    -w- A::GROUP@:watncy A::GROUP@:waDtncy
    -wx A::GROUP@:waxtncy A::GROUP@:waDxtncy
    r-- A::GROUP@:rtncy A::GROUP@:rtncy
    r-x A::GROUP@:rxtncy A::GROUP@:rxtncy
    rw- A::GROUP@:rwatncy A::GROUP@:rwaDtncy
    rwx A::GROUP@:rwaxtncy A::GROUP@:rwaDxtncy
    mode owner NFSv4 ACL OWNER on file NFSv4 ACL OWNER on dir
    --- A::OWNER@:tTnNcCy A::OWNER@:tTnNcCy
    --x A::OWNER@:xtTnNcCy A::OWNER@:xtTnNcCy
    -w- A::OWNER@:watTnNcCy A::OWNER@:waDtTnNcCy
    -wx A::OWNER@:waxtTnNcCy A::OWNER@:waDxtTnNcCy
    r-- A::OWNER@:rtTnNcCy A::OWNER@:rtTnNcCy
    r-x A::OWNER@:rxtTnNcCy A::OWNER@:rxtTnNcCy
    rw- A::OWNER@:rwatTnNcCy A::OWNER@:rwaDtTnNcCy
    rwx A::OWNER@:rwaxtTnNcCy A::OWNER@:rwaDxtTnNcCy
    NFSv4 ACLs have more sets of permissions than the file mode creation mask. Each permission bit fulfills a unique function. Some permissions cannot take effect alone unless they are combined with other permissions. In addition, the functionalities of some permission bits must be expressed by other permission bits. The same permission bits for different files and directories may have different functionalities. The following table describes the permissions that are included in the NFSv4 ACLs for files and directories.
    Table 1. NFSv4 ACLs for a file
    Permission bit Functionality Usage note
    r Reads a file. None.
    w Writes or creates a file. The w permission takes effect only if both the w and a permissions are specified.
    a Appends data to an existing file. The a permission takes effect only if both the w and a permissions are specified.
    x Executes a file. The x permission takes effect only if both the r and x permissions are specified.
    d Deletes a file. This permission is invalid in NFSv4 ACL. If you have the w and x permissions on the parent directory, you can delete the current file regardless of whether the d permission that valid on the file.
    D - You cannot set the D permissions on files. The nfs4_setfacl D command is filtered out by the client.
    t Reads the attributes of a file. One of the four default least permissions. You are not allowed to revoke this permission.
    T Modifies file attributes. None.
    n Reads the attributes of a file. One of the four default least permissions. You are not allowed to revoke this permission.
    N Modifies the named attributes of a file. You cannot modify the named attributes of the files in an NFS NAS file system. The N permission is invalid.
    c Reads the ACL of a file. One of the four default least permissions. You are not allowed to revoke this permission.
    C Modifies the ACL of a file. None
    o Changes the owner of a file. If you have the o permission, you can change the file owner to yourself. However, you cannot change the file owner to others unless you are the root user.
    y Allows synchronous access. One of the four default least permissions. You are not allowed to remove this permission.
    Table 2. NFSv4 ACLs for a directory
    Permission bit Functionality Usage note
    r Queries a directory None.
    w Creates files and directories. The w permission alone is invalid. The functionalities of the w permission are implemented by the D permission. Therefore, the w permission take effect only if the D and x permissions are applied.
    a Creates a subdirectory The a permission alone is invalid. The functionalities of the a permission are implemented by the D permission. Therefore, the a permission can take effect only if the D and x permissions are applied.
    x Enters a directory None
    d Deletes a directory The d permission is invalid in NFSv4 ACLs. If you have the w and x permissions on a parent directory, you can delete the current subdirectory regardless of whether the d permission is valid on the subdirectory.
    D Deletes subfiles and subdirectories from a directory The D permission can take effect only if the D and X permissions are applied.
    t Reads the attributes of a directory. One of the four default least permissions. You are not allowed to revoke this permission.
    T Modifies the attributes of a directory. None.
    n Reads the named attributes of a directory One of the four default least permissions. You are not allowed to revoke this permission.
    N Modifies the named attributes of a directory You cannot modify the named attributes of the files in an NFS NAS file system. The d permission is invalid in NFSv4 ACLs.
    c Reads the ACL of a directory. One of the four default least permissions. You are not allowed to revoke this permission.
    C Modifies the ACL of a directory None
    o Changes the owner of a file If you have the o permission, you can change the file owner to yourself. However, you cannot change the file owner to others unless you are the root user.
    y Allows synchronous access One of the four default least permissions. You are not allowed to revoke this permission.
    Notice
    • The default least permission of the OWNER principal is tTnNcCy.
    • The default least permission for the GROUP and EVERYONE principal is tncy.
  • Interactions between NFSv4 ACLs and POSIX ACLs are supported.

    You can mount NFSv3 file systems that have NFSv4 ACLs. These NFSv4 ACLs are then converted to POSIX ACLs. You can also mount NFSv4 file systems that have POSIX ACLs. These POSIX ACLs are then converted to NFSv4 ACLs.

    Note The semantics of POSIX ACLs are different from the semantics of NFSv4 ACLs. For example, the inheritance rules that apply to POSIX ACLs do not differentiate files or directories. NFSv4 ACLs have more permissions than POSIX ACLs. POSIX ACLs have only read, write, and execute permissions. We recommend that you use either NFSv4 ACLs or POSIX ACLs to prevent potential issues.

    If you configure an NFSv4 ACL for the dir0 directory, the following permissions are required.

    [root@vbox test] sudo nfs4_getfacl dir0
    A::OWNER@:tTnNcCy
    A::GROUP@:tncy
    A::EVERYONE@:tncy
    A:fdi:EVERYONE@:tncy
    A:fdi:OWNER@:tTnNcCy
    A:fdi:GROUP@:tncy
    A:g:19064:rxtncy
    A:g:19065:rwaDxtTnNcCy
    A:fdig:19064:rxtncy
    A:fdig:19065:rwaDxtTnNcCy

    If you configure a POSIX ACL for the dir0 directory, the following permissions are required.

    [root@vbox test] sudo getfacl dir0
    user::---
    group::---
    group:players:r-x
    group:adminis:rwx
    mask::rwx
    other::---
    default:user::---
    default:group::---
    default:group:players:r-x
    default:group:adminis:rwx
    default:mask::rwx
    default:other::---

    If you configure an NFSv4 ACL for the dir0/file file, the following permissions are required.

    [root@vbox test] sudo nfs4_getfacl dir0/file
    A::OWNER@:tTnNcCy
    A::GROUP@:tncy
    A::EVERYONE@:tncy
    A:g:19064:rxtncy
    A:g:19065:rwaxtTnNcCy

    If you configure a POSIX ACL for the dir0/file file, the following permissions are required.

    [root@vbox test] sudo getfacl dir0/file
    user::---
    group::---
    group:players:r-x
    group:adminis:rwx
    mask::rwx
    other::---
  • The number of NFSv4 ACLs is limited.
    By default, NAS supports a maximum of different 100,000 ACLs in each file system. Each ACL can contain a maximum of 500 ACEs.
    Note We recommend that you do not exceed the limits of ACLs or ACEs. Otherwise, more time and resources are consumed to verify permissions.

Features of NAS POSIX ACLs

  • Permissions that are specified for users of the other class apply to everyone.

    Everyone includes the owner, groups, and users that are related to each ACE. The other class is equal to the EVERYONE principal of an NFSv4 ACL.

    Note We recommend that you grant the least permissions to users of the other class.

    For example, the following ACL is configured for the myfile file. Although the ACE contains a user named alice who does not have the write permissions, the write permissions propagate to the ACE because the permissions are specified for users of the other class.

    [root@vbox 3]# getfacl myfile
    # file: myfile
    # owner: root
    # group: root
    user::rw-
    user:alice:r--
    group::r--
    mask::r--
    other::rw-
  • Permissions that are configured by ACLs are not changed after you run the chmod command.
    Note We recommend that you do not modify the file mode creation mask of a file to which a POSIX ACL is applied. You can configure permissions for the file by modifying the POSIX ACL.
    1. For example, an ACE that grants the players group the read and write access to the myfile file.
      [root@vbox 3]# getfacl myfile
      # file: myfile
      # owner: root
      # group: root
      user::rw-
      user:player:rw-
      group::rw-
      group:players:rw-
      mask::rw-
      other::---
    2. The chmod g-w myfile or chmod u-w myfile command does not change the permissions that are granted to the player user or the players group. This is different from the POSIX ACL standard. However, this ensures that the permissions that are granted by POSIX ACLs to non-reserved users are the same after you modify permissions by using the file mode creation mask. Non-reserved users include all users except for the users of the owner, group, and other classes.
      [root@vbox 3]# getfacl myfile
      # file: myfile
      # owner: root
      # group: root
      user::r--
      user:player:rw-
      group::r--
      group:players:rw-
      mask::rw-
      other::---
  • If the execute permission is not granted to the group or other classes of an ACL, the execute permissions on the ACL are invalid.

    The rule is predefined in Linux. The execute operation is allowed by the backend of NAS. However, to make the execute permission in the ACL effective, you must grant the execute permissions to the group or other class.

    For example, if the group and other classes do not have the execute access to the myfile file, the player user cannot execute the file.

    [root@vbox 3]# getfacl myfile
    # file: myfile
    # owner: root
    # group: root
    user::rw-
    user:player:r-x
    group::r--
    mask::r-x
    other::r--
    If you grant the execute permissions to the group class, the execute permissions also propagate to the player user.
    [root@vbox 3]# getfacl myfile
    # file: myfile
    # owner: root
    # group: root
    user::rw-
    user:player:r-x
    group::r-x
    mask::r-x
    other::r--
  • If you configure inheritable NFSv4 ACLs for directories that reside in NFSv3 file systems, these settings may not conform to the POSIX ACL standard.

    Inheritance rules that apply to files are different from inheritance rules that apply to directories in NFSv4 ACLs. The same inheritance rules apply to both files and directories in POSIX ACLs.

    Note We recommend that you apply either NFS4 ACLs or POSIX ACLs to an NFS file system to prevent potential issues.
  • The file mode creation mask cannot be modified.

    The file mode creation mask of a POSIX ACL is generated by the permissions or operations of all users and groups. The mask has no practical meaning and cannot be changed.

  • You must manage the mappings between usernames or group names and user IDs (UIDs) or group IDs (GIDs) across multiple instances.

    Apsara File Storage NAS NFS uses IP security groups instead of usernames to authenticate users. When you configure POSIX ACLs, UIDs or GIDs that are included in ACEs are stored in Linux. When you print an ACL for an object in a shell, Linux automatically loads the /etc/passwd file and converts UIDs or GIDs to actual usernames or group names. You need to manage the mappings between usernames or group names and UIDs or GIDs across multiple instances. You must ensure that each username is mapped to its corresponding UID, and each group name is mapped to its corresponding GID.

  • POSIX ACLs can be printed by using extended attributes.
    [root@vbox nfs]# getfattr -n system.posix_acl_access file
    # file: file
    system.posix_acl_access=0sAgAAAAEAAAD/////AgAFACAEAAAEAAAA/////xAABQD/////IAABAP////8=
  • POSIX ACLs can be migrated by using tools such as cp.

    NAS allows you to migrate POSIX ACLs by using the cp, tar, and rsync tools. For more information, see How to preserve NFS v4 ACLs via extended attributes when copying file.

    The following cp --preserve=xattr file1 file2 command copies the ACL of file1 when it copies file1 to file2. The cp -ar dir1 dir2 command copies the ACL of dir1 when it copies dir1 to dir2.
    Note POSIX ACLs may fail to be migrated if the version of the rsync tool is earlier than 3.1.2.
    [root@vbox nfs]# getfacl file1
    user::---
    user:player:r-x
    group::---
    mask::r-x
    other::--x
    [root@vbox nfs]# cp --preserve=xattr file1 file2
    [root@vbox nfs]# getfacl file2
    # file: file2
    user::---
    user:player:r-x
    group::---
    mask::r-x
    other::--x
    [root@vbox nfs]# cp -ar dir1 dir2
  • The number of POSIX ACLs is limited.
    By default, NAS supports a maximum of 100,000 ACLs that are different from one another in each file system. Each ACL contains a maximum of 500 ACEs.
    Note We recommend that you do not exceed the limits of ACLs or ACEs. Otherwise, more time and resources are consumed to verify permissions.

FAQ

Why are deny ACEs not supported?
  • The position of an ACE that resides in an ACL is important.

    The sequence for ACEs that reside in an NFSv4 ACL is random. A deny ACE may be placed in any position of an NFSv4 ACL. For example, an ACL contains two ACEs: A::Alice:r and D::Alice:r. The position of the ACEs determines whether the user named Alice has the write permissions.

    Note When you configure an ACL, you must consider the position of each ACE.
  • The number of ACEs in an ACL has a sharp increase.

    The ACEs in an ACL may be difficult to combine and deduplicate because it is not mandatory to sequence ACEs. The number of ACEs may increase up to tens or hundreds over a long period of time. To manage the final permissions that are produced by these ACEs, you need to check each ACE. The check process is strenuous and time-consuming.

  • The interactions between the file mode creation mask and ACLs become more complex after deny ACEs are applied. This is because deny features do not exist in the file mode creation mask.
    • If deny ACEs are available, you may need to add several ACEs to an ACL when the file mode creation mask is changed. For example, if you change the file mode creation mask to -rw-rw-rw, you need to add the following ACEs to the ACL. You must add the ACEs in sequence at the beginning of the ACL.
      A::OWNER@:rw
      D::OWNER@:x
      A::GROUP@:rw
      D::GROUP@:x
      A::EVERYONE@:rw
      D::EVERYONE@:x
    • If deny ACEs are unavailable, you can sort and deduplicate ACEs while the ACEs for the everyone class and the other class are not differentiated. If you change the file mode creation mask, you can modify ACLs by changing ACEs for the owner, group, and everyone classes into the following content:
      A::OWNER@:rw
      A::GROUP@:rw
      A::EVERYONE@:rw
  • Conversions between NFSv4 ACLs and POSIX ACLs are not supported.

    POSIX ACLs do not support deny ACEs. If deny ACEs are included in an NFSv4 ACL, you cannot convert the ACL to a POSIX ACL.