Troubleshooting GCSFuse Permission Issues for Non-Root Users on Google Compute Engine


2 views

When mounting Google Cloud Storage buckets using gcsfuse on Compute Engine instances, I encountered a persistent permission problem where non-root users could read but not write files, despite proper configuration. Here's my deep dive into the solution.

# My testing environment configuration:
OS: CentOS 7
GCE Instance: n1-standard-1
Service Account: default compute engine SA
GCS Bucket: test_bucket_00
Mount Point: /data/cloud/tb-00
  • The bucket mounted successfully as root with allow_other
  • File permissions showed -rw-r--r-- for root only
  • Chmod 777 had no effect on mounted directory
  • Non-root users could read but not modify files

After extensive testing, I found these steps reliably solve the permission issues:

# 1. Create proper fuse group and add users
sudo groupadd fuse
sudo usermod -a -G fuse testuser

# 2. Configure gcsfuse with proper uid/gid mapping
sudo mkdir -p /data/cloud/tb-00
sudo chown testuser:fuse /data/cloud/tb-00
gcsfuse --uid $(id -u testuser) --gid $(id -g testuser) \
    --implicit-dirs test_bucket_00 /data/cloud/tb-00

# 3. Permanent solution via fstab
echo "test_bucket_00 /data/cloud/tb-00 gcsfuse rw,allow_other,uid=$(id -u testuser),gid=$(id -g fuse)" | sudo tee -a /etc/fstab

The critical elements that made this work:

  • Explicit UID/GID mapping in mount options
  • Proper group permissions for the fuse group
  • Using --implicit-dirs for better directory handling
  • Service account must have Storage Admin role at minimum
[testuser@vm-00 ~]$ touch /data/cloud/tb-00/testfile
[testuser@vm-00 ~]$ ls -la /data/cloud/tb-00/
total 0
drwxr-xr-x 1 testuser fuse  0 Jan 21 00:25 .
drwxr-xr-x 3 root     root 20 Jan 21 00:25 ..
-rw-r--r-- 1 testuser fuse 20 Jan 21 00:25 animal.txt
-rw-r--r-- 1 testuser fuse  0 Jan 21 00:30 testfile

For system-wide access without per-user configurations, consider:

# Systemd mount unit example
[Unit]
Description=GCS Fuse Mount
After=network.target

[Service]
User=root
Environment="GOOGLE_APPLICATION_CREDENTIALS=/path/to/service-account.json"
ExecStart=/usr/bin/gcsfuse -o allow_other --file-mode=664 --dir-mode=775 \
    test_bucket_00 /data/cloud/tb-00
ExecStop=/bin/fusermount -u /data/cloud/tb-00
Restart=always
Type=simple

[Install]
WantedBy=multi-user.target

When working with gcsfuse on Google Compute Engine instances, a common pain point emerges: non-root users facing write permission issues despite proper bucket permissions. Here's what's happening under the hood:

# Sample error you might encounter
$ touch /mnt/gcsbucket/newfile.txt
touch: cannot touch '/mnt/gcsbucket/newfile.txt': Permission denied

The root cause typically stems from three intertwined factors:

  • FUSE's default permission handling
  • GCS bucket IAM configurations
  • Local filesystem permissions

Solution 1: Proper Mount Options

Modify your mount command or /etc/fstab entry to include these critical parameters:

gcsfuse \
    --uid $(id -u youruser) \
    --gid $(id -g youruser) \
    --implicit-dirs \
    --file-mode=777 \
    --dir-mode=777 \
    your-bucket-name /mnt/yourmountpoint

Solution 2: Service Account Configuration

Ensure your Compute Engine service account has these IAM roles on the bucket:

  • roles/storage.objectAdmin (for read-write access)
  • roles/storage.legacyBucketOwner (for legacy permission support)

For production systems, consider this more robust configuration:

# /etc/fstab entry
your-bucket /mnt/gcsbucket gcsfuse rw,x-systemd.requires=network-online.target,allow_other,uid=1000,gid=1000,file_mode=664,dir_mode=775,implicit_dirs,key_file=/path/to/service-account.json

Then create a systemd automount unit:

# /etc/systemd/system/mnt-gcsbucket.automount
[Unit]
Description=Automount GCS Bucket
After=network-online.target

[Automount]
Where=/mnt/gcsbucket
TimeoutIdleSec=300

[Install]
WantedBy=multi-user.target

When permissions still don't work:

  1. Verify with gcloud auth list which account is active
  2. Check bucket IAM: gsutil iam get gs://your-bucket
  3. Confirm fuse group membership: groups youruser
  4. Test with debug mode: gcsfuse --foreground --debug_fuse --debug_gcs --debug_http your-bucket /mnt/test

If gcsfuse proves problematic:

  • Consider s3fs with Google's S3 interoperability API
  • For high-performance needs, explore GCS's native client library
  • Cloud Storage FUSE CSI driver for Kubernetes workloads

Remember that gcsfuse operations eventually become consistent, though immediately after writes you might see temporary permission artifacts.