On my current project we are using DataSync to move data from an S3 bucket to an FSx ONTAP device via NFS. The transferred data is subsequently consumed and modified by another process that needs to have permissions to that data.
Unfortunately, by default, AWS DataSync sets the default POSIX permissions to 755 with an owner UID:GID of 65534:65534 (aka anonymous) when transferring from S3 to NFS. This was preventing our subsequent process from modifying and moving files to subsequent locations on the FSx ONTAP device.
However, on that same user guide page further up, AWS DataSync data that is copied from NFS to S3 maintains the original permissions as S3metadata. The metadata is used with AWS Storage Gateway or if you DataSync the data back to an NFS share. Based on this information, I was confident that we could set said metadata on our S3 objects and have them land with the correct permissions. Sadly, it does not tell you what that metadata looks like.
Well friends, I’m here to help!
First, I found this AWS blog article about how you can setup DataSync to replicate your NFS server to an S3 bucket. In the article, there’s a picture of a file’s metadata!

Lo-and-behold, adding the following metadata block to an object via put-object or copy-object, allowed for the file to land on the FSx ONTAP server with the correct UID, GID, and permission set.
{
"user-agent": "aws-datasync",
"file-owner": "999",
"file-permissions": "100755",
"file-group": "416636"
}
This worked well and good for the files. However, the root folder the DataSync destination was attached to on the FSx ONTAP kept getting it’s permissions overwritten with the default permissions – 755 with an owner UID:GID of 65534:65534. “Folders” don’t really exist in S3, they are a manifestation of the key’s name when it includes a “/”.
Searching didn’t save us, and we had to stand up a quick NFS to S3 environment. We transferred some files with various permissions and looked at what ended up in the S3 bucket. Sadly, it looked the same from the AWS portal – a “folder” with some files in it, with no ability look at a folder’s metadata.
However, upon further analysis…
$ aws s3api head-object --bucket <bucketname> --key "<folder>/"
{
<stuff />
"Metadata": {
"folder-group": "416636",
"user-agent": "aws-datasync",
"folder-permissions": "100777",
"file-owner": "999",
"file-permissions": "100755",
"file-group": "416636",
"folder-owner": "999"
},
<moreStuff />
}
DataSync is creating an actual “folder object” that has the metadata attached to it (e.g. “folderName/”)!
Using that understanding, in our source S3 bucket we created the correct “folder object” with the right metadata attached to it. The “folder object” is set as the the DataSync source folder. And now when the DataSync task runs, the correct permissions are set on the subsequent root destination folder!
Leave a Reply