What are common Amazon EFS access point configurations?

Short description

Amazon EFS authenticates clients or overrides authentication in the following ways:

• Amazon EFS files and directories support standard Unix-style read, write, and run permissions based on the user identification (UID) and group identification (GID).
• If an NFS client mounts the file system without an access point, then the UID and GID that the client provides are trusted and used.
• By default, root squashing is turned off. Amazon EFS behaves similar to a Linux NFS server with no_root_squash.
• If a UID or GID is 0, then Amazon EFS regards the user as the root user and bypasses permissions checks. Use EFS access points to override the UID and GID that the NFS client uses.
  Note: Amazon EFS doesn't review user or group names. Instead, Amazon EFS uses only the numeric identifiers.

The following are NFS mapping options:

• root_squash maps requests from the UID or GID 0 to the anonymous UID or GID. This doesn't apply to any other UIDs or GIDs that are equally sensitive, such as user bin or group staff.
• no_root_squash turns off root squashing. Use this option for diskless clients.
• all_squash maps all UIDs and GIDs to the anonymous user. Use this option for NFS-exported public FTP directories, news spool directories, and so on. The opposite option is the default no_all_squash setting.

Use one of the following configurations based on your use case.

Resolution

Access points with a non-root path and other configurations

The access point has a non-root path that didn't previously exist, for example "/test". You keep the PosixUser and CreationInfo fields blank.

You use an access point to mount a file system to an Amazon Elastic Compute Cloud (Amazon EC2) instance. However, the mount fails because the access point's path directory doesn't exist in the file system.

To resolve this issue, create a directory before you use or mount a file system without an access point. Or, specify the creation information when you create or modify the access point.

The access point has a non-root path that didn't previously exist. You specify the PosixUser and keep the CreationInfo field blank.

You use an access point to mount a file system to an EC2 instance. However, the mount fails because the access point's path directory doesn't exist in the file system.

To resolve this issue, create a directory before you use or mount a file system without an access point. Or, specify the creation information when you create or modify the access point.

The access point has a non-root path that didn't previously exist. You specify the PosixUser and the CreationInfo.

There are no mount issues with this configuration.

The access point has a non-root path that didn't previously exist. You specify the PosixUser as 0:0 and the CreationInfo as 0:0 (0755).

There are no mount issues with this configuration. The all_squash mapping makes it appear that all operations are performed with the root account, even though the user is a non-root user.

The access point has a non-root path that didn't previously exist, for example "/test". You specify the PosixUser as 1000:1000 and keep the CreationInfo field blank.

Note: Before you mount, create a path /test for the access point.

There are no mount issues with this configuration. All files and directories that under the /test access point are owned by an AWS account that has the numeric identification UID 1000 and GID 1000.

The access point has a non-root path that didn't previously exist, for example "/test". You specify the CreationInfo as 0:0 (0755), and keep the PosixUser field blank.

There are no mount issues with this configuration. However, you must use sudo for file operations.

Access points with a root path and other configurations

If you don't specify the path value when you create an access point, then Amazon EFS uses the file system's root directory. Because you can't change the root directory's permissions in the file system, only the root account of the operating system (OS) can perform file system operations. When you turn on user enforcement, Amazon EFS replaces the NFS client's user and group IDs with the identity that's configured on the access point. The identity is used for all file system operations. This option conflicts on the Amazon EFS server side of the file system.

The access point has a root path " / ", and you keep the PosixUser and CreationInfo fields blank.

There are no mount issues with this configuration. This configuration is the same as when you don't use an access point for the file system. Only the root user can create or modify files.

The access point has a root path " / ". You specify the PosixUser as 0:0 and keep the CreationInfo field blank.

There are no mount issues with this configuration because the all_squash mapping makes it appear that all operations are performed with the root account. This configuration is the same as when you don't use an access point for the EFS file system. Only the root user can create or modify files.

The access point has a root path " / ". You specify the PosixUser as 1000:1000 and keep CreationInfo field blank.

There are no mount issues with this configuration because all_squash makes it appear that operations are performed with the account that has 1000 UID/GID numeric identification. You can't create or modify files even when you use sudo commands.

The access point has a root path " / ". You specify the PosixUser as 1000:1000 and the CreationInfo as 1000:1000 (0755).

If the directory doesn't exist, then Amazon EFS automatically creates the specified root directory with these permissions. However, because of all_squash, users can't write to the file system.

Note: The information in the CreationInfo field doesn't affect the EFS file system because the "/" root directory already exists.

However, users can't perform file operations because of the ownership conflict.

To resolve, this issue don't use " / " as a path for an access point. Use 0:0 as a PosixUser, and don't specify a value in the CreationInfo field.