gsutil version 4.21
awscli installed.
gsutil ls gs://bucket-id/ works!
aws s3 ls s3://bucket-id/ works!
gsutil ls s3://bucket-id/ does not work.
RROR 0906 15:19:51.842520 utils.py] Unable to read instance data, giving up
Failure: No handler was ready to authenticate. 4 handlers were checked. ['HmacAuthV1Handler', 'DevshellAuth', 'OAuth2Auth', 'OAuth2ServiceAccountAuth'] Check your credentials.
thanks for the responses.
Hm. I'm curious as to whether this occurs in version 4.19 as well (we tweaked some of the auth code between 4.19 and 4.20). Would you mind grabbing version 4.19, running the same ls command, and seeing if gsutil ls
still fails against your s3 bucket?
Short of that, I'd also make sure that your ~/.boto
file has the same S3 credentials (aws_access_key_id
and aws_secret_access_key
under the [Credentials]
section) that the aws cli uses, which the docs say should be under ~/.aws/credentials
.
I've been unable to reproduce this when operating on AWS buckets via gsutil, with and without the presence of an ~/.aws/credentials
file. We made several auth-related changes after v4.20, so chances are this has been fixed (or there's just something about your local environment that I'm missing in order to repro) - if you're still able to reproduce this, let me know and I'll reopen this issue.
Im getting the same error for the ls operation although the s3 bucket has public read and write access. Hope I'm not missing anything here. The gsutil was executed inside the google cloud shell.
Command - gsutil ls s3://rnd-grocery
Error Message - ERROR 1228 14:00:22.190043 utils.py] Unable to read instance data, giving up
Failure: No handler was ready to authenticate. 4 handlers were checked. ['HmacAuthV1Handler', 'DevshellAuth', 'OAuth2Auth', 'OAuth2ServiceAccountAuth'] Check your credentials.
Hi figured it out, I did not add the aws access and secret key in the ~/.boto file. After adding them it worked fine.
Can someone please see this https://github.com/GoogleCloudPlatform/gsutil/issues/1098, I am having the same issue but with AWS ECS Fargate and nothing seems to be fixing the issue.
Most helpful comment
Short of that, I'd also make sure that your
~/.boto
file has the same S3 credentials (aws_access_key_id
andaws_secret_access_key
under the[Credentials]
section) that the aws cli uses, which the docs say should be under~/.aws/credentials
.