google-drive-ocamlfuse: Mount Google Drive as a Linux Filesystem

What google-drive-ocamlfuse actually solves

Google Drive has no first-party Linux client. The web interface works, but scripts, editors and build tools expect a path. google-drive-ocamlfuse fills that gap by presenting Drive as a mounted directory through FUSE, so `ls`, `cp` and `grep` operate on it like any other folder. The README describes the project as a FUSE filesystem for Google Drive written in OCaml, and the repository's topics confirm the same framing: filesystem, fuse, google-drive, ocaml.

The intended user is someone on Linux who already lives in a terminal. The feature list points at that audience: full read/write access to ordinary files and folders, read-only access to Google Docs, Sheets and Slides exported to configurable formats, multiple account support, access to a `.Trash` directory, Unix permissions and ownership, and symbolic links. Team Drive support and service account support are documented on the wiki rather than in the README body, which tells you the project expects you to read further than the front page before deploying it.

It is not a sync client. Nothing is mirrored to local disk for offline use, and the README does not describe any offline mode. The mount is a view over the API, and every operation that is not served from cache goes to Google.

How the mount, cache and authorization fit together

The architecture visible in the README has three parts. A FUSE layer handles kernel filesystem calls. A cache holds metadata and file content. An HTTP client talks to the Google Drive API, with `curl.log` recording every request and `gdfuse.log` recording FUSE operations and cache management.

The cache is the part that shapes day-to-day behaviour. The README states that cached metadata remains valid for 60 seconds by default and that this is configurable. After it expires, the next normal resource operation checks the server for changes. The practical consequence is stated plainly: a change made server side will not appear immediately in the mounted filesystem. If you edit a document in the browser and then list the directory, you may see the old state for up to a minute.

Authorization is OAuth 2.0 with a client you create yourself. You activate the Google Drive API, create an OAuth client ID, choose Desktop as the application type, and receive a client ID and client secret. Those are passed on the command line the first time, which creates `~/.gdfuse/default` with a `config` file and opens a browser to complete authorization. Because the credentials belong to your own Google Cloud project, the trust boundary is your project rather than a shared third-party service. That is worth noting when the question of whether the tool is safe comes up.

Multiple accounts are separated by label. Each label gets its own directory under `~/.gdfuse`, holding configuration, application state and file cache. The README states that no file is shared among different accounts.

Installing google-drive-ocamlfuse on Ubuntu from the PPA

The README gives .deb packages for Ubuntu through a PPA. The stable channel is added and installed like this:

sudo add-apt-repository ppa:alessandro-strada/ppa
sudo apt-get update
sudo apt-get install google-drive-ocamlfuse

After this, `google-drive-ocamlfuse` is on your PATH. The README points to the wiki for other distributions and installation options, and the repository ships a `flake.nix` and an opam file, so a source build is possible if you have the toolchain. The build requirements listed are OCaml 4.08.0 or later, dune 2.0.0 or later, fuse3 3.10.0 or later, gapi-ocaml 0.4.9 or later, sqlite3-ocaml 1.6.1 or later, tiny_httpd 0.10 or later, otoml 1.0.1 or later, and ounit 2.0.0 or later. From source, the commands are `dune build @install` followed by `dune install`.

If you want the beta channel instead, the README lists a second PPA:

sudo add-apt-repository ppa:alessandro-strada/google-drive-ocamlfuse-beta
sudo apt-get update
sudo apt-get install google-drive-ocamlfuse

The default branch of the repository is `beta`, so the beta PPA tracks the branch where development happens. That is a choice to make deliberately rather than by accident.

First real use: authorize, mount, unmount

Before mounting anything you need an OAuth client. Create one in the Google Cloud console with application type Desktop, then pass the credentials. The README gives this form:

google-drive-ocamlfuse -id xxxxxxxxxx.apps.googleusercontent.com -secret XXX-YYY-ZZZ

This creates `~/.gdfuse/default` and its `config` file, and starts a browser to obtain authorization. Because the configuration exists before the first mount, you can edit it first. That matters if you want to mount read-only, which the README suggests as a precaution while the application is still under testing.

Create the mount point and mount:

mkdir ~/GoogleDrive
google-drive-ocamlfuse ~/GoogleDrive &

The trailing `&` runs it in the background. Since version 0.8.0 the process is kept in the foreground by default, which the README flags as a breaking change, so the `&` is no longer optional if you want your shell back. For a second account, add a label:

