# How to Mount Google Drive with Rclone: VFS Cache and Setup Guide

Mounting Google Drive with Rclone translates local POSIX filesystem calls into remote API requests. Without full VFS caching, recursive scans from AI coding agents trigger API throttling and freeze local processes. Setting up dedicated client credentials, configuring full VFS cache buffering, and managing systemd services provides reliable local access before connecting workspaces to AI agents via the Model Context Protocol.


Source: https://fast.io/resources/rclone-mount-google-drive/
Author: [Tom Langridge](https://fast.io/authors/tom-langridge/)
Last reviewed: 2026-10-08

## Why Direct Google Drive FUSE Mounts Freeze During Agent Workflows

Rclone mount Google Drive uses FUSE to expose remote Google Drive folders as a local POSIX filesystem, translating local read and write system calls into Google Drive API requests. While this abstraction allows operating systems to treat remote cloud storage like an attached hard drive, cloud object storage lacks the native latency and concurrency guarantees of physical block devices.

POSIX file tools expect filesystem operations to complete in microseconds. When tools like `git status`, language server daemons, file indexing services, or autonomous coding agents inspect a repository, they issue hundreds of rapid `stat`, `readdir`, and file open calls. On local drives, this inspection finishes almost instantaneously. Over a direct network mount, every single metadata request translates into an HTTP roundtrip to Google servers, introducing latency of fifty to one hundred fifty milliseconds per operation.

The failure worsens under API rate limits. Google Drive enforces a default quota of 10 transactions per second for API requests, according to the official [Rclone Google Drive provider documentation](https://rclone.org/drive/). A recursive scan that checks a small repository with a few hundred files can easily fire thousands of metadata requests in seconds. Once this threshold is exceeded, Google servers respond with HTTP 403 (User Rate Limit Exceeded) or HTTP 429 (Too Many Requests) errors, forcing clients to back off.

When Rclone encounters these rate limits without proper buffering, it blocks the calling process while waiting for backoff timers to expire. Because the Linux kernel FUSE driver handles filesystem calls synchronously, the requesting process enters an uninterruptible sleep state. Git commands hang indefinitely, file trees in integrated development environments (IDEs) stop refreshing, and AI coding agents time out. Resolving this requires dedicated API credentials and local disk cache buffering through Rclone Virtual File System (VFS). For teams evaluating remote storage architectures, review [Google Drive alternatives](/alternatives/google-drive/) designed for developer workflows.

## How to Configure Rclone with a Dedicated Google Drive Client ID

Configuring Rclone to communicate with Google Drive requires authenticating with Google Cloud. While Rclone includes internal client credentials for quick testing, those default credentials are shared among thousands of users worldwide. Using the shared ID causes immediate rate limiting because other users draw down the global transaction quota. Production mounts must use a custom OAuth client ID.

Creating a dedicated client ID isolates your API quotas to your own Google Cloud project. Follow these steps to register your application in the Google Cloud Console:

1. Open the Google Cloud Console and create a new project named `rclone-storage`.
2. Go to **APIs & Services > Library**, search for **Google Drive API**, and select **Enable**.
3. Go to **APIs & Services > OAuth consent screen**. Select **External** (or **Internal** if using a Google Workspace organization), provide an application name, and enter your developer contact email.
4. Under **Scopes**, you can leave the defaults or add the `../auth/drive` scope. In development or testing status, add your Google account email under **Test Users**.
5. Open **APIs & Services > Credentials**, select **Create Credentials**, and choose **OAuth client ID**.
6. Set the application type to **Desktop app**, name the client `rclone-desktop`, and click **Create**.
7. Copy the generated **Client ID** and **Client Secret**.

### Configuring the Remote via CLI

With your credentials in hand, launch the interactive setup in your terminal:

```bash
rclone config
```

Select `n` to create a new remote, and name it `gdrive`. When prompted for the storage type, enter `drive`. Paste your custom client ID and client secret when prompted:

```text
Option client_id.
OAuth Client Id.
Enter a value. Press Enter to leave empty.
client_id> your-client-id.apps.googleusercontent.com

Option client_secret.
OAuth Client Secret.
Enter a value. Press Enter to leave empty.
client_secret> your-client-secret
```

Choose scope `1` for full drive access, or scope `2` for access restricted to files created by Rclone. For `root_folder_id` and `service_account_file`, press Enter to accept the empty defaults. When asked to edit advanced configuration, select `n`.

When prompted for auto config (`Use auto config?`), choose `y` if you are running on a local desktop machine with a browser. Rclone will launch a local web server, open your default browser, and prompt you to grant access. If you are configuring a headless remote server, choose `n` and use `rclone authorize` on your local workstation to generate the verification token.

Verify the configuration by listing top-level folders:

```bash
rclone lsd gdrive:
```

If the connection succeeds, Rclone displays the root directories of your remote storage.

## How Rclone VFS Cache Modes Handle Remote Files

The Rclone Virtual File System (VFS) layer translates POSIX filesystem calls into remote storage operations. Tuning an rclone vfs cache Google Drive deployment requires matching cache parameters to the concurrency patterns of your local applications. Because cloud storage APIs do not natively support file locking, random writes, or sparse file updates, Rclone provides four distinct caching modes that determine how files are buffered locally.

Understanding the behavior of each mode is essential for selecting the correct profile for developer tools and coding agents:

* **--vfs-cache-mode off:** Rclone streams data directly to and from the remote without storing files on local disk. Reads can seek, but writes must be strictly sequential. Applications cannot open files for simultaneous reading and writing, and in-place file modifications fail. This mode breaks Git, SQLite, and language server compilers.
* **--vfs-cache-mode minimal:** Files opened for both reading and writing are buffered to disk first. Sequential writes to new files still stream directly. While this mode uses less local disk space, it fails when applications attempt random write access or append operations on existing files without an explicit read-write flag.
* **--vfs-cache-mode writes:** Files opened for writing or modification are downloaded completely to local disk before opening, and modifications upload asynchronously once the file closes. Read operations still stream directly from the API. While suitable for basic document storage, coding agents reading source files repeatedly will continually hit API rate limits.
* **--vfs-cache-mode full:** Rclone full VFS cache mode buffers all reads and writes to and from local disk. In this mode, files exist in the cache as sparse files, downloading only the chunks requested by running applications.

According to the official [Rclone mount command reference](https://rclone.org/commands/rclone_mount/), in this mode all reads and writes are buffered to and from disk. This behavior enables random reads, in-place writes, and local caching across recurring operations.

```
+-----------------------------------------------------------------------+
|                         Operating System                              |
|         (Developer IDEs, Git CLI, AI Coding Agents, Shell)            |
+-----------------------------------^-----------------------------------+
                                    | POSIX System Calls
                                    v
+-----------------------------------------------------------------------+
|                       Rclone Mount (FUSE Layer)                       |
|                                                                       |
|  +---------------------------+     +-------------------------------+  |
|  |     Directory Cache       |     |        Full VFS Cache         |  |
|  |  (--dir-cache-time 72h)   |     |    (--vfs-cache-mode full)    |  |
|  | Tracks folder hierarchies |     | Buffers sparse reads & writes |  |
|  +-------------^-------------+     +---------------^---------------+  |
+----------------|-----------------------------------|------------------+
                 | Polling (15s)                     | Chunked I/O
                 v                                   v
+-----------------------------------------------------------------------+
|                       Google Drive REST API                           |
|      (Default quota: 10 transactions/second per client ID)            |
+-----------------------------------------------------------------------+
```

When an AI agent runs `grep`, `git diff`, or a static analysis pass, `--vfs-cache-mode full` serves already-downloaded chunks straight from local disk. The agent avoids triggering upstream API calls, bypassing Google rate limits entirely after the initial fetch.

### Memory Buffers and Chunk Size Optimization

Alongside the caching mode, two complementary flag groups govern data movement:

1. **Memory buffers (`--buffer-size 32M`):** Controls the in-memory read-ahead buffer for active file descriptors. Setting this parameter to `32M` provides smooth sequential reads without consuming excessive system memory across multiple open file descriptors.
2. **Chunk scaling (`--vfs-read-chunk-size 32M` and `--vfs-read-chunk-size-limit 2G`):** Rclone begins downloading files using chunk sizes starting at `32M`. As an application continues sequential reading, Rclone doubles the chunk size progressively up to `2G`, reducing total HTTP roundtrips.
3. **Cache retention (`--vfs-cache-max-size 50G` and `--vfs-cache-max-age 24h`):** Configuring `--vfs-cache-max-size 50G` and `--vfs-cache-max-age 24h` caps total local disk usage and evicts unaccessed files after one day using a least-recently-used policy.

## Production Mount Flags and Systemd Service Setup

Deploying Rclone in production requires combining VFS caching, directory caching, and network pacing flags into a reliable service. A bare `rclone mount gdrive: /mnt/gdrive` command will fail under any sustained developer or agent workload.

Here is the recommended production command for mounting Google Drive with full VFS caching:

```bash
rclone mount gdrive: /mnt/gdrive \
  --vfs-cache-mode full \
  --vfs-cache-max-size 50G \
  --vfs-cache-max-age 24h \
  --vfs-read-chunk-size 32M \
  --vfs-read-chunk-size-limit 2G \
  --dir-cache-time 72h \
  --poll-interval 15s \
  --buffer-size 32M \
  --attr-timeout 1s \
  --drive-pacer-min-sleep 10ms \
  --drive-pacer-burst 100 \
  --umask 022 \
  --allow-other
```

### Directory Caching and Change Polling

Directory traversal is often more expensive than file data transfers. The `--dir-cache-time 72h` flag instructs Rclone to remember directory hierarchies in memory for three days, eliminating repeated `files.list` API queries when scanning folders.

To prevent directory listings from becoming stale when files change on the remote, Rclone uses `--poll-interval 15s`. Google Drive supports change notifications, allowing Rclone to query the Drive changes endpoint every fifteen seconds and invalidate only modified directory branches. This mechanism keeps directory listings accurate with minimal API overhead.

### Managing the Mount with Systemd on Linux

To ensure the mount starts automatically on boot and restarts after network drops, configure a systemd service unit.

Create the service definition file at `/etc/systemd/system/rclone-gdrive.service` using a shell heredoc:

```bash
sudo bash -c 'cat << "EOF" > /etc/systemd/system/rclone-gdrive.service
[${SECTION_UNIT:=Unit}]
Description=Rclone Google Drive Mount Service
After=network-online.target
Wants=network-online.target

[${SECTION_SERVICE:=Service}]
Type=notify
ExecStart=/usr/bin/rclone mount gdrive: /mnt/gdrive \
  --config=/etc/rclone/rclone.conf \
  --vfs-cache-mode full \
  --vfs-cache-max-size 50G \
  --vfs-cache-max-age 24h \
  --vfs-read-chunk-size 32M \
  --vfs-read-chunk-size-limit 2G \
  --dir-cache-time 72h \
  --poll-interval 15s \
  --buffer-size 32M \
  --attr-timeout 1s \
  --drive-pacer-min-sleep 10ms \
  --drive-pacer-burst 100 \
  --umask 022 \
  --allow-other
ExecStop=/bin/fusermount -u -z /mnt/gdrive
Restart=on-failure
RestartSec=10

[${SECTION_INSTALL:=Install}]
WantedBy=default.target
EOF'
```

Enable and start the service:

```bash
sudo systemctl daemon-reload
sudo systemctl enable --now rclone-gdrive.service
```

Check the service status and logs using `systemctl status rclone-gdrive.service` and `journalctl -u rclone-gdrive.service -f`. The `fusermount -u -z` directive ensures that if the service stops, the mount point unmounts cleanly without leaving orphaned FUSE locks.

### Mounting Google Drive on Windows with WinFsp

Configuring an rclone mount Google Drive Windows setup requires a third-party FUSE driver to expose cloud remotes as local drive letters. The standard driver is WinFsp (Windows File System Proxy).

1. Download and install WinFsp from its official release repository.
2. Open PowerShell and verify that Rclone can access your configured remote using `rclone lsd gdrive:`.
3. Mount the remote to an available drive letter such as `G:`:

```powershell
rclone mount gdrive: G: `
  --vfs-cache-mode full `
  --vfs-cache-max-size 50G `
  --vfs-cache-max-age 24h `
  --vfs-read-chunk-size 32M `
  --vfs-read-chunk-size-limit 2G `
  --dir-cache-time 72h `
  --poll-interval 15s `
  --buffer-size 32M
```

To run this mount persistently in the background on Windows, use NSSM (Non-Sucking Service Manager) to wrap the Rclone executable as a standard Windows service, or configure a scheduled task that executes at system startup.

## How to Connect Cloud Workspaces to AI Agents with Fast.io

While a tuned Rclone FUSE mount provides functional local access for individual developers, local filesystem mounts struggle in collaborative and agentic environments. When multiple AI coding agents, background workers, and human teammates need to read and write shared project assets, local mounts exhibit distinct operational bottlenecks:

* **Host coupling:** An Rclone mount exists solely on the local workstation or virtual machine where the daemon runs. Cloud sandboxes, CI/CD runners, and remote IDEs cannot access the mount without complex network sharing.
* **Payload overhead:** AI agents frequently need to query, filter, or retrieve specific facts from large files. FUSE forces the agent to download entire files through the filesystem layer, consuming local disk cache and network bandwidth.
* **Coordination collisions:** When multiple agents write to the same mounted directory simultaneously, local caches can fall out of sync before background uploads finish, risking file collisions.

### Intelligent Cloud Workspaces

Organizations can avoid these filesystem bottlenecks by pairing existing cloud storage with [Fast.io workspaces](/product/workspaces/). Fast.io serves as the collaborative coordination layer where agents and people interact through structured endpoints rather than raw filesystem mounts.

Teams maintain their current storage footprint in Google Drive. Cloud Sync currently ships for Google Drive, Dropbox, Box, and OneDrive on a schedule or on demand. When files are imported into a Fast.io workspace, Intelligence Mode auto-indexes content for hybrid search across full-text keywords, semantic vectors, and document metadata.

Instead of downloading multi-gigabyte archives or scanning raw folder trees over FUSE, AI agents connect to [Fast.io storage for agents](/storage-for-agents/) using the remote Model Context Protocol (MCP) server over Streamable HTTP:

* **Coding agents:** IDE tools such as Claude Code, Cursor, Cline, Devin Desktop, and Roo Code connect directly at `https://mcp.fast.io/mcp/code`. Agents use consolidated tools like `search` and `execute` to locate relevant snippets across indexed files without pulling whole directories. Setup details are documented at the [Fast.io MCP documentation](https://mcp.fast.io/docs).
* **General AI assistants:** Claude apps, OpenClaw, and Hermes Agent connect at `https://mcp.fast.io/mcp/tools` with OAuth sign-in.
* **ChatGPT and Codex:** Users can install the Fastio plugin from the ChatGPT plugin directory or connect via custom server at `https://mcp.fast.io/mcp/operations`.

In published connector benchmarks comparing remote agent retrieval, Fastio was measured the fastest and the lowest cost of the providers tested (detailed benchmark data is published in the [Fast.io benchmarks report](https://fast.io/benchmarks/)).

### Structured Extraction and Workspace Governance

Beyond search and retrieval, [Fast.io AI features](/product/ai/) provide governance capabilities tailored for multi-agent teams:

* **Metadata Views:** For structured document processing, [Metadata Views](/product/document-data-extraction/) extract typed schemas from PDFs, spreadsheets, and scanned records into filterable spreadsheets without manual OCR templates.
* **Per-file version history:** Every agent edit generates an immutable version record, allowing developers to audit agent outputs and roll back changes if needed.
* **Advisory file locks:** Agents acquire leases through MCP actions (`lock-acquire` and `lock-release`) to signal active edits to other members.
* **Collaborative Notes:** Real-time markdown notes allow people and agents to coordinate project checklists and instructions in one shared view.
* **Activity events feed:** Long-poll and WebSocket feeds notify external services when files change, enabling reactive agent execution.

Fast.io operates on organizational subscriptions. Monthly plans start with a 14-day free trial, which requires a credit card. Review available tiers on the [Fast.io pricing](/pricing/) page:

| Plan | Monthly Billing | Included Storage | Team Seats | Monthly AI Credits |
|---|---|---|---|---|
| Starter | $9.99/mo | 250 GB | 3 seats | 100,000 |
| Business | $49.99/mo | 5 TB | 10 seats | 600,000 |
| Enterprise | $199.99/mo | 25 TB | 30 seats | 3,000,000 |

Setting up an intelligent workspace bridges existing Google Drive assets directly into production AI workflows without the maintenance overhead of local FUSE mounts.

## Frequently asked questions

### How do I mount Google Drive locally using Rclone?

To mount Google Drive locally, install Rclone, run rclone config to configure a new remote using a custom Google Cloud OAuth client ID, and create a local mount directory. Then run rclone mount gdrive: /path/to/mount with full VFS caching flags to expose the remote as a local filesystem.

### What are the best VFS cache settings for Google Drive in Rclone?

The recommended settings combine `--vfs-cache-mode full` with `--vfs-cache-max-size 50G`, `--vfs-cache-max-age 24h`, `--vfs-read-chunk-size 32M`, and `--vfs-read-chunk-size-limit 2G`. Pair these with `--dir-cache-time 72h` and `--poll-interval 15s` to minimize Google Drive API requests and avoid rate limits.

### Why does Rclone mount Google Drive freeze during file reads?

Freezes occur when applications perform recursive directory scans or random file reads that exceed Google Drive's default quota of 10 transactions per second. Without full VFS caching, the kernel FUSE driver blocks system calls while waiting for HTTP responses or exponential backoff retries, causing processes to hang.

### How do I mount Google Drive on Windows with Rclone?

On Windows, install the WinFsp driver first. Open PowerShell and run rclone mount with full VFS cache mode to an unassigned drive letter. You can automate the mount on startup by configuring a Windows service using NSSM or Windows Task Scheduler.

### Can multiple AI coding agents write to the same Rclone mount concurrently?

Direct concurrent writes to an Rclone mount can cause synchronization delays because files are buffered locally before uploading. For multi-agent collaboration, using an intelligent workspace platform with per-file version history and advisory file locks prevents race conditions.

### How can AI agents search Google Drive files without triggering API rate limits?

Instead of scanning raw files over FUSE, import files into a Fast.io workspace where Intelligence Mode automatically creates a hybrid semantic and keyword index. Agents can then connect via the Model Context Protocol using endpoints detailed at /storage-for-agents/ to search files directly without downloading entire directories.

## Sources

- [Rclone: Google Drive Documentation](https://rclone.org/drive/): Google Drive enforces a default quota of 10 transactions per second for API requests.
- [Rclone: rclone mount Documentation](https://rclone.org/commands/rclone_mount/): Rclone full VFS cache mode buffers all reads and writes to and from local disk.

## About Fast.io

Fast.io provides shared workspaces where people and AI agents work on the same files, with built-in semantic search and citation-backed chat over what they hold. Agents reach it through a remote MCP server, a REST API at https://api.fast.io/current/, and a command line client published on npm as @vividengine/fastio-cli. MCP setup is at https://mcp.fast.io/docs: Claude and most MCP clients connect to https://mcp.fast.io/mcp/tools, ChatGPT to https://mcp.fast.io/mcp/operations, and coding agents to https://mcp.fast.io/mcp/code.