S3: uploads fail with AccessControlListNotSupported on buckets with BucketOwnerEnforced

[a-nomad]

Problem

Since April 2023, AWS S3 creates all new buckets with ObjectOwnership: BucketOwnerEnforced
by default, which disables ACLs entirely. uploadfs always sends ACL: 'public-read'
(or whatever bucketObjectsACL is set to) in every copyIn, enable, and disable call,
causing all uploads to fail with:

AccessControlListNotSupported: The bucket does not allow ACLs

Root Cause

In lib/storage/s3.js, the ACL param is always included in requests:

// copyIn
const params = {
  Bucket: bucket,
  ACL: bucketObjectsACL, // always sent, no way to disable
  ...
};

// enable / disable also always call PutObjectAclCommand

Expected Behavior

It should be possible to pass bucketObjectsACL: false (and disabledBucketObjectsACL: false)
to skip sending ACL headers entirely, for use with modern S3 buckets or S3-compatible
storage that does not support ACLs.

Suggested Fix

bucketObjectsACL = options.bucketObjectsACL === false
  ? false
  : (options.bucketObjectsACL || 'public-read');

disabledBucketObjectsACL = options.disabledBucketObjectsACL === false
  ? false
  : (options.disabledBucketObjectsACL || 'private');

Then in copyIn, enable, and disable — skip ACL if value is false.

This is fully backward compatible — existing users who don't set these options
get the same public-read default as before.

Related

• AWS announcement: https://aws.amazon.com/blogs/aws/heads-up-amazon-s3-security-changes-are-coming-in-april-of-2023/

[boutell]

You're not wrong, ACLs in S3 are not popular these days. But this would break the ability to disable public access to a file that is in the archive. The right fix would involve implementing our disabled file key approach used for local storage and azure storage. THOMAS BOUTELL | CHIEF EXECUTIVE OFFICER APOSTROPHECMS | apostrophecms.com | he/him/his

…

On Wed, Mar 25, 2026, 5:14 PM Andrii ***@***.***> wrote: *a-nomad* created an issue (apostrophecms/apostrophe#5366) <#5366> Problem Since April 2023, AWS S3 creates all new buckets with ObjectOwnership: BucketOwnerEnforced by default, which disables ACLs entirely. uploadfs always sends ACL: 'public-read' (or whatever bucketObjectsACL is set to) in every copyIn, enable, and disable call, causing all uploads to fail with: AccessControlListNotSupported: The bucket does not allow ACLs Root Cause In lib/storage/s3.js, the ACL param is always included in requests: // copyInconst params = { Bucket: bucket, ACL: bucketObjectsACL, // always sent, no way to disable ...}; // enable / disable also always call PutObjectAclCommand Expected Behavior It should be possible to pass bucketObjectsACL: false (and disabledBucketObjectsACL: false) to skip sending ACL headers entirely, for use with modern S3 buckets or S3-compatible storage that does not support ACLs. Suggested Fix bucketObjectsACL = options.bucketObjectsACL === false ? false : (options.bucketObjectsACL || 'public-read'); disabledBucketObjectsACL = options.disabledBucketObjectsACL === false ? false : (options.disabledBucketObjectsACL || 'private'); Then in copyIn, enable, and disable — skip ACL if value is false. This is fully backward compatible — existing users who don't set these options get the same public-read default as before. Related - AWS announcement: https://aws.amazon.com/blogs/aws/heads-up-amazon-s3-security-changes-are-coming-in-april-of-2023/ — Reply to this email directly, view it on GitHub <#5366?email_source=notifications&email_token=AAAH27LPEVSYLJADDU6TQCT4SRD4VA5CNFSL4Z3JMQ5C6L3HNF2C22DVMIXUS43TOVSS6NBRGM4DKOBTHA2TFJTSMVQXG33OVJZXKYTTMNZGSYTFMSSWK5TFNZ2KYZTPN52GK4S7MNWGSY3L>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAH27NP53XNETDPCYTEDWD4SRD4VAVCNFSM6AAAAACW7O5EN6VHI2DSMVQWIX3LMV43ASLTON2WKOZUGEZTQNJYGM4DKMQ> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[anjali-rayy]

Hi, I'd like to work on this fix. I plan to skip the ACL param in copyIn/enable/disable when bucketObjectsACL is false. Should I also align this with the disabled file key approach used in local/Azure storage? Happy to take guidance before submitting a PR