Linode S3 - SignatureDoesNotMatch
Hey,
I'm having a couple of issues with Linode S3 - more specifically, it appears something has changed and now I am no longer able to perform HeadBucket or ListBuckets requests correctly.
For the sake of clarity: I'm using a Rust backend application and use the official AWS S3 SDK (latest version V1).
The problem is reproducible though in other languages (e.g. Python).
What I want to do:
- check if a bucket exists on application start by listing buckets
- previously I used the head bucket request
Both no longer work and result in 403 responses - the head bucket now returns 403 without any additional info.
ListBuckets returns SignatureDoesNotMatch.
I correctly set the endpoint to
my-region.linodeobjects.com
Access and secret key are correct.
The same code works perfectly fine with local S3 (MinIO), with official AWS S3 and even with other vendors such as Wasabi S3.
I've therefore come to the conclusion that something is non-standard in the way Linode provides S3 compatibility.
SignatureDoesNotMatch is very odd on a GET request and the client is correctly configured.
Interestingly, other requests do not fail:
- I can presumably create a bucket with access and secret key (at least it confirms the creation of a bucket with the same name)
- I can set the bucket policy as well
- afterwards, uploads etc. work perfectly fine
Any help would be appreciated.
Thanks
1 Reply
CassandraD
Linode Staff
I've tried to recreate this and haven't been able to. List buckets works for me and a few of my teammates. However, head_bucket didn't work for me, but I did not get a similar error and I think that was my own configuration/permissions issue. That said, I did find something interesting in another post on our Community Site that may be helpful.
It looks like users have reported in the past that our system sometimes shows that "SignatureDoesNotMatch" error when it's not super specific and that there's an "'Etag' in the response header which contains the md5 result."
Since that sounds like something we can improve on our end, I've requested we work on providing more detailed error output by submitting a report in our internal tracking system.
If you'd like to share your exact configurations and the portion of your script relevant to these errors, we can try to recreate them more specifically to your use case.
I wanted to also suggest trying in a different region to see if that changes anything. I started troubleshooting this last week so I'm not 100% certain, but I believe I tested this in us-lax-1 and us-east-1.