Google Cloud存储桶自动构建后文件丢失“公开共享”权限求助

Hey there! I’ve run into this exact issue before when setting up static sites on Cloud Storage with auto-deployments from GitHub—super frustrating when your updated index.html suddenly becomes inaccessible. Let’s break down why this happens and how to fix it:

Why This Happens #

When your auto-build trigger updates existing files (like index.html), it’s essentially replacing the old object with a new one. By default, Cloud Storage sets new objects to private unless you explicitly configure permissions during upload or set a default access policy for the bucket. Since you mentioned your setup requires handling permissions at the individual file level, the key is to make sure every updated file gets the Share publicly (allUsers read access) permission automatically.

Solutions to Try #

1. Set a Default Bucket ACL (Simplest Fix)

This ensures every new or updated file inherits public read access automatically, so you don’t have to handle permissions per file every time:

• Go to your Cloud Storage bucket in the GCP Console
• Navigate to the Permissions tab
• Click Add principal, type allUsers in the field
• Select the Storage Object Viewer role from the dropdown
• Save the changes
• Alternatively, use the gcloud CLI command:

  gsutil defacl set public-read gs://your-bucket-name
  

  Note: Only do this if all content in your bucket is meant to be public—don’t use this for buckets with sensitive data.

2. Add Permission Steps to Your Build Script

If you prefer not to set a bucket-wide default ACL, update your auto-build workflow to set permissions after uploading files:

• If you’re using gsutil cp to upload your site files, add the -a public-read flag to apply permissions during upload:

  gsutil cp -r ./your-build-folder/* gs://your-bucket-name -a public-read
  

• If you’re uploading first and need to fix permissions afterward, run this command to grant read access to all users for every file in the bucket:

  gsutil acl ch -u allUsers:R gs://your-bucket-name/**
  

  Make sure your build service account has the Storage Admin or Storage Object Admin role to modify these permissions.

3. Verify Your Build Trigger Configuration

Double-check your GitHub trigger or Cloud Build setup to make sure there’s no step that’s overriding permissions accidentally. For example, if your script deletes old files before uploading new ones, the new files will use the bucket’s default permission (which is private unless you changed it). Adding the permission step right after upload will fix this.

Quick Test #

After applying one of these fixes, push a small change to your GitHub master branch and check the permissions of the updated file in Cloud Storage—you should see allUsers listed with read access, no need to manually set "Share publicly" anymore.

内容的提问来源于stack exchange，提问作者got2jam