Akeeba Backup for Joomla!

#31899 – Amazon S3 transfer Failing

Posted in ‘Akeeba Backup for Joomla!’
This is a public ticket. Everybody will be able to see its contents. Do not include usernames, passwords or any other sensitive information.
Tuesday, 22 October 2019 15:55 CDT
Hi, we have a configured database backup every hour, which is transferred to S3. It has worked without problem for several months, until today.

Error with SSL activated:
0 :: Akeeba\Engine\Postproc\Connector\S3v4\Connector::putObject(): [60] SSL: no alternative certificate subject name matches target host name ''

Error with SLL desactivated:
413 :: Unexpected HTTP status 413

I attach both logs.

Custom Fields
Joomla! version (in x.y.z format) 3.8.13
PHP version (in x.y.z format) 7.1.32
Akeeba Backup version (x.y.z format) 6.6.1
Wednesday, 23 October 2019 04:20 CDT
While I cannot reproduce this issue I have an idea about what might be going on.

Go to the Configuration page of your backup profile and click the Configure button next to the Post-processing Engine. Set the "Bucket access" setting to "Path access (legacy)". If I recall correctly, your region (US West 2) doesn't work properly with Virtual Hosting bucket access for some buckets created before Amazon S3 started asking developer to use the Virtual Hosting access.

As for the HTTP 413 message, according to Amazon's documentation it cannot happen, meaning that it's not a documented HTTP status their REST API should ever return. It literally means Payload Too Large (the data sent to the server exceed its capacity to process information) which doesn't make sense in the context as you're trying to upload a file less than 5MB when the size limit for Amazon S3 is 5GB i.e. more than a thousand times bigger. I also see in your log that there's a subsequent 500 Internal Server Error from Amazon when we're trying to delete files. All these together make me thing that the problem may indeed be the "Bucket access" setting.

If you're wondering why this started happening now: Amazon S3 deprecated the "Path access" method for accessing bucket. As a result we changed our code to use virtual hosting bucket access by default, following Amazon's advice. I had already bumped into cases similar to yours in the past, hence the option in the configuration to keep using the legacy method that Amazon says we shouldn't be using (but requires us using for some older buckets -- go figure). It's one of those changes that you're damned if you do and damn if you don't, all because the third party vendor is exhibiting a behavior its documentation says it shouldn't be exhibiting. In other words yet another day in the life of an IT person...

Nicholas K. Dionysopoulos

Lead Developer and Director

🇬🇷Greek: native

🇬🇧English: excellent

🇫🇷French: basic

Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

Friday, 22 November 2019 17:17 CST
This ticket has been automatically closed. All tickets which have been inactive for a long time are automatically closed. If you believe that this ticket was closed in error, please contact us.
This ticket is closed, therefore read-only. You can no longer reply to it. If you need to provide more information, please open a new ticket and mention this ticket's number.

Support Information

Working hours: Typically we work Monday to Friday, 9am to 7pm Cyprus timezone (EEST). Support is provided by the same developers writing the software, all of which live in Europe. You can still file tickets, but we cannot respond to them, outside of our working hours.

Support policy: We would like to kindly inform you that when using our support you have already agreed to the Support Policy which is part of our Terms of Service. Thank you for your understanding and for helping us help you!