Back to blog

How to Mount Google Drive on Your Linux Server with rclone — Local Cache and Custom API Keys

·Anders da Silva Rytter Hansen

Learn to mount Google Drive on your Linux server with rclone. Use custom API keys and local cache for maximum speed and stability.

Introduction

Got a Google One subscription with 2 TB of storage but think it's absurd to pay for extra VPS storage on top? So did I. Luckily, there's an elegant solution: rclone.

With rclone, you can mount your Google Drive as a regular folder on your Linux server — and with the right configuration, it actually feels fast, not sluggish like you might expect.

Why Custom API Keys Are Essential

Google imposes rate limits on public API keys. If you use rclone's built-in keys, you'll experience:

  • Slow transfers
  • Choppy streaming
  • General frustration

The solution: Create your own OAuth2 credentials in the Google Cloud Console. It takes 10 minutes and makes a world of difference.

My Practical Setup

I use rclone with the following priorities:

  • Stability: The folder just needs to work, even after reboots
  • Speed: Local cache layer for frequently accessed data
  • Security: Encrypted remote (I use googleencrypted:)

Here's my mount command:

rclone mount googleencrypted: /mnt/google/encrypted \
    --vfs-cache-mode full \
    --vfs-cache-max-size 2G \
    --vfs-write-back 5m \
    --dir-cache-time 1000h \
    --attr-timeout 1000h \
    --no-checksum \
    --no-modtime \
    --poll-interval 15s \
    --async-read=true \
    --allow-other \
    --verbose \
    --vfs-cache-max-age 7200h \
    --metadata \
    --file-perms 0775 \
    --dir-perms 0775 \
    --umask 0002 \
    --vfs-fast-fingerprint

What Do the Flags Mean?

FlagMeaning
--vfs-cache-mode fullAggressive caching for both reads and writes
--vfs-cache-max-size 2GMax 2 GB local cache (adjust for your available hard drive space)
--vfs-write-back 5mDelay before uploading to cloud — good for temporary files
--dir-cache-time 1000hCache directory structure for 1000 hours (performance boost)
--poll-interval 15sCheck for external changes every 15 seconds
--no-checksum --no-modtimeAvoid unnecessary API calls (trust the cache)
--vfs-fast-fingerprintFaster file comparison

The Result

With this setup:

  • 📁 Your Google Drive appears as /mnt/google/encrypted on the server
  • 🚀 Frequently accessed files load from local cache (almost instant)
  • 💾 You leverage your existing Google One subscription
  • 🔒 Data is transparently encrypted by rclone (if you use a crypt remote)

Real-world example: I use this exact setup to store all repositories and data from my Forgejo instance — a self-hosted Git solution running on the same server.

Getting Started

  1. Install rclone: sudo apt install rclone (or download from rclone.org)
  2. Configure with rclone config — set up Google Drive + optional crypt layer
  3. Create your own API keys in Google Cloud Console
  4. Run the mount command above (optionally as a systemd service)

Known Limitations (that I'm still working on)

There are two challenges I haven't fully solved yet:

  1. Unix permissions in the crypt layer: Currently, I have to set all files to have the same permissions (--file-perms 0775 --dir-perms 0775). I haven't found a way to make the crypt layer preserve individual Unix file permissions. This means all files in the mount get the same permissions.

  2. Latency on git push: When I push a new commit to a Git repository located on the mount, it takes some time to finish. I suspect this is because there are many small files that need to be changed (especially in .git/objects/), and the rclone mount takes time to process each file operation. It's not a showstopper, but something I'd like to optimize.

Conclusion

If you're already paying for Google One, there's no reason to pay for VPS storage too. With rclone, custom API keys, and intelligent caching, you get the best of both worlds: cheap cloud storage with local server speed.

Questions about the setup? Drop me a message — happy to help!

#rclone#google-drive#mount#cloud-storage#linux#self-hosting#cache