Working fine yesterday, but today I am getting 403 on all the requests sent to the S3 gateway.
Just to check, I created new S3 Credentials with all permissions for all buckets in my account in region EU1, but I still get “403 Forbidden” for all the request, whether to list buckets (listBuckets), check if a bucket exists (headBucket) or list objects in a bucket (listObjects).
The gateway seems to respond correctly to health checks:
curl -v https://gateway.storjshare.io/-/health
- Trying 22.214.171.124:443…
- Connected to gateway.storjshare.io (126.96.36.199) port 443
- schannel: disabled automatic use of client certificate
- ALPN: curl offers http/1.1
- ALPN: server accepted http/1.1
- using HTTP/1.1
GET /-/health HTTP/1.1
< HTTP/1.1 200 OK
< Content-Security-Policy: block-all-mixed-content
< Vary: Origin
< X-Amz-Request-Id: 17A76DD5B07A0FD2
< X-Xss-Protection: 1; mode=block
< Date: Fri, 05 Jan 2024 10:49:08 GMT
< Content-Length: 0
Is it possible to get more info one why the GW is rejecting all my requests?
PS: I get the same result when I try aws s3 ls via the AWS CLI endpoint.
@Yaluba a couple questions to help me better understand what the issue could be:
- can you confirm if you are able to view objects from the satellite web UI?
- could you privately share your EU1 account email address with me? Either via a DM on this platform, or in an email to email@example.com - this will allow me to check our database to see if there is anything there which could indicate a problem
Another thing you could try is generate an access grant in the satellite UI, and try to use this with uplink, e.g. with the following steps:
uplink access import jan5accesstest <access from UI>
uplink access use jan5accesstest
uplink ls sj://<bucketname>
If inconvenient, do not worry about testing with Uplink. Letting me know about the object browser and providing me with your email should be sufficient to start with.
thanks Moby, just sent a private email.
On WEB UI, I have no proble to acces the buckets. I will try with uplink cli later today.
Is it possible that you have a not valid or limited credentials in the
Many S3-compatible tools uses them by default.
You may override them with environment variables: Environment variables to configure the AWS CLI - AWS Command Line Interface
It solved it looking in that direction.
The creds in “~/.aws/credentials” were old and overrode the ones passed programmatically. For some reason that I could not figure out, this started happening just after I installed aws s3 cli following the Storj instructions. This created a “~/.aws/config” and the creds in different config files probably messed with each other.
Finally, it worked again when I removed all files with credentials in “~/.aws/”. Then it started using only the ones that I pass programmatically.
If you installed an AWS CLI it starting to behave like this… almost all s3-compatible tools starting to look into
~/.aws/credentials instead of what is provided programmatically.
There are only two options:
- use environment variables to override settings in
By the way, I’m not sure that p.2 is enough for everyone used tool…