Troubleshooting Storage Quota for API Service Accounts

When an automated script, application, or backup pipeline running under a Google Cloud Platform (GCP) service account abruptly fails with 403: storageQuotaExceeded or The user's Drive storage quota has been exceeded, the service account has attempted to upload data directly to its own virtual identity. By default, a service account has an effective Google Drive storage allocation of 0 bytes because it is not a licensed Google Workspace user.

Quick Answer

Service accounts cannot store files directly in their own identity because they do not have a licensed Workspace storage pool. To fix storage quota errors, configure the service account to write files directly into a Shared Drive using supportsAllDrives=true, or use Domain-Wide Delegation to impersonate a licensed Workspace user who owns available storage.

---

Why Service Accounts Fail with Storage Quota Errors

A service account is an identity created inside a Google Cloud project (for example, backup-bot@my-project.iam.gserviceaccount.com). Developers often treat service accounts like standard user accounts, writing scripts that call the Drive API files.create endpoint to upload database dumps, logs, or reports.

However, Google enforces strict boundaries between Google Cloud Platform and Google Workspace:

• No Native Workspace License: A service account does not occupy a seat in your Google Workspace directory. It has no pooled storage allotment and cannot purchase Google One space.
• The “Ghost” My Drive: While the Drive API technically permits a service account to generate file metadata, its internal personal storage quota is zero (or capped at a strict unmanaged threshold). Once the service account attempts to upload binary content, the API throws 403 storageQuotaExceeded.
• Inaccessible Web UI: You cannot log into drive.google.com as a service account to view its files, empty its trash, or monitor its quota usage visually.

---

Solution 1: Target an Organizational Shared Drive (Recommended)

The cleanest, most durable solution is to redirect the service account’s upload destination to a Google Workspace Shared Drive. Files stored in a Shared Drive belong to the drive itself, not to the uploading identity. Therefore, uploads draw against the organization’s overall pooled storage rather than the service account’s nonexistent personal quota.

1. Grant the Service Account Access

1. Copy the full service account email address (...@project.iam.gserviceaccount.com).
2. Open Google Drive in your web browser.
3. Open the target Shared Drive.
4. Click Manage members in the top right.
5. Add the service account email with Contributor (can add files) or Content Manager access.

2. Update Your API Upload Request Parameters

When uploading to a Shared Drive via the Google Drive API, your code must explicitly instruct Google to route the file into the Shared Drive container. If you omit these parameters, the API attempts to place the file in the service account’s root drive, triggering the quota error.

Ensure your API client payload includes:

• supportsAllDrives=true (or supportsTeamDrives=true on older SDKs).
• The Shared Drive folder ID specified inside the file metadata’s parents array.

Python Example:

file_metadata = {
    'name': 'daily_backup.tar.gz',
    'parents': ['0B1234567890SharedDriveFolderID']
}

media = MediaFileUpload('daily_backup.tar.gz', mimetype='application/gzip')

drive_service.files().create(
    body=file_metadata,
    media_body=media,
    supportsAllDrives=True,
    fields='id'
).execute()

If your service account receives permissions errors after updating your script, see How to Resolve “Service Account cannot access Drive”.

---

Solution 2: Implement Domain-Wide Delegation (Impersonation)

If your architecture requires files to be owned by a specific human employee rather than a Shared Drive, configure your service account with Domain-Wide Delegation of Authority.

This allows the service account to sign API requests using its own private key, while impersonating a licensed Workspace user:

1. When the script runs, it requests an OAuth2 token specifying user@yourdomain.com as the subject (sub).
2. The Drive API handles the upload as if that licensed employee uploaded it directly.
3. The uploaded bytes deduct from that licensed user’s personal/OU allocation or the organization’s pooled quota.

To set up and troubleshoot delegation credentials, refer to How to Resolve “Domain-Wide Delegation” Failures and How to Resolve “Service Account Impersonation” Errors.

---

Purging Orphaned Files Trapped in the Service Account

If a script has been uploading files to the service account’s root drive over several months, those items may now be blocking even metadata operations. Because the service account lacks a browser interface, you must purge these items programmatically:

1. List all files owned by the service account:
   Execute files.list with the query 'me' in owners and trashed = false.
2. Permanently delete the files:
   Loop through the returned file IDs and call files.delete(fileId=id) to bypass the 30-day trash bin and immediately free the service account’s metadata table.