# harababurel/gcsf: Mount Google Drive as a FUSE Filesystem

> GCSF is a Rust FUSE filesystem that mounts a Google Drive account as a local directory. It is a small utility with a real OAuth setup cost, and it is the wrong tool for offline or multi-writer workflows.

**harababurel/gcsf** — a FUSE file system based on Google Drive

- Repository: https://github.com/harababurel/gcsf
- Stars: 2,383 · Forks: 98
- Language: Rust
- License: MIT
- Published: 2026-09-28 · Updated: 2026-09-28 · Language: en
- Canonical page: https://hysenlabs.com/projects/harababurel-gcsf

## What GCSF Solves for People Who Live in a Shell

Google Drive has a web interface and a desktop sync client. Neither gives you a path you can hand to grep, rsync, or a build script. GCSF fills that gap: it is a virtual filesystem that mounts a Drive account locally, so the contents appear under a mount point and can be used like a regular disk partition. The README describes it exactly that way.

The audience is narrow and specific. You are on Linux, macOS or FreeBSD, you already use FUSE-based mounts, and you want Drive files addressable by path rather than through an API client library. The project is written in Rust and published on crates.io, so the install path runs through cargo rather than a distribution package manager, with an AUR package for Arch users. Windows is not supported, and the README points to issue #19 for that.

One naming note that confuses people searching for the project: GCSF stands for "Google Conduce Sistem de Fișiere", Romanian for "Google Drive Filesystem". The README says the acronym stayed as GCSF because GDFS was already taken by another project. If you arrived expecting 3D model tooling, you are looking at the wrong repository.

## How the Mount, the Tree and the Credentials Fit Together

The architecture visible in the repository is a FUSE layer over the Google Drive API. The Cargo.toml lists fuser with the libfuse feature for the kernel-facing side, google-drive3 pinned at exactly 7.0.0 for the API client, and yup-oauth2 for the OAuth flow. That pin is deliberate: a comment in the manifest explains that google-drive3 7.0.0 disables default features on yup-oauth2, which drops InstalledFlowAuthenticator::builder, so the project depends on yup-oauth2 directly to switch the feature back on.

In-memory state is handled with id_tree and lru_time_cache. That combination suggests the filesystem builds a tree of Drive node IDs and caches recently used entries rather than mirroring the whole account on disk. The README's mount output supports that reading, since it prints "Creating and populating file system..." before "File system created." and then mounts. Population happens at mount time, not lazily per lookup.

Credentials and configuration live outside the mount. GCSF writes a config file to $XDG_CONFIG_HOME/gcsf/gcsf.toml, usually $HOME/.config/gcsf/gcsf.toml, and stores session credentials in the same directory. Sessions are named, which is why one machine can hold several accounts at once and why the mount command takes a -s flag.

The dependency list also shows a fully async stack: tokio with the full feature set, futures, hyper-util, reqwest with rustls rather than OpenSSL at the HTTP layer, plus libssl-dev in the Linux build requirements. That mix is worth knowing before you try to build in a minimal container.

## Installing gcsf and Mounting a First Session

GCSF requires the stable Rust toolchain, installed via rustup. The README suggests running rustup update stable first if Rust is already present. On Ubuntu or Debian, the build dependencies are fuse3, libfuse-dev, libssl-dev and pkg-config:

```bash
sudo apt-get install -y fuse3 libfuse-dev libssl-dev pkg-config
```

On Fedora the equivalent set is gcc, fuse3-devel and pkg-config, and on macOS the README uses brew for pkg-config and the osxfuse cask. With those in place, the binary comes from crates.io:

```bash
cargo install gcsf
```

That places the gcsf binary in $HOME/.cargo/bin, which must be on your PATH. A release binary is also offered for download if you would rather not compile.

Before the first login you need your own Google Cloud project, because GCSF has no shared client credentials. The README's steps are: create a project at console.developers.google.com, add the Google Drive API, configure an OAuth consent screen (external unless the project is internal to a GSuite), and create an OAuth2 credential. For a headless server, do not use WEB as the token type; use the urn:* URI, and set authorize_using_code=True in the config so that completing the flow in another browser yields a code you paste back. If you do choose WEB, the README notes you must add http://localhost:8081 to the accepted domains.

With client_id, client_secret and project_id written into the config, logging in and mounting look like this:

```bash
gcsf login some_session_name
gcsf mount /mnt/gcsf -s some_session_name
```

The login command prints a Google accounts URL to open in a browser and, on success, reports that credentials were saved under $HOME/.config/gcsf/some_session_name. The mount command prints progress lines and ends with "Mounted to /mnt/gcsf". At that point the Drive tree is readable at the mount point, and gcsf list shows every saved session.

## The Token Expiry Problem and Why Testing Mode Bites You

The most concrete operational limitation in the README is not about files at all. It is about OAuth consent screen status. If your Google Cloud project stays in Testing mode, access tokens expire more frequently, and GCSF prompts for re-authentication. That is tolerable for an interactive session and unpleasant for a service.

The README treats this as important enough to warrant its own section for long-running use. The fix is to publish the app to Production mode from the OAuth consent screen's Audience page, then re-authenticate, because the existing session is invalidated:

```bash
gcsf logout your_session_name
gcsf login your_session_name
```

The README also states that publishing to Production does not require Google verification for personal use, and that verification matters only when distributing the app to many external users. There is a verify subcommand for checking a session's state, which prints "Authentication is valid." when the credentials still work.

This is the design trade-off of the whole project. GCSF runs against your own GCP project rather than a hosted service, which means no third party holds your Drive tokens, and also means you own the consent screen configuration, the token lifetime, and any verification questions that follow. If you want a mount you can set up once and forget, the consent screen status is the first thing to check, not the last.

