The Problem: [storage.objects.get] Permission Errors

When working with Google Cloud Document AI Workbench, one of the most frustrating errors you can encounter happens during the document import phase. You configure your dataset, point it to a Google Cloud Storage (GCS) bucket containing your training PDFs, click import, and get hit with a permission rejection:

{
  "status": {
    "code": 7,
    "message": "Does not have permissions [storage.objects.get] in the bucket"
  }
}

Naturally, your first instinct is to find the Document AI service account and grant it the Storage Object Viewer (or Admin) role. The default Document AI service account typically looks like this:

service-{PROJECT_NUMBER}@gcp-sa-prod-dai-core.iam.gserviceaccount.com

You run gsutil iam ch or use the GCP Console IAM page, grant the permissions, wait for propagation, and try again. Yet, the error persists. Why?

The Root Cause: Project Viewer Context

The root cause is that Document AI Workbench does not authenticate as the service account directly when importing documents via the Cloud Console interface. Instead, it operates under the project's default viewer role context: projectViewer:{YOUR_PROJECT_ID}.

Because the Workbench runs in this context, granting roles to the core Document AI service account does not solve the import authorization checks on the bucket.

The Solution

To resolve this, you must grant the Storage Legacy Object Reader role to the project viewer principal at the project level, rather than the bucket level.

Via gcloud CLI:

gcloud projects add-iam-policy-binding {YOUR_PROJECT_ID} \
  --member="projectViewer:{YOUR_PROJECT_ID}" \
  --role="roles/storage.legacyObjectReader"

Via Google Cloud Console UI:

• Go to IAM & Admin → IAM.
• Find the principal: projectViewer:{YOUR_PROJECT_ID}.
• Click the Edit (pencil) icon next to it.
• Click Add Another Role.
• Search for and select: Storage Legacy Object Reader.
• Click Save.

Key Takeaway

Cloud service integrations often inherit credentials from project-level roles rather than their specific service accounts. Understanding which principal actually performs the actions is key to resolving deceptively simple permission blocks.