How to keep or specify ContentType of object to upload?

[neko-kawaii-nyan]

Mountpoint for Amazon S3 version

mount-s3 1.2.0

AWS Region

ap-northeast-1

Describe the running environment

Running in EC2 on Amazon Linux 2 using instance profile credentials against an S3 Bucket in the another account.

What happened?

I use S3 as a CloudFront backend for website hosting purposes. Therefore, the html file placed in S3 must be displayed as a web page when accessed by a browser, but if placed via mount-s3, the ContentType will be binary/octet-stream, so the html file will be downloaded.

Is there any way to modify the ContentType of the object being uploaded to text/html?

[ec2-user@ip-10-0-54-13 ~]$ mount-s3 --version
mount-s3 1.2.0
[ec2-user@ip-10-0-54-13 ~]$ sudo mount-s3 mybucket /s3 --uid 900 --gid 900 --allow-other --log-directory /var/log/mounts3 --debug
[ec2-user@ip-10-0-54-13 ~]$ file --mime-type index.html
index.html: text/html
[ec2-user@ip-10-0-54-13 ~]$ sudo cp index.html /s3/b.html
[ec2-user@ip-10-0-54-13 ~]$ aws s3api head-object --bucket mybucket --key b.html --query ContentType
"binary/octet-stream"

This is probably the same behavior as #471 .

Relevant log output

No response

[ahmarsuhail]

thanks for opening an issue @neko-kawaii-nyan. This is not something Mountpoint supports currently, we will be investigating if this is something we can support in the future. We are updating this to be a feature request.

[neko-kawaii-nyan]

Thank you for your reply. Is there any additional information I should provide here for the feature request?

[sam9191]

I have the same problem. .css file won't work on a web page because its content-type is binary/octet-stream. If mountpoint-s3 can automatically set the correct content-type when it uploads a file to the S3 bucket, would be great.

[gerard67]

Hello,

just adding to the case as I get this same annoying "issue"... A configuration option in mount-s3 to apply Mailcap mime-types when uploading to S3 would be very usefull

[sagebind]

Perhaps extended attributes could somehow be leveraged to allow specifying content type (and perhaps other object metadata as well)? FUSE does support xattrs so it may be possible.

When uploading, the user would probably have to call fsetxattr on a new filesystem node after the file is created and opened for writing, and before writing any data, so that the attributes are all accessible to Mountpoint before it makes the first call to upload the object so it can include the desired headers.

It would be neat if the user.mime_type extended attribute defined by XDG were to be mapped automatically to object content type. If you were to use this for writes and exposed this extended attribute when reading as well, then file copies that preserve extended attributes would also preserve the S3 object content type.

For extra credit, other object metadata you could do an automatic header translation into an extended attribute namespace. For example, x-amz-meta-mykey could be exposed through Mountpoint as user.s3.x_amz_meta_mykey.

[infrahead]

Interesting ideas @sagebind but I wonder if that approach would add too much friction for different programming environments and runtimes vs normal file APIs and automatic detection. Maybe for advanced use cases.

IIRC, the AWS CLI does automatic mime-type detection (based on file extension?) and that would seem to me to be best starting place for Mountpoint as well.

[sagebind]

Automatic content type detection wouldn't work for our particular use-case (though it would be a good addition overall), as one of the things we currently are using Mountpoint for is to enable piping files into our file processing stack. One such feature of the file processing stack is to detect the content type of a file using our own more advanced file identification suite, so we already know with great accuracy what the format of the file is. Any sort of auto-detection would likely be a downgrade of the information our code already knows.

For files where it is important for the content type set in S3 to be accurate, we're currently not using Mountpoint and instead writing the output of the processing stack to a temporary file, then using the S3 SDK to upload the file using the known content type. If Mountpoint allowed us to explicitly specify the content type through the file system somehow, that would allow us to bypass that step and allow the file processing to stream its result into S3 directly via Mountpoint.

[bernard-drb]

Hey everyone, any news related to this issue? We are facing this same problem when using EKS Pod + S3 CSI Driver + Mountpoint. A report app generates some html+css files that is outputted in a mountpoint, which are sent the S3 bucket. But, in the bucket, metadata are all set as "binary/octet-stream", making the browser downloads the index.html file instead of rendering it.

[Jusedawg]

"This is not something Mountpoint supports currently, we will be investigating if this is something we can support in the future. We are updating this to be a feature request."

You certainly can do it. ---acl=public-read,--use-content-type are the only two options I can see that are missing and make this almost useless for anything you are trying to make publicly accessible like web images as they won't be public or have the right content type. Goofys does it now on older instance types where it actual compiles, but it doesn't work on Amazon Linux 2023 yet.

https://github.com/kahing/goofys

What a sample fuse mount in fstab should look like using theirs and yours shouldn't really be any different. Not sure what the exact syntax is for yours though as the documentation isn't very verbose or clear.

/root/work/bin/goofys#some-public-files:banners /mnt/s3/banners fuse _netdev,allow_other,--file-mode=0660,--dir-mode=0770,--uid=80,--gid=80,--acl=public-read,--use-content-type 0 0

/usr/bin/mount-s3 --prefix banners/ some-public-files /mnt/s3/banners fuse _netdev,--allow-other,--file-mode=0660,--dir-mode=0770,--uid=80,--gid=80,--acl=public-read,--use-content-type 0 0