google-drive-ocamlfuse -label work ~/GoogleDrive &

To unmount, the README gives `fusermount3 -u ~/GoogleDrive`, noting that older distributions still providing the previous helper name should use `fusermount -u ~/GoogleDrive` instead. When something misbehaves, `google-drive-ocamlfuse -debug mountpoint` turns on debug and verbose logging, and `google-drive-ocamlfuse -cc` clears the cache.

The cache delay and the read-only question

The clearest limitation is the metadata cache. A 60 second default staleness window means the mount is not a live view of Drive. Tools that watch directories for changes will see them late. Two people editing the same folder will not see each other's work in step. The README does not claim otherwise, and it does not document any push or notification mechanism that would shorten the window.

The second limitation is maturity, and the README says so itself: the application is still under testing, and there are probably bugs to discover and fix. That is the project's own wording, not an outside assessment. The suggested mitigation is to mount read-only by editing the configuration so that no write attempt reaches the server. The README also notes that `rm` trashes the file rather than deleting it, so a mistaken removal should be recoverable from `.Trash`.

Where it is the wrong tool: if you need your files available without a network connection, this is not the project. If you need a mount that reflects server-side edits within seconds, the cache default works against you. And if your distribution is not covered by the PPA and you do not want to build OCaml dependencies, the setup cost is real. The related searches include people hitting "Unable to locate package google drive ocamlfuse", which is what happens when the PPA has not been added or does not cover the release.

One more thing the README leaves open: it does not document rollback beyond the trash behaviour. There is no described snapshot or versioning layer inside the mount.

How it differs from rclone mount

The obvious comparison is rclone, which also exposes Google Drive over FUSE on Linux. The difference is what each is built around. rclone is a transfer and sync engine that happens to offer a mount; its primary job is moving data between storage backends, with Drive as one of many. google-drive-ocamlfuse is a filesystem first. It exists to make Drive look like a local directory, and its features reflect that: Unix permissions and ownership, symbolic links, a `.Trash` directory, read-only export of Docs, Sheets and Slides into configurable formats, and per-label account separation under `~/.gdfuse`.

That difference shows up in configuration. rclone is configured through remotes and its own config file. google-drive-ocamlfuse uses a TOML `config` file inside `~/.gdfuse/<label>`, and since version 0.8.0 that TOML format replaced the earlier one, which the README flags as a breaking change. If you are upgrading from an older install, that migration is on you.

The Google Docs, Sheets and Slides export is the feature that is hardest to replicate elsewhere. Those file types are not ordinary files, and the read-only export path is a deliberate design decision rather than a side effect. If your work involves pulling document contents into a shell pipeline, that is the reason to pick this project over a general transfer tool.

Maintenance, licence and upgrade cost

The repository is not archived, and the last push was on 2026-08-23. The most recent release listed is v0.9.1 on 2026-07-18, following v0.9.0 on 2026-06-17 and v0.8.2 on 2026-04-06. That is a steady release cadence across the visible window.

The licence is MIT. In practical terms that permits commercial and private use, modification and redistribution provided the copyright notice and permission notice are included. This is not legal advice; check the LICENSE file in the repository for the exact terms before you rely on it in a product.

Upgrade cost is concentrated in two breaking changes the README calls out explicitly. Since version 0.8.0 the process stays in the foreground, so any script or systemd unit that assumed it daemonized itself needs the `&` or an equivalent. Since version 0.8.0 the configuration file format is TOML, so pre-0.8 configs need conversion. Both are one-time costs, but they are the kind that surface as a failed mount rather than a clear error. The repository also ships a `Makefile` with `make install`, `make uninstall`, `make test` and an `e2e` target that builds `test/e2e/e2eSuite.exe`, so there is an end-to-end suite to run against your own setup if you build from source.

Editorial conclusion

Adopt google-drive-ocamlfuse if you work on Linux and want Google Drive reachable through ordinary shell tools, especially for read-only exports of Docs, Sheets and Slides. Do not adopt it if you need a cross-platform sync client or a filesystem that reflects server-side changes instantly. Before committing, verify that the PPA covers your distribution, decide whether to mount read-only, and confirm the cached metadata timeout in your config.

Frequently asked questions

Official sources

1. astrada/google-drive-ocamlfuse on GitHub
2. License: MIT
3. Project website
4. README
5. Releases