Files coming in from s3 to FSx have their default ACL mask being overwritten. Ignoring the set default ACL mask.

Question

I have an FSx filesystem to access files on S3 using the data repository feature.
I am using the following command the make sure the ubuntu user can access all files on the FSx mount: `sudo setfacl -R -d -m u:ubuntu:rwx /fsx`
This sets the default ACL to allow the ubuntu user full permissions to all files. This means that when a new file is created in the FSx mount it automatically sets the correct ACL for that file.

Here is the output of `getfacl /fsx`:

```
# file: fsx/
# owner: root
# group: root
user::rwx
user:ubuntu:rwx
group::r-x
mask::rwx
other::r-x
default:user::rwx
default:user:ubuntu:rwx
default:group::r-x
default:mask::rwx
default:other::r-x
```

When I create a file in the /fsx dir using sudo `sudo touch /fsx/s3_bucket/test.txt` all permissions are set correctly so that the ubuntu user and read and write to that file. See output of `getfacl /fsx/s3_bucket/test.txt` below.

```
# file: test.txt
# owner: root
# group: root
user::rw-
user:ubuntu:rwx                 #effective:rw-
group::rwx                      #effective:rw-
mask::rw-
other::r--
```

However when I add a file to S3 that is then being synced to FSx (using the webinterface or S3 API) it does not set the ACL correctly.
Here you can see the output of `getfacl /fsx/s3_bucket/s3_upload.txt`

```
# file: s3_upload.txt
# owner: root
# group: root
user::rwx
user:ubuntu:rwx                 #effective:r-x
group::rwx                      #effective:r-x
mask::r-x
other::r-x
```

Notice that the mask of s3_upload.txt is `r-x` preventing the ubuntu user from writing to that file. You can see the default ACL giving the ubuntu user rwx rights is being applied but the mask is causing the effective permissions to be `r-x`. This does not happen when I create new file directly on the FSx mount.

The problem is that the ubuntu user is not allowed to write to files on FSx that were uploaded to S3 via the web interface or API because it ignores the default ACL mask.

Anganam_S · Answer

Hello,

Thank you for reaching out.

Kindly note, when importing objects from S3 that don't have POSIX permissions configured in the user-defined metadata[1][2], the default POSIX permission that FSx for Lustre assigns to a file is 755. This permission allows read and execute access for all users and write access for the owner of the file. Please see the FSx for Lustre user guide[3] used as reference

To ensure that your ubuntu user has access to files directly upload to S3, you need to ensure the files are uploaded using at least the following user-defined metadata

`x-amz-meta-file-permissions` -  The file type and permissions in the format , consistent with st_mode in the Linux stat(2) man page https://man7.org/linux/man-pages/man2/lstat.2.html . Please

`x-amz-meta-file-owner` – The owner user ID (UID) expressed as an integer.

`x-amz-meta-file-group` – The group ID (GID) expressed as an integer.

***EXAMPLE:***

```
x-amz-meta-file-permissions : 0100775
x-amz-meta-file-owner : 1001
x-amz-meta-file-group : 1001
```

This permission allows read and execute access for **OTHER** users, and read,write & execute access for the owner with **UID 1001** & group with **GID 1001** the file is associated with.  "010" octal file type in x-amz-meta-file-permissions stands for a regular file, please see link [3] & [5] and 0775 represents the octal permission mask

***REFERENCE***

[1] User-defined object metadata - https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingMetadata.html#UserMetadata

[2] Editing object metadata in the Amazon S3 console - https://docs.aws.amazon.com/AmazonS3/latest/userguide/add-object-metadata.html

[3] POSIX metadata support for data repositories - https://docs.aws.amazon.com/fsx/latest/LustreGuide/posix-metadata-support.html

[4] https://codegolf.stackexchange.com/questions/220255/filetype-color-codes

[5] https://en.wikipedia.org/wiki/Unix_file_types#Numeric

Files coming in from s3 to FSx have their default ACL mask being overwritten. Ignoring the set default ACL mask.

Relevant content