S3 Plugin: Error Uploading to S3 Bucket Any File Larger than 5MB

-- HikaShop version -- : 6.6.0
-- Joomla version -- : 6.1.4
-- PHP version -- : 8.5
-- Browser(s) name and version -- :  Chrome 154.0
-- Error-message(debug-mod must be tuned on) -- : Error

A client of mine purchased your Amazon S3 plugin at my prompting.

It is working fine except for this one issue:

• Any file larger than 5MB shows an 'error' in the Status area of the "Move the files to the bucket" section.
• Any file smaller than 5MB uploads successfully to the S3 bucket, showing OK in the Status area.

I have repeated this and verified the S3 bucket contents.

There are no errors in the Hikashop error log or php.error.log
The debug switch is on.

ps - love your new website redesign!

Here is the policy attached to the bucket in an attempt to fix the issue. This doesn't look like an IAM/S3 issue.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "BucketListAndLocation",
      "Effect": "Allow",
      "Action": [
        "s3:ListBucket",
        "s3:GetBucketLocation",
        "s3:ListBucketMultipartUploads"
      ],
      "Resource": "arn:aws:s3:::YOUR-BUCKET-NAME"
    },
    {
      "Sid": "ObjectReadWrite",
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject",
        "s3:DeleteObject",
        "s3:AbortMultipartUpload",
        "s3:ListMultipartUploadParts"
      ],
      "Resource": "arn:aws:s3:::YOUR-BUCKET-NAME/*"
    }
  ]
}

Hi Michael,

Thanks, glad you like the new site.

Files up to 5 MB are sent to S3 in a single request, and larger ones with a multipart upload, so that is where the two cases differ. We ran the same "Move the files to the bucket" screen with 6 MB and 23 MB files against an S3-compatible storage on Joomla 6.1.4, HikaShop 6.6.0 and PHP 8.5, and they were moved without problem, so the cause should be on your server or on the bucket.

When Amazon refuses a file, the plugin shows Amazon's message in the Status column (for example "AccessDenied: ..."). The plain word "error" means something else: the request to your own website failed or came back empty, typically because of a server or proxy timeout or a PHP error. To make this easier to diagnose, we released version 1.0.1 of the plugin, which your client can download from their account. With it, the Status column gives the HTTP code when the request to your website fails, for example "error (HTTP 504 from your server)", and with the debug option of the plugin on, every file that could not be moved is written to the HikaShop log with its reason. Could you install it over the current one, try again with a file over 5 MB, and send us what the Status column shows and the matching lines of the HikaShop log? If it gives an HTTP code, the PHP error log of the server, or the error log of your hosting panel, for the same minute would also help.

You can access the log in the "Payment log file" setting of the HikaShop configuration page.

If the Status column shows a message from Amazon instead, the most common cause is the bucket's default encryption: with a KMS key (SSE-KMS), multipart uploads need the kms:Decrypt permission on that key in addition to kms:GenerateDataKey, while single uploads work without it. You can check it in the AWS console, in the bucket's Properties tab, under "Default encryption".

Best regards,
Nicolas

Installed the updated S3 plugin.

Here is the Status: error (empty answer from your server)

There isn't anything in the Hikashop error log:
media/com_hikashop/upload/safe/logs/report_539496696.log

This is a brand-new cPanel server with WHM.
Perhaps a port needs to be opened on the firewall?
Or does a PHP Module or extension need to be added to Apache?

Thank you, that message was the clue we needed. It does not come from your server: it comes from the plugin itself. For files over 5 MB the plugin sends the file to Amazon in several parts. When Amazon refused one of them, the plugin cancelled the upload and, in doing so, lost Amazon's error message, so the screen had nothing to show and nothing was written to the log. Files of 5 MB or less are sent in one go, which is why only the larger ones were affected.

We corrected this in version 1.0.2 of the plugin. With it, the Status column and the HikaShop log give Amazon's own reason when a large file is refused. Once it is available in your client's account, please install it over the current version, try a file over 5 MB again and send us what the Status column shows.

In the meantime, here are the two most likely causes, which you can also check:

1. The bucket's default encryption. In the AWS console, open the bucket's Properties tab and look under "Default encryption". If it uses a KMS key (SSE-KMS), the IAM user of the plugin needs the kms:Decrypt permission on that key in addition to kms:GenerateDataKey. Large files need it and small ones don't.

2. The upload speed from your server to the bucket. Large files are sent in parts of 10 MB, and each part has 30 seconds to reach Amazon. A slow connection from the hosting to the bucket's region, or a bucket in a region far from the server, can make the parts fail while small files still go through.

