403: caller does not have storage.objects.list access to the Google Cloud Storage bucket
Fixes GCS calls rejected for missing IAM permission even though authentication works. Use when list/get calls return 403 storage.objects.list. Not for DefaultCredentialsError (no credentials at all).
TL;DR: Your credentials are fine; the identity just lacks permission. In the GCP console, grant the service account (or your user) Storage Object Viewer on the bucket, or Storage Admin if it also needs to write, then retry.
403 GET https://storage.googleapis.com/storage/v1/b/[bucket]/o: caller does not have storage.objects.list access to the Google Cloud Storage bucket.Fix it
- Find which identity you authenticate as: gcloud auth list, or decode it from the code path. Expected: you know the service account email or user.
- In the console go to the bucket, Permissions, Grant access, and add the Storage Object Viewer role for that identity. Expected: the binding appears.
- Retry the list call. Expected: objects come back.
- If writes are needed too, use Storage Object Admin instead of stacking read roles.
When this applies
- The error is a 403 naming a specific storage.* permission.
- Auth itself succeeds (no DefaultCredentialsError).
When it doesn't
- The error is 401 or DefaultCredentialsError: fix credentials first.
- The error is 404 on the bucket: the bucket name or project is wrong.
Compatibility
- google-cloud-storage any version; IAM behavior is server-side.
Why it happens
GCS separates authentication (who you are) from authorization (what you may do). Default service accounts and new users get almost no storage permissions until someone grants them.
Edge cases
- Uniform bucket-level access ignores object ACLs; grant at the bucket IAM level.
- Permission changes can take a minute to propagate; retry before assuming it failed.
- Cross-project buckets need the grant in the bucket's project, not yours.