I keep running into this annoying problem with Google Drive API and service accounts. I’m getting a 403 error that says service accounts don’t have storage quota even though I have plenty of space left.
Here’s what happened. I was using a service account with editor permissions to upload files through the API. It worked perfectly for a while. Then suddenly I started getting this 403 error about storage quota. I made a new service account and gave it owner permissions which fixed the issue temporarily. But now the same error is back even though my drive only has about 50KB of data.
Here’s my upload code:
# Search for existing files with same name
search_query = f"'{folder_id}' in parents and name = '{file_name}' and trashed = false"
result = self.__drive_service.files().list(
q=search_query,
corpora="user",
fields="files(id, name, createdTime, modifiedTime)"
).execute()
# Remove old files if they exist
for existing_file in result.get('files', []):
old_file_id = existing_file.get('id')
old_file_name = existing_file.get('name')
self.__drive_service.files().update(removeParents=folder_id, fileId=old_file_id).execute()
print(f"Removed existing file: {file_path}/{old_file_name} (ID: {old_file_id})")
# Upload new file
file_meta = { 'name': file_name, 'parents': [folder_id] }
media_upload = MediaFileUpload(file_path, resumable=True)
try:
new_file = self.__drive_service.files().create(
body=file_meta,
media_body=media_upload,
fields='id',
supportsAllDrives=True
).execute()
print(f"Successfully uploaded {file_path}*{file_name}, ID: {new_file.get('id')}")
except Exception as error:
handle_error(error, "Upload failed")
print("Error details above")
The exact error I’m getting is:
<HttpError 403 when requesting None returned "Service Accounts do not have storage quota. Leverage shared drives or use OAuth delegation instead.". Details: "[{'message': 'Service Accounts do not have storage quota. Leverage shared drives or use OAuth delegation instead.', 'domain': 'usageLimits', 'reason': 'storageQuotaExceeded'}]">
I’m really confused because I have tons of storage space available. Has anyone else run into this issue? Any suggestions would be great.
The Problem: You’re encountering a “Service Accounts do not have storage quota” error when uploading files to Google Drive using a service account, even though you have ample storage space. This issue arises because Google’s handling of service account storage has changed. Service accounts no longer have their own dedicated storage quota; your files are essentially in limbo without proper quota allocation. This is causing the 403 error.
Understanding the “Why” (The Root Cause):
Google has updated how service accounts interact with storage. Previously, they implicitly inherited storage quota from the project owner. This is no longer the case. Your service account uploads are failing because they lack the necessary storage allocation. The error message is misleading, suggesting a lack of overall storage when the real problem is a lack of allocated storage for the service account itself. Using OAuth delegation or shared drives circumvents this by associating the uploaded files with a user or a shared drive that does have a quota.
Step-by-Step Guide:
Implement User Impersonation via Domain-Wide Delegation (Recommended): This approach leverages the existing storage quota of a Google Workspace user account while maintaining the benefits of service account automation.
Enable Domain-Wide Delegation: In your Google Workspace admin console, navigate to the Security settings and enable Domain-wide Delegation. This allows your service account to act on behalf of a specified user.
Select a User: Choose a Google Workspace user account with sufficient storage quota. This user will effectively “own” the files uploaded by the service account.
Configure Service Account Credentials: When creating or updating your service account credentials, you’ll need to specify the email address of the chosen user using the subject parameter. This instructs the service account to impersonate that user.
Update Your Code: Modify your application code to use the updated service account credentials. The authentication process will now use the delegated user’s credentials. Ensure your service account has the necessary permissions on the target Google Drive folders.
Example Code Snippet (Conceptual): The exact implementation will depend on your chosen Google client library. This illustrates the key concept of specifying the delegated user:
# Assuming you're using the Google Client Library for Python
credentials = service_account.Credentials.from_service_account_file(
'path/to/your/service_account_key.json',
scopes=['https://www.googleapis.com/auth/drive'],
subject='[email protected]' # This is crucial - specify the delegated user here!
)
Alternative: Utilize Google Shared Drives: If domain-wide delegation is not feasible, use Google Shared Drives. Shared drives have their own storage quota separate from individual user quotas. This means your service account’s uploads will be linked to the Shared Drive’s quota, resolving the storage issue.
Create a Shared Drive: In your Google Workspace admin console, create a new Shared Drive.
Grant Access: Ensure your service account has appropriate permissions (at least “Contributor”) to this Shared Drive.
Update folder_id: Modify your code to use the folder_id of a folder within the Shared Drive. Your current folder_id likely points to a personal Google Drive folder. The supportsAllDrives=True parameter in your code should already allow access to Shared Drives, but double-checking the correct folder_id is crucial.
Common Pitfalls & What to Check Next:
OAuth 2.0 Configuration (If using OAuth): If you’re implementing OAuth 2.0 (as an alternative or if you are abandoning Service Accounts altogether), carefully review the Google Cloud Console’s OAuth consent screen and ensure that all redirect URIs are correctly configured and match exactly what your application is using.
Shared Drive Permissions: If using a Shared Drive, verify that your service account has the necessary permissions at the organization level and not just at the folder level.
folder_id Verification: Before uploading, explicitly check the properties of the folder_id in your Google Drive to verify it belongs to a Shared Drive and isn’t associated with a personal Google Drive account. You can use the Google Drive API to retrieve folder details and check the drive’s type.
Incorrect Subject Email (Domain-Wide Delegation): Double-check that the email address specified in the subject parameter of your service account credentials is correct and belongs to a Google Workspace user with sufficient storage quota and the necessary Drive folder permissions.
Still running into issues? Share your (sanitized) config files, the exact command you ran, and any other relevant details. The community is here to help!
This is driving me nuts too! Same error started last month outta nowhere. Fixed it by impersonating a real user through domain delegation instead of direct service account auth. Set up delegation in workspace admin console, then your service account acts as an actual user with storage quota. Takes some setup but uses real user storage instead of the non-existent service account quota.
The Problem: You’re encountering a “Service Accounts do not have storage quota” error when uploading files to Google Drive using a service account, even though you have ample storage space. This issue arises because the way Google handles service account storage has changed. Service accounts no longer have their own dedicated storage quota; instead, your files are essentially in limbo without proper quota allocation. This is causing the 403 error.
Understanding the “Why” (The Root Cause):
Google has updated how service accounts interact with storage. Previously, they implicitly inherited storage quota from the project owner. This is no longer the case. Your service account uploads are failing because they lack the necessary storage allocation. The error message is misleading, suggesting a lack of overall storage, when the real problem is a lack of allocated storage for the service account itself. Using OAuth delegation or shared drives circumvents this by associating the uploaded files with a user or a shared drive that does have a quota.
Step-by-Step Guide:
Automate with a User Account (Recommended): The most efficient solution is to bypass the limitations of service accounts entirely and leverage the storage quota of a regular user account. This involves restructuring your application to use OAuth 2.0 for authentication instead of service account credentials. This approach provides a clean and robust solution while adhering to Google’s updated service account policies. You will need to obtain OAuth 2.0 credentials for a user account and modify your Python code to use these credentials instead of the service account key file. This means you will handle authorization differently in your script. While you’ll lose some of the automatic authorization benefits of service accounts, you gain the simplicity and reliability of directly using a user’s existing quota.
Alternative: Utilize Google Shared Drives: If you absolutely must continue using service accounts, the alternative solution is to use Google Shared Drives. Shared drives have their own storage quota separate from individual user quotas. This means your service account’s uploads will be linked to the Shared Drive’s quota, resolving the storage issue. To implement this, you need to:
Create a Shared Drive: In your Google Workspace admin console, create a new Shared Drive.
Grant Access: Ensure your service account has appropriate permissions (at least “Contributor”) to this Shared Drive.
Update folder_id: Modify your code to use the folder_id of a folder within the Shared Drive. Your current folder_id likely points to a personal Google Drive folder. The supportsAllDrives=True parameter in your code should already allow access to Shared Drives, but double-checking the correct folder_id is crucial.
Common Pitfalls & What to Check Next:
OAuth 2.0 Configuration: If using OAuth 2.0, carefully review the Google Cloud Console’s OAuth consent screen and ensure that all redirect URIs are correctly configured and match exactly what your application is using.
Shared Drive Permissions: If using a Shared Drive, verify that your service account has the necessary permissions at the organization level and not just at the folder level.
folder_id Verification: Before uploading, explicitly check the properties of the folder_id in your Google Drive to verify it belongs to a Shared Drive and isn’t associated with a personal Google Drive account. You can use the Google Drive API to retrieve folder details and check the drive’s type.
Duplicate File Removal: Your code attempts to remove duplicate files. While efficient, ensuring it works correctly across all scenarios is vital. A failure here, unrelated to the quota issue, could lead to additional errors.
Still running into issues? Share your (sanitized) config files, the exact command you ran, and any other relevant details. The community is here to help!
Yeah, Google changed their API recently - that’s why it worked before and broke now. They updated how service accounts handle storage and now require shared drives or OAuth delegation. I’ve dealt with this exact issue. The fastest fix? Switch to OAuth 2.0 with a regular user account instead of the service account. You can keep most of your code but swap out the service account credentials for OAuth flow credentials. Files will use the authenticated user’s quota instead of hitting the non-existent service account storage. If you’re stuck using service accounts, you’ll need to create a shared drive and update your folder_id references to point there. Shared drives work great for organizations but you’ll need a Google Workspace account.
Hit this same headache two months ago during a client migration. Google changed their policy - service accounts don’t inherit storage quota from project owners anymore. Your files basically become orphaned without proper quota backing.
Here’s what fixed it for me: you’ve got supportsAllDrives=True already, but make sure your target folder actually lives in a shared drive, not personal drive space. The error screams that your folder_id is still pointing to personal storage even though you think you’re using shared drives.
Query the drive details first to double-check your folder_id is actually in a shared drive location. Personal drive folders will throw this quota error no matter how much space you have. Also check that your service account has shared drive access at the org level, not just folder permissions.
It seems you’ve encountered a common limitation with service accounts. They don’t have individual storage quotas, so the 403 error indicates that your files are not associated with a user’s storage. When I faced a similar issue, migrating to a Google Shared Drive resolved the problem effectively. Shared Drives operate independently of user quotas, allowing for more flexible file management. Alternatively, if the setup allows for it, domain-wide delegation could be an option, but it tends to complicate things due to admin access requirements. For straightforward scenarios, leveraging a Shared Drive is typically the best path forward.
Understanding the “Why” (The Root Cause):
Step-by-Step Guide:
Common Pitfalls & What to Check Next:
Still running into issues? Share your (sanitized) config files, the exact command you ran, and any other relevant details. The community is here to help!