What are common EFS access point configurations?

Last updated: 2022-07-13

What are common Amazon Elastic File System (Amazon EFS) access point configurations that work correctly or that cause mount errors?

Resolution

Before reviewing the access point configurations, make sure that you're aware of the following:

How Amazon EFS authenticates clients or overrides authentication when required

  • EFS files and directories support standard Unix-style read, write, and run permissions based on the user ID and group IDs.
  • If an NFS client mounts the file system without an access point, then the user and group IDs provided by the client are trusted and used.
  • By default, root squashing isn't turned on. Amazon EFS behaves like a Linux NFS server with no_root_squash. For more information, see No root squashing.
  • If a user or group ID is 0, then Amazon EFS treats that user as the root user, and bypasses permissions checks. To override the user ID and Group ID used by the NFS client, you can use EFS access points. Amazon EFS uses the access point IDs to indicate the owner and group owner for new files and directories that the user creates. This is "all squash" mapping behavior.
    Note: Amazon EFS doesn't examine user or group names. It uses only the numeric identifiers.

NFS mapping behavior, such as no_root_squash, root_squash and all_squash

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

Access points with non-root path and other configurations

The access point has a non-root path that didn't previously exist, such as /test. The POSIX user and Creation Info fields are blank.

Common issue: You try to mount a file system to an Amazon Elastic Compute Cloud (Amazon EC2) instance through an access point. The mount fails if the access point's path directory (/test, in this example) doesn't exist in the file system.

Resolution: Create a directory before using or mounting a file system without using an access point. Or, specify the Creation Info when creating or modifying the access point.

The access point has a non-root path that didn't previously exist, such as /test. The POSIX user is configured (for example, 1000:1000). The Creation Info field is blank.

Common issue: When you try to mount a file system to an EC2 instance through an access point, the mount fails. This is because the access point's path directory (/test, in this example) doesn't exist in the file system.

Resolution: Create a directory before using or mounting a file system without using an access point. Or, specify the Creation Info when creating or modifying the access point.

The access point has a non-root path that didn't previously exist, such as /test. POSIX user (for example, 1000:1000) and the Creation Info field is completed (for example, 1000:1000 (0755) ).

You won't have mount issues with this configuration.

Access points with a root path and other configurations

If you don't specify the "path" value when creating an access point, then EFS uses the file system's root directory as the path to the access point. In this scenario, the file system allows only the root account of the OS to perform file system operations such as read, write, and run. This is because you aren't allowed to change the permissions of the root directory in file systems that are set up like this.

But when user enforcement is turned on, Amazon EFS replaces the NFS client's user and group IDs with the identity configured on the access point for all file system operations. This option conflicts on the EFS server side of the file system.

The access point has a root path " / " and the POSIX user and Creation info field is blank.

You won't have mount issues with this configuration. This configuration is the same as using an EFS file system without using an access point. Only the root user can create or modify files.

The access point has a root path " / " and the POSIX user is set to 0:0. The Creation info field is blank.

You won't have mount issues with this configuration. This is because the all_squash mapping makes it appear that all operations are performed with the root account, which enforces a user identity. This configuration is the same as using an EFS file system without using an access point. Only the root user can create or modify files.

The access point has a root path " / " and the POSIX user is set to 1000:1000. The Creation info field is blank.

You won't have mount issues with this configuration. This is because the all_squash mapping makes it appear that all operations are performed with the account that has 1000 UID/GID numeric identification. You can't create or modify files even if you're using sudo commands with this configuration.

The access point has a root path " / " and the POSIX user is set to 1000:1000. The Creation info field is set to 1000:1000 0755.

EFS automatically creates the specified root directory with these permissions if the directory doesn't already exist. But because of the all_squash mapping, users can't write to the file system at all.

Note: Creation info doesn't affect the EFS file system because the root directory (/) already exists.

Common issue: Users can't perform any file operations because of the ownership conflict.

Resolution:

  • Don't use "/" as a path for an access point.
  • Use 0:0 as a POSIX user and don't use Creation info, which isn't required.

Access points with a non-root path (for example, /test ), POSIX user as 0:0, and the Creation info field as 0:0 (0755)

You won't have mount issues with this configuration due to all_squash mapping. The all_squash mapping makes it appear that all operations are performed with the root account (enforcing a user identity). This is true even though the user is a non-root user.

Access points with a non-root path (for example, /test ), POSIX user as 1000:1000 and Creation info field as empty

Note: Create a path /test for the access point.

You won't have mount issues with this configuration. But note that all files and directories are owned by an account that has the numeric identification UID 1000 and GID 1000.

Access points with a non-root path (for example, /test ), Creation info field as 0:0 (0755), and the POSIX user is empty

You won't have mount issues with this configuration. But, sudo must be used for file operations.


Did this article help?


Do you need billing or technical support?