prossel
Forum Replies Created
-
The same error occurs with DreamHost DreamObjects storage on their new cluster.
ERROR: S3 Service API: Unsupported header 'x-amz-checksum-crc32' received for this API callUsing BackWPup 5.2.1
Here is their answer:
Unfortunately this isn’t a matter of a configuration missing from the new US-East 5 cluster, but a design choice. Upload checksums like the kind provided by that header are no longer supported and will need to be disabled in order to continue uploading.
Looks like either DreamHost or BackWPup need to change something to fix the issue. They don’t seem to be willing.
Will you ?
Hello @duongcuong96,
I don’t see permissions options in DreaHost panel.
And I tested with UpdraftPlus which has no problem deleting old archives.
Regards
PierreHello @duongcuong96
I don’t see any trash bin. When I delete a file with Cyberduck, I don’t see it anywhere else.
I have a WP test site with BackWPup and a job configured to save on S3 / Dreamhost, file deletion set to 2.
I can run the job 3 times in a row or every day, no matter what the files keep accumulating and not is deleted.
I also have other WP sites in production with daily backups on S3. No file has ever been deleted automatically and it’s been configured since several months. I need to delete them manually.
Could a BackWPup developer check that the file deletion actually works on S3 / Dreamhost ?
I tried using troubleshooting mode with only BackWPup activated.
Same result.
The only way to have the job run without error is to configure the “Folder in bucket” parameter with a string starting with the bucket name. Then I can add any path after the slash and it will be created in the bucket.
This is maybe a problem with Dream host service only.
If we can exchange a private message, I can create a bucket and send you the keys to make your own tests.
Sorry, I have been busy with other tasks, and since I have a workaround, this is not high priority for me.
Did you test with DreamHost ?
I can create a bucket for you to test if you want.
Hello @duongcuong96,
Exactly. There are unexpected errors in both first tests.
Test 1: When “folder in bucket” is empty
Why is there an error ?
Test 2: When “folder in bucket” has some random name
Why is there an error ? Even if the name matches an existing folder ?
Test 3: When “folder in bucket” has the name of the bucket
OK, that’s fine and my conclusion is that the “folder in bucket” parameter must start it’s path with the bucket name. Since the bucket name is known by selecting it somewhere else in the interface, to me, as a developer, there is no sense expecting a user to repeat the bucket name at the start of a path, if it is mandatory and cannot be changed. This is redundant to selecting the bucket name. But maybe I’m missing something and there is a reason. It just took me some time to figure it out as it’s not intuitive.