How To Mount a Google Cloud Storage Bucket as a Drive on a Linux VM with Cloud Storage FUSE

Mounting a Cloud Storage bucket into a Linux VM file system is useful when you want familiar file operations (ls, cp, mv, application file reads/writes) without rewriting tools around object storage APIs.

This guide walks through installing Cloud Storage FUSE (gcsfuse), authenticating from a VM, mounting a bucket, and making the mount persistent across reboots.

Why Cloud Storage FUSE

Cloud Storage FUSE gives you a POSIX-like mount point backed by a Cloud Storage bucket. It is a practical fit for workloads that already expect file paths, such as ETL workers, model pipelines, and batch jobs.

Use it when you want:

• Existing Linux tools to work with bucket data from a mount path.
• Minimal code changes in scripts that already read and write local files.
• Optional boot-time mounting through /etc/fstab.

Prerequisites

• A Linux VM (for example, Compute Engine).
• A Cloud Storage bucket (example: my-bucket).
• IAM access to that bucket.
• sudo access on the VM.

Step 1: Install Cloud Storage FUSE

The Google Cloud docs support Ubuntu/Debian, CentOS/RHEL/Rocky Linux, and SUSE. Below is the Ubuntu/Debian path (most common on GCE).

sudo apt-get update
sudo apt-get install -y curl lsb-release

export GCSFUSE_REPO=gcsfuse-`lsb_release -c -s`
echo "deb [signed-by=/usr/share/keyrings/cloud.google.asc] https://packages.cloud.google.com/apt $GCSFUSE_REPO main" \
  | sudo tee /etc/apt/sources.list.d/gcsfuse.list

curl https://packages.cloud.google.com/apt/doc/apt-key.gpg \
  | sudo tee /usr/share/keyrings/cloud.google.asc

sudo apt-get update
sudo apt-get install gcsfuse

Verify installation:

gcsfuse --version

For RHEL-family and SUSE hosts, use yum or zypper repository setup from the official install page.

Step 2: Authenticate from the VM

Cloud Storage FUSE uses Application Default Credentials (ADC).

For local shell authentication:

gcloud init
gcloud auth application-default login

For Compute Engine VMs, attaching a service account with proper bucket permissions is usually cleaner for production. Cloud Storage FUSE can use that VM service account automatically.

Step 3: Mount the Bucket

Create a mount point and mount the bucket:

sudo mkdir -p /mnt/gcs
sudo gcsfuse my-bucket /mnt/gcs

Now verify:

ls -la /mnt/gcs

At this point, your bucket is accessible like a drive path on Linux.

Common Mount Variants

Mount read-only:

gcsfuse -o ro my-bucket /mnt/gcs

Mount only a subdirectory inside a bucket:

gcsfuse --only-dir a/b my-bucket /mnt/gcs

Mount with implicit directory support (useful when folder-like prefixes exist but directory objects do not):

gcsfuse --implicit-dirs my-bucket /mnt/gcs

Step 4: Persist the Mount Across Reboots

Cloud Storage FUSE installs a helper (/sbin/mount.gcsfuse) that allows persistent mounts via /etc/fstab.

Example fstab entry:

my-bucket /mnt/gcs gcsfuse rw,_netdev,allow_other,uid=1001,gid=1001

Important notes:

• Add _netdev (or x-systemd.requires=network-online.target) so mount waits for network readiness.
• In fstab mount flags, use underscores, not hyphens (for example, implicit_dirs).
• allow_other may require enabling user_allow_other in /etc/fuse.conf.

Test fstab mount safely before reboot:

sudo mount /mnt/gcs

Multi-VM Shared Storage Pattern

One practical advantage of this approach is that the same Cloud Storage bucket can be mounted on multiple Linux VMs at the same time. That gives each VM a consistent shared path (for example, /mnt/gcs) while data remains centralized in Cloud Storage.

This is useful for:

• Stateless worker fleets that read shared inputs and write outputs.
• Multi-VM batch pipelines where each stage runs on different machines.
• Short-lived autoscaled VMs that need immediate access to common data.

Important design note: Cloud Storage is object storage, not a POSIX block file system. Coordinate concurrent writers carefully and avoid assumptions about strict file-lock semantics across VMs.

Performance Note: gcsfuse vs Direct Bucket Utilities

gcsfuse optimizes for file-system compatibility and ease of integration, not raw transfer throughput in every case.

• Use gcsfuse when applications must access bucket data through normal file paths.
• Use direct object operations (gcloud storage cp, gsutil cp, or Storage APIs) for large sequential transfers, bulk sync jobs, and copy-heavy workflows where maximum throughput matters.

In many production systems, teams combine both: gcsfuse for application runtime file access, and direct bucket utilities for ingestion/export pipelines.

Unmount When Needed

fusermount -u /mnt/gcs

Conclusion

Cloud Storage FUSE is the fastest way to expose a Google Cloud Storage bucket as a Linux mount path on a VM. The production baseline is straightforward: install gcsfuse, authenticate with ADC (prefer VM service accounts), mount to a stable path, and persist through /etc/fstab with network-aware options.

Further Reading

• Cloud Storage FUSE performance tuning and caching options.
• Cloud Storage FUSE configuration file options for advanced behavior.
• Directory semantics and folder behavior in object storage-backed mounts.

If you found this helpful, consider following my profile and signing up for the newsletter. Have thoughts or questions? Share them in the comments below.

References

• https://docs.cloud.google.com/storage/docs/cloud-storage-fuse/install
• https://docs.cloud.google.com/storage/docs/cloud-storage-fuse/mount-bucket
• https://docs.cloud.google.com/storage/docs/cloud-storage-fuse/overview
• https://docs.cloud.google.com/storage/docs/cloud-storage-fuse/troubleshooting