I installed plg_hikashop_s3-1.0.2
This is in the Status area when moving the files to the bucket:

• SignatureDoesNotMatch: The request signature we calculated does not match the signature you provided. Check your key and signing method.

The new upload code is signing the part incorrectly:

• SignatureDoesNotMatch on a file over 5MB after the update. Files under 5MB still upload. Bucket is SSE-S3 in us-east-2. Endpoint blank, path-style off, region us-east-2.
• The secret was re-saved and the small-file signature still matches, so the key is valid. The mismatch is on the multipart part request: canonical URI, signed headers, or payload hash for UploadPart, not the IAM policy.

This is from the Amazon AI (also see response below it):

That changes things. Your bucket is using SSE-S3 (S3-managed keys), not SSE-KMS. With SSE-S3, AWS manages the encryption keys entirely — there is no KMS key involved at all.
This means:

• Code:

  kms:Decrypt
  and
  
  Code:

  kms:GenerateDataKey
  are not needed — these are KMS-specific permissions and have no effect with SSE-S3.
• S3 handles all encryption and decryption transparently on its own, regardless of file size.
• The IAM user only needs the standard S3 permissions (e.g.
  
  Code:

  s3:GetObject
  ,
  
  Code:

  s3:PutObject
  ) to read and write objects.

So the behavior you're seeing — where large files fail but small ones don't — is likely not a KMS permissions issue. The root cause is probably something else, such as:

• Code:

  s3:GetObject
  not being allowed for the user on larger objects (though this would affect all sizes equally).
• Multipart upload/download permissions — large files often use multipart operations, which require additional actions like
  
  Code:

  s3:GetObject
  with range requests, or
  
  Code:

  s3:CreateMultipartUpload
  ,
  
  Code:

  s3:UploadPart
  ,
  
  Code:

  s3:CompleteMultipartUpload
  .
• Request timeouts or size limits configured in the plugin or a proxy in front of it.

---

From Grok:

Amazon’s conclusion is right on encryption and wrong on the fix. SSE-S3 means there is no KMS key, so drop the `kms:` block. S3 encrypts both small and large objects with the same bucket setting, and file size does not change that.

`s3:CreateMultipartUpload`, `s3:UploadPart`, and `s3:CompleteMultipartUpload` are not separate IAM actions. S3 authorizes those API calls with `s3:PutObject`, which the user already has, along with `s3:AbortMultipartUpload`, `s3:ListMultipartUploadParts`, and `s3:ListBucketMultipartUploads`. Adding those three names to the policy does nothing. The policy you have is already the full set for a private SSE-S3 bucket.

What is left is the plugin or the host. Send the developer this:

- Bucket `dr-ziw-music-downloads`, region `us-east-2`, default encryption SSE-S3, not SSE-KMS.
- IAM user can list the bucket, get its location, put, get, and delete objects, and abort or list multipart uploads. Eight files under 5MB copy and appear in the bucket. Every file over 5MB fails.
- Debug is on. Nothing is written to the HikaShop payment log or the domain PHP error log.
- Endpoint is blank. Region is `us-east-2`. Empty Region signs as `us-east-1` and returns `AuthorizationHeaderMalformed`.
- Need the response body and HTTP status from the failed move request, or the plugin’s own error string for one file over 5MB.

That 5MB line is the plugin’s multipart switch. With SSE-S3 and this policy, a permissions denial would have been `AccessDenied` on every size, not only the large files.

Thank you, that message pinpointed it. It comes from the plugin, not from your bucket or the IAM permissions. A file over 5 MB is sent to Amazon in parts, and the last request, which asks Amazon to assemble the parts, was sent with a type of content that Amazon does not accept for that request. Amazon answers it with SignatureDoesNotMatch. Other S3-compatible storage services accept it, which is why it went unnoticed in our tests. Files of 5 MB or less are sent in a single request without that problem, which is why only the larger ones failed.

So there is nothing to change on the AWS side: the default encryption (SSE-S3) and the permissions you have are fine. A real permission problem gives an "AccessDenied" message, not this one.

We corrected this in version 1.0.3 of the plugin. Please install it over the current version via Joomla's System > Install > Extensions.

I installed the plg_hikashop_s3-1.0.3 update.

SUCCESS!!!
The large MB files have been uploaded to the S3 bucket without issue.

Thank you very much!

I did receive one Status error:

• Could not reach the storage service: Recv failure: Connection reset by peer
  

I tried again to upload that file and it worked fine.