AWS S3 Server side encryption Access denied error

Question

• I have A and B AWS accounts and I am syncing S3 bucket from A account SoruceS3Bucket to B account DestinationS3Bucket.
• Following is the bucket policy which is applied on Destination bucket and it is allowing Source AWS account to sync the content with DestinationS3Bucket.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "PermissionsToAAccount",
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::XXXXXXX:root"
            },
            "Action": "s3:*",
            "Resource": [
                "arn:aws:s3:::DestinationS3Bucket",
                "arn:aws:s3:::DestinationS3Bucket/*"
            ]
        }
    ]
}

• Here the sync was working perfectly since long time and it is still working but from last few days at the DestinationS3Bucket files are not accessible with the Server side encryption Access denied error.
• I have verified there no encryption(Default encryption, none) on SourceS3Bucket and DestinationS3Bucket and I am using Source AWS account secret and access key to sync the content. Thanks in advance.

Answer 1

When you copy files from one S3 bucket in account A using credentials of account A to a bucket in account B, the owner of the files in the destination bucket will be account A. (Account A is the principal that created the files in account B's bucket).

During the file copy from source to destination bucket, add the --acl bucket-owner-full-control option so that account B can control the files. Otherwise you might have files in account B's bucket that account B cannot access or control.

Another option is to use the credentials of account B to copy from the source to the destination bucket. This way the owner of the copied files is account B.

Answer 2

Solution provided by John Hanely works, but that does not immediately change the ownership. You would need to execute a separate command to change it

First Step:

aws s3 cp s3://yourbucket s3://yourbucket --recursive --acl bucket-owner-full-control

Second Step:

aws s3 cp s3://yourbucket s3://yourbucket --recursive --metadata-directive REPLACE

Notice --meta-directive REPLACE

Answer 3

您应该以这种方式一起替换文件和元数据 -

aws s3 cp s3://yourbucket s3://yourbucket --recursive --acl bucket-owner-full-control --metadata-directive REPLACE

Answer 4

You don't need to cp it.

Assumptions: You have access to the offending account and that account has putobjectacl policy permissions.

Tells you who put the file and who has access:

$ aws s3api get-object-acl --bucket yourbucket --key path/to/file
{
    "Owner": {
        "DisplayName": "the-account-putting-the-thing",
        "ID": "offendingaccountrandomidstringthatisntrelaventhere"
    },
    "Grants": [
        {
            "Grantee": {
                "DisplayName": "the-account-putting-the-thing",
                "ID": "offendingaccountrandomidstringthatisntrelaventhere",
                "Type": "CanonicalUser"
            },
            "Permission": "FULL_CONTROL"
        }
    ]
}

To fix this so the destination owner now controls the file:

$ aws s3api put-object-acl --bucket yourbucket --key path/to/file --acl bucket-owner-full-control
$ aws s3api get-object-acl --bucket yourbucket --key path/to/file
{
    "Owner": {
        "DisplayName": "the-account-putting-the-thing",
        "ID": "offendingaccountrandomidstringthatisntrelaventhere"
    },
    "Grants": [
        {
            "Grantee": {
                "DisplayName": "the-account-putting-the-thing",
                "ID": "offendingaccountrandomidstringthatisntrelaventhere",
                "Type": "CanonicalUser"
            },
            "Permission": "FULL_CONTROL"
        },
        {
            "Grantee": {
                "DisplayName": "the-account-recieving-the-thing",
                "ID": "destinationaccountrandomidstringthatisntrelaventhere",
                "Type": "CanonicalUser"
            },
            "Permission": "FULL_CONTROL"
        }
    ]
}

I didn't have any issues manipulating the file after changing the acl vi s3api from the destination / owner account role.

Special thanks to the previous answerees. Without you, I wouldn't have been able to fix my mistake.