## Where GCSF Is the Wrong Tool

GCSF is not a sync client, and treating it as one invites trouble. The README documents no offline mode, no conflict resolution, and no local staging area. Files are addressed through the Drive API, so a mount is only as available as your network and Google's API. If you need a working copy on a disconnected laptop, the desktop sync client is the right choice and GCSF is not.

Windows is unsupported, stated plainly in the README with a pointer to issue #19. If your team is on Windows, stop here. The build requirements also assume a real toolchain: libfuse-dev, libssl-dev, pkg-config, and for FreeBSD the sysutils/fusefs-libs port. A slim container image without those will not build the crate, and the async dependency stack means the build pulls a substantial tree.

Multi-writer use deserves scepticism. Nothing in the README describes how concurrent changes from another device or the web interface are reflected in a mounted tree, and the mount-time population step suggests the tree is built when you mount rather than continuously reconciled. For a single user doing shell work on their own files, that is fine. For a shared folder edited by several people, verify the behaviour yourself before trusting it with anything important.

Finally, the README's troubleshooting section is thin. It begins a "Could not mount to $mountpoi" entry and the excerpt ends there, so the failure modes around mounting are not documented at the level you would want when a mount refuses to come up.

## How GCSF Differs from OCamlFUSE-Style Mounts

The obvious comparison for anyone searching this space is OCamlfuse, the OCaml FUSE binding used by projects like google-drive-ocamlfuse to put Drive on a Linux mount point. Both approaches end in the same place: a directory where Drive files appear, backed by FUSE and the Drive API. The difference is in the implementation and in what you inherit from it.

GCSF is a self-contained Rust binary installed through cargo, with its own CLI for sessions (login, list, mount, logout, verify) and its own TOML config. OCamlfuse is a binding library; the Drive filesystem built on it is a separate program with its own configuration conventions. If you already run an OCaml-based Drive mount and it works, there is no migration argument in this repository. If you prefer a single cargo-installed binary with named sessions and a documented OAuth setup against your own GCP project, GCSF is the more direct fit.

The Rust choice has a practical consequence too. GCSF pins google-drive3 at exactly 7.0.0 and works around a feature-flag gap in that release by depending on yup-oauth2 directly. That kind of pinning is normal for API-client crates, but it means an upgrade of the Drive client is a deliberate change, not something that floats in on a minor version. The release history shows 0.3.9 in September 2026, 0.3.8 in July 2026 and 0.3.7 in December 2025, so the cadence is irregular rather than continuous. Check the tag you install against the changelog rather than assuming a steady stream of fixes.

## Licence, Packaging and What Upgrades Cost You

GCSF is MIT licensed, and the Cargo.toml declares the same. For most users that is the end of the question: permissive, no copyleft obligation on your own code, and no restriction on running it internally. Note that the licence covers GCSF itself, not the crates it pulls in; the dependency tree includes google-drive3, yup-oauth2, tokio and others under their own terms. If you redistribute a bundled binary, review those separately. That is not legal advice, and the LICENSE file in the repository is the authoritative text.

The repository carries a gcsf.service unit file and a dist-workspace.toml, which suggests running GCSF as a systemd service is an intended deployment. That path is exactly where the Production mode advice matters, because a service that periodically demands re-authentication is not much of a service. The README's own framing supports this: it recommends Production mode for system services and extended runs.

Upgrade cost is low but not zero. The binary installs and updates through cargo install gcsf, and the config format is a single TOML file, so a version bump rarely touches your setup. The risk sits in the pinned Drive client and the OAuth flow. A change to either can invalidate a session, and the README's own Production mode instructions already require logout and login after a consent screen change. Budget for one re-authentication whenever you touch the Google Cloud side, and read the release notes for the version you are moving to before you overwrite a working binary.

## Conclusion

GCSF suits Linux, macOS or FreeBSD users who want their Drive tree available to ordinary shell tools and who are willing to run a one-time OAuth setup against their own Google Cloud project. Skip it if you need Windows support, offline access, or concurrent editing from several machines, since the README documents none of those. Before relying on it, mount a session and confirm that writes land in Drive as expected, and check which authentication mode your setup needs, including authorize_using_code for headless servers.

## FAQ

### What is harababurel/gcsf?

It is a virtual filesystem written in Rust that mounts a Google Drive account locally through FUSE, so Drive contents can be used like a regular disk partition. The README describes it as a Google Drive filesystem, and the name is a Romanian acronym kept because GDFS was already taken.

### How do I install gcsf on Ubuntu or Debian?

Install the build dependencies first with sudo apt-get install -y fuse3 libfuse-dev libssl-dev pkg-config, then run cargo install gcsf. The README also lists Fedora, SUSE, macOS, FreeBSD and Arch AUR instructions, and states that Windows is not supported.

### Why does gcsf keep asking me to authenticate again?

The README attributes frequent re-authentication to a Google Cloud project that is still in Testing mode, where access tokens expire more often. Publishing the app to Production mode from the OAuth consent screen's Audience page resolves it, but you must run gcsf logout and gcsf login afterwards.

## Sources

- [harababurel/gcsf on GitHub](https://github.com/harababurel/gcsf)
- [Issues](https://github.com/harababurel/gcsf/issues)
- [License: MIT](https://github.com/harababurel/gcsf/blob/master/LICENSE)
- [README](https://github.com/harababurel/gcsf/blob/master/README.md)
- [Releases](https://github.com/harababurel/gcsf/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/harababurel-gcsf