Features of NFSv4 ACLs and POSIX ACLs - File Storage NAS

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

Features of 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 Network File System (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 (umask) is applied. Example:
1. Run the touch file command to enter the file.
2. Run the ls -l file command to view the permissions on the file.
```
-rw-r--r--. 1 root root 0 May 6 14:27 file
```
3. Run the nfs4_getfacl file command to view the current ACL permissions on the file.
```
# file: file
A::OWNER@:rwatTnNcCy
A::GROUP@:rtncy
A::EVERYONE@:rtncy
```
An ACL is an ordered list that contains and deduplicates ACEs. This scheme 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.
  Run the nfs4_getfacl file command to view the ACL permissions on the file in sequence.
```
# 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.
  - Run the following commands:
```
nfs4_setfacl -a A::1009:X file
nfs4_getfacl file
```
  - Sample command output:
```
# file: file
A::OWNER@:rwaxtTcCy
A::GROUP@:rwatcy
A::EVERYONE@:tcy
A::1001:rwaxtTNcCy
A::1009:waxtTncCy
```
- 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.
  - Run the following commands:
```
nfs4_setfacl -a A::1009:W file
nfs4_getfacl file
```
  - Sample command output:
```
# 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.
  - Run the following commands:
```
nfs4_setfacl -a A:fd:1009:R file
nfs4_getfacl file
```
  - Sample command output:
```
# 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 permissions, the GROUP principal has the read permissions, and the EVERYONE principal has no permissions on the dir directory.
  - Run the following command:
```
nfs4_getfacl dir
```
  - Sample command output:
```
# 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 permissions on the dir directory. The f and d inheritance flags are also specified for the ACE.
  - Run the following commands:
```
nfs4_setfacl -a A:fd:1000:rwx dir
nfs4_getfacl dir
```
  - Sample command output:
```
# file: dir
A::OWNER@:rwaDxtTcCy
A::GROUP@:rxtcy
A::EVERYONE@:tcy
A::1000:rwx
A:fdi:1000:rwx
```
3. When you create a file or subdirectory in the dir directory, the file or the subdirectory automatically inherits all the ACEs from the dir directory.
  - Create a file in the dir directory
    - Run the following commands:
```
touch dir/file
nfs4_getfacl dir/file
```
    - Sample command output:
```
# file: dir/file
A::OWNER@:rwatTcCy
A::GROUP@:rwatcy
A::EVERYONE@:rwatcy
A::1000:rwx
```
  - Create a subdirectory in the dir directory
    - Run the following commands:
```
mkdir dir/subdir
nfs4_getfacl dir/subdir
```
    - Sample command output:
```
# 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 umask 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 umask, as specified in the RFC 7530 standard. When you modify the group bits of a umask 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 umask 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 actual business scenarios, we recommend that you modify umasks only for ACLs that include the following principals: OWNER, GROUP, and EVERYONE. This prevents potential issues and ensures that the 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.
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 on 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 ACLs by using extended attributes.

Run the following command:
```
getfattr -n system.nfs4_acl file
```

Sample command output:

# 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 dir1 when it copies dir1 to dir2.
Note
NFSv4 ACLs may fail to be migrated if the version of the rsync tool is earlier than 3.1.2.
- Example 1: Migrate the ACL of a file.
  1. Run the nfs4_getfacl file1 command to view the ACL permissions on file1.
```
# file: file1
A::OWNER@:rwatTcCy
A::GROUP@:rwatcy
A::EVERYONE@:rwatcy
A::1000:rtncy
```
  2. Run the cp --preserve=xattr file1 file2 command to copy the ACL of file1 to file2.
  3. Run the nfs4_getfacl file2 command to view the ACL permissions on file2.
```
# file: file2
A::OWNER@:rwatTcCy
A::GROUP@:rwatcy
A::EVERYONE@:rwatcy
A::1000:rtncy
```
- Example 2: Migrate the ACL of a directory.
  1. Run the nfs4_getfacl dir1 command to view the ACL permissions on dir1.
```
# file: dir1
A::OWNER@:rwaDxtTnNcCy
A::GROUP@:rxtncy
A::EVERYONE@:rxtncy
A::1000:rxtncy
```
  2. Run the cp -ar dir1 dir2 command to copy the ACL of dir1 to dir2.
  3. Run the nfs4_getfacl dir2 command to view the ACL permissions on dir2.
```
# file: dir2
A::OWNER@:rwaDxtTnNcCy
A::GROUP@:rxtncy
A::EVERYONE@:rxtncy
A::1000:rxtncy
```
NFSv4 ACLs can interact with umasks. If you modify the ACL of an object, the umask of the object is changed. If you modify the umask of an object, the ACL of the object is also changed.
For example, if the umask of the file object is 0666, you can run the following commands to view the file permissions and ACL permissions.
- Run the ls -l file command to view the permissions on the file.
```
-rw-rw-rw-. 1 root root 0 May 3 2019 file
```
- Run the nfs4_getfacl file command to view the ACL permissions on the file.
```
# file: file
A::OWNER@:rwatTcCy
A::GROUP@:rwatcy
A::EVERYONE@:rwatcy
```
If you add the execute permissions to the umask by modifying the owner bits, the execute permissions are also added to the ACE that includes the OWNER principal. Example:
1. Run the chmod u+x file command to grant the execute permissions to the OWNER principal.
2. Run the ls -l file command to view the permissions on the file.
```
-rwxrw-rw-. 1 root root 0 May 3 2019 file
```
3. Run the nfs4_getfacl file command to verify that the execute permissions are granted to the OWNER principal.
```
# 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 umask.
1. Run the nfs4_setfacl -a A::GROUP@:x file command to grant the execute permissions to the GROUP principal.
2. Run the ls -l file command to view the permissions on the file.
```
-rwxrwxrw-. 1 root root 0 May 3 2019 file
```
Note
- In the interactions between ACLs and umasks, 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 umask is rw-------. 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 permissions are added to the ACE that includes the EVERYONE principal. If no change is applied to the default umask, the owner and group classes still do not have the 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 unchanged. 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 unchanged. We recommend that you do not use umasks together with NFSv4 ACLs.

The relationship between the umask and NFSv4 ACEs.

If you run the chmod command to modify the umask, changes are applied to the NFSv4 ACLs. The following table describes the changes.

other

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

group

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

owner

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

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 umask.
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 umask.
If the Dx permission is included in the NFSv4 ACLs for directories, the w permission is not displayed in the umask. If subfiles and subdirectories can be created in the directories, the w and x permissions are still included in the umask.
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 umask. This can prevent the compatibility issues between an NFSv4 ACL and the umask.

NFSv4 ACLs have more sets of permissions than the umask. 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. For more information about NFSv4 ACLs for files and directories, see NFSv4 ACLs.

Note

The default least privilege of the OWNER principal is tTnNcCy.
The default least privilege of the GROUP and EVERYONE principals 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. To prevent potential issues, we recommend that you use either NFSv4 ACLs or POSIX ACLs.
If you configure an NFSv4 ACL for the dir0 directory, the following permissions are required.
- Run the following command to obtain the permissions on dir0:
```
sudo nfs4_getfacl dir0
```
- Sample command output:
```
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.
- Run the following command:
```
sudo getfacl dir0
```
- Sample command output:
```
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.
- Run the following command:
```
sudo nfs4_getfacl dir0/file
```
- Sample command output:
```
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.
- Run the following command:
```
sudo getfacl dir0/file
```
- Sample command output:
```
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 100,000 different 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 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 privilege 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. Example:
- Run the following command:
```
getfacl myfile
```
- Sample command output:
```
# 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 umask of a file to which a POSIX ACL is applied. You can configure permissions on the file by modifying the POSIX ACL.
For example, an ACE that grants the players group the read and write permissions on the myfile file. Example:
- Run the following command:
```
getfacl myfile
```
- Sample command output:
```
# file: myfile
# owner: root
# group: root
user::rw-
user:player:rw-
group::rw-
group:players:rw-
mask::rw-
other::---
```
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 granted by POSIX ACLs to non-reserved users are the same after you modify permissions by using the umask. Non-reserved users include all users except for the users of the owner, group, and other classes. Example:
- Run the following command:
```
getfacl myfile
```
- Sample command output:
```
# 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 on Linux. The execute operation is allowed by the backend of NAS. However, to ensure that the execute permissions in the ACL are 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 permissions on the myfile file, the player user cannot execute the file. Example:
- Run the following command:
```
getfacl myfile
```
- Sample command output:
```
# 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. Example:
- Run the following command:
```
getfacl myfile
```
- Sample command output:
```
# 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
To prevent potential issues, we recommend that you apply either NFS4 ACLs or POSIX ACLs to an NFS file system.
The umask cannot be modified.
The umask 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 UIDs or GIDs across multiple instances.
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 on 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.

You can print POSIX ACLs by using extended attributes.

Run the following command:

getfattr -n system.posix_acl_access file

Sample command output:

# file: file
system.posix_acl_access=0sAgAAAAEAAAD/////AgAFACAEAAAEAAAA/////xAABQD/////IAABAP////8=

You can use tools such as cp to migrate POSIX ACLs.
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.
- Example 1: Migrate the ACL permissions on the file.
  1. Run the getfacl file1 command to view the ACL permissions on file1.
```
# file: file1
# owner: root
# group: root
user::rw-
user:player:r--
group::r--
mask::r--
other::r--
```
  2. Run the cp --preserve=xattr file1 file2 command to copy the ACL of file1 to file2.
  3. Run the getfacl file2 command to view the ACL permissions on file2.
```
# file: file2
# owner: root
# group: root
user::rw-
user:player:r--
group::r--
mask::r--
other::r--
```
- Example 2: Migrate the ACL of a directory.
  1. Run the getfacl dir1 command to view the ACL permissions on dir1.
```
# file: dir1
# owner: root
# group: root
user::rwx
user:player:r-x
group::r-x
mask::r-x
other::r-x
```
  2. Run the cp -ar dir1 dir2 command to copy the ACL of dir1 to dir2.
  3. Run the getfacl dir2 command to view the ACL permissions on dir2.
```
# file: dir2
# owner: root
# group: root
user::rwx
user:player:r-x
group::r-x
mask::r-x
other::r-x
```
The number of POSIX ACLs is limited.
By default, NAS supports a maximum of 100,000 different 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.

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 umask and ACLs become more complex after deny ACEs are applied. This is because deny features do not exist in the umask.
- If deny ACEs are available, you may need to add several ACEs to an ACL when the umask is changed. For example, if you change the umask 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 modify the umask, 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.