Google Cloud Storage permission denied

I have the same issue . For me the

Fatal: unable to open config file: service.Objects.Get: googleapi: Error 403: Caller does not have storage.objects.get access to the Google Cloud Storage object. Permission ‘storage.objects.get’ denied on resource (or it may not exist)., forbidden

Is there a repository at the following location?


I have the bucket and also the permission for SA is available but for some reason suddenly I am getting this error . When I check for date it shows UTC time . Any help here!!

@sander The error message is quite clearly indicating that the credentials you use do not have the permissions needed. You need to check the permissions on the Google side, and make sure that you have correctly configured the credentials on your restic side.

Hello @rawtaz

That is the problem here. My SA which is used in the pods is given with object.admin access so it should not be the case . And it was all working fine before 6 - 7 days . Suddenly it is not working .

Assuming that the restic binary you are running has not changed, the changes causing this problem are outside of restic, and you need to debug your use and configuration of the credentials, and/or your permissions on the Google side.

EDIT: I split this problem into its own topic, as it’s not the same error as the original topic that was replied to.

I doubt that !!! Because the credentials from GCP end was the same . Now in fact I had created new SA with admin access and also used the new creds. But still the same. Even after giving SA with object.admin if it is giving 403 I doubt it is from GCP end

@sander Please continue the discussion in this thread instead of the other one.

Did you change the restic binary? If not, it will do the exact same thing as it did previously. And that means that whatever changed is in how you use/provide the credentials, their contents, or the permissions on the Google side. I’m not sure what part of this is unclear or why you do not think that this makes sense.

If the restic binary did not change, it still does things exactly the same way as before. If you then started having a problem, it has to mean that something else changed. Figure out what, and you should be on track to find the cause of the problem.

1 Like

You can use the Policy Troubleshooter to verify whether the SA has access to the storage bucket in question.

1 Like

Found the solution that adding the env which is below
value: /config/gcs/credentials.json

Previously it was set to use env

    value: /config/gcs/credentials.json