Support

This is strange. I do not see any references to getSignature anywhere.

Can you please re-run this with --verbose and give me the debug backtrace?

Can you please use this dev release instead? https://www.akeeba.com/download/unite-dev/5-1-0-dev202308020828-rev6dfb0ab/unite-package-5-1-0-dev202308020828-rev6dfb0ab-zip.zip. I believe this will address the issue you are facing.

That's probably because you are giving it an Access / Secret Key combination which does not allow the S3 listObjects API call.

When you are trying to import from S3 you only give it the name of a single backup archive, the one with the .jpa, .jps, or .zip extension. UNiTE needs to know if this is a split archive i.e. if it has parts named .j01, .j02, … / .z01, .z02, … To do that, it needs to list the objects (files) in the bucket. This requires calling listObjects. If your user —as defined by the Access and Secret Key combination— does not have the permission to do that UNiTE cannot know what to download, so it errors out instead of doing something potentially stupid.

You would also get the same error if the access / secret keys are wrong, the region is wrong (for v4 signatures), or the signature type is wrong. In all cases, the call to listObjects fails and you get an error in return.

The trace actually confirms what I said.

Note that the code we use to connect to the S3 API has not changed. It's https://github.com/akeeba/s3 which we also use in Akeeba Backup itself. However, we don't list files in Akeeba Backup. We only write and delete files. This is why you never noticed a problem; that part of the code does not run there.

However, you're right in saying that you didn't observe an error in the past. It was a bug that was fixed :) Previous versions of UNiTE ignored the problem of the S3 API returning nothing  and tried to download just the one file (.jpa, .jps, or .zip) you had specified in the job XML file. I suspect that since you had single-part archives you never noticed this being a problem.

In this version we use the progress bar from the Symfony Console package. We pass the total file size read from the S3 API for all part files as its max length argument. When the S3 API fails to return a file listing this is zero and causes the progress bar to emit an error. The root cause is not the S3 API code (which hasn't changed and used in Akeeba Backup), nor the Symfony progress bar; it's that the S3 API returns no file listing.

For what it's worth, it's not a problem in UNiTE's logic either. I have tested this with a multi-part (10 parts) archive using Amazon S3 proper and it works.

It would appear that something's up with Wasabi. Can you try using your credentials with s3cmd using its ls command to list the contents of your bucket? s3cms uses boto3, the official S3 API implementation for Python and is maintained by Amazon Web Services itself. This will tell us if the problem is with the Wasabi credentials, or at least their implementation of the S3 API.

Side notes:

Using Wasabi with S3: https://knowledgebase.wasabi.com/hc/en-us/articles/115001757791-How-do-I-use-s3cmd-with-Wasabi-

You can totally use v4 signatures with Wasabi. The regions are the part between s3 and wasabisys.com in the URLs found in https://knowledgebase.wasabi.com/hc/en-us/articles/360015106031-What-are-the-service-URLs-for-Wasabi-s-different-regions-. I have confirmed this with another user and long-time friend a few months ago.

Stupid question before I pay Wasabi for an account. Are you using the same credentials, signature, region, and endpoint in UNiTE as Akeeba Backup?

So, I did try with Wasabi and found it to be working. Here are the relevant settings from my YAML file:

siteInfo:
  package: myfile.jpa

s3:
  accesskey: MYACCESSKEY
  secretkey: secretSECRETsecretSECRET
  signature: v2
  bucket: mybucket
  endpoint: s3.eu-central-2.wasabisys.com
  filename: myfile.jpa
  ssl: 1

This is for a bucket in the eu-central-2 region (Germany) of Wasabi using the v2 signature.

While troubleshooting this I noticed that it would never apply the setting for a v4 signature if you were using a custom endpoint. Moreover, Wasabi has a non-compliant version of the v4 signature. Unlike Amazon S3, they do not want us to put the Date header into the string to sign (whereas Amazon S3 proper requires it, that's why I am saying it's non-compliant). I added a workaround for Wasabi's broken v4 signature calculation and fixed the S3 v4 signature feature to work with custom endpoints as well. You will find a new dev release in https://www.akeeba.com/download/unite-dev/5-1-0-dev202308081335-rev3fe24b1.html. Using that dev release you can use the following settings in the S3 section, properly using v4 signatures:

s3:
  accesskey: MYACCESSKEY
  secretkey: secretSECRETsecretSECRET
  signature: v4
  region: eu-central-2
  bucket: mybucket
  endpoint: s3.eu-central-2.wasabisys.com
  filename: myfile.jpa
  ssl: 1

So, I am not sure what you are doing in your configuration file. Is it possible you're using the wrong endpoint or bucket name? I know I already asked you to check the endpoint, but I am not sure if you did.

Another thing, is that if your bucket name contains dots it might cause problems with the way SSL works on Wasabi's (and Amazon's) end. If you are using such a bucket, please instead use a bucket which has dashes instead of dots.

You're welcome!