Google Drive on Linux: A Fast rclone Mount (and Why Your Thumbnails Are Missing)

I have never managed to get Google Drive working decently on Linux. There is no official desktop client. The sync tools I tried over the years were either flaky, abandoned, or wanted to download my entire Drive onto a laptop SSD that did not have room for it.

What I actually wanted was simple: my Drive showing up as a normal folder, fast to browse, plus a place to push some offsite backups. This is the setup that finally works for me, on Ubuntu with XFCE. It includes one genuinely non-obvious problem — missing image thumbnails on the mount — that took me a while to understand, so I am writing it down before I forget it.

Before anyone says it: yes, there are other ways. GNOME has Online Accounts that can bolt on Google Drive in a couple of clicks, there are sync clients like Insync, and plenty of people are perfectly happy with one of those. I am not claiming this is the way to do it. In a sense I reinvented the wheel here — and honestly, who cares. This is the wheel that fits my machine: it is fast, I understand every piece of it, and it does exactly what I want. In 2026 it is still worth building something yourself just to try a different approach and learn how the parts actually fit together. That is half the fun.

Mounting Google Drive with rclone

The right tool is rclone. It speaks the Google Drive API and can expose any remote as a FUSE filesystem. You do not need root — a user-local binary is enough.

After installing rclone, authorize it against your Google account. This opens a browser for the OAuth consent and stores a refresh token locally:

rclone authorize "drive"

You will see a "Google hasn't verified this app" screen — that is normal for rclone's public credentials. The token never leaves your machine. Paste the resulting token into a remote called gdrive.

Now, instead of mounting by hand every time, run the mount as a systemd user service so the folder is always there and survives reboots. Drop this into ~/.config/systemd/user/rclone-gdrive.service:

[Unit]
Description=rclone mount Google Drive
After=network-online.target
Wants=network-online.target

[Service]
Type=notify
ExecStartPre=/bin/mkdir -p %h/GoogleDrive
ExecStart=%h/.local/bin/rclone mount gdrive: %h/GoogleDrive \
  --vfs-cache-mode full \
  --dir-cache-time 1000h \
  --poll-interval 15s \
  --rc --rc-addr 127.0.0.1:5572 --rc-no-auth
ExecStop=/bin/fusermount3 -u %h/GoogleDrive
Restart=on-failure

[Install]
WantedBy=default.target

Enable it with systemctl --user enable --now rclone-gdrive.service and your whole Drive is now at ~/GoogleDrive.

Making it actually fast

A naive rclone mount is slow to browse, and it is worth understanding why: every time you open a folder, rclone makes a round trip to the Google Drive API. Each call is a second or two. Click into three folders and you have waited five seconds for nothing.

My Drive contents change rarely, so the answer is aggressive caching. Notice the two flags above:

• --dir-cache-time 1000h keeps the folder structure cached for weeks, so after the first visit a folder opens instantly.
• --poll-interval 15s means real changes on Drive still propagate within seconds, so the long cache time never makes you see stale listings.

The directory cache lives in memory, so it starts cold after every reboot. To avoid the first-visit lag entirely, pre-warm the whole tree on startup. The --rc flag exposes a local control endpoint; add an ExecStartPost that asks rclone to walk the directory tree (metadata only, no downloads):

ExecStartPost=/bin/sh -c 'sleep 8; rclone rc --rc-addr 127.0.0.1:5572 \
  vfs/refresh recursive=true _async=true'

After that warm-up, navigation is instant — there are no API calls left to make until something actually changes. I also keep a tiny gdrive-refresh helper that calls the same vfs/refresh on demand, for the rare moment when I expect a brand-new file that the cache has not picked up yet.

A file manager that doesn't choke

My first surprise was that Thunar, XFCE's default file manager, froze solid the moment I opened the Drive folder. I switched to Nemo, which is a nicer file manager anyway, but the freeze taught me something important.

The slowness was not downloads. The rclone cache was nearly empty the whole time. The file manager itself was the problem: by default it does two expensive things on every folder it shows. It counts the items inside each subfolder (so it can print "14 items"), which means listing every subfolder over the network, and it reads the start of each file to guess its type and build thumbnails. On a remote filesystem, both turn into a storm of API calls.

In Nemo, turning these off makes browsing feel local:

gsettings set org.nemo.preferences show-directory-item-counts 'never'
gsettings set org.nemo.preferences show-image-thumbnails 'never'

A quick note on that second setting: you might expect 'local-only' to spare a remote mount. It does not. A FUSE mount looks local to the file manager, so "local only" still treats your Drive as fair game. It is all or nothing.

The thumbnail trap nobody warns you about

Here is the part that cost me the most time. Turn thumbnails back on, open a folder full of images on the Drive mount, and… you get generic "JPG" placeholders. No previews. Meanwhile, the exact same thumbnailer generates a perfect preview if you run it by hand on one of those files.

The reason is buried in how GNOME-based file managers decide whether to thumbnail at all. They consult a filesystem hint called filesystem::use-preview. Local disks report it; rclone's FUSE mount does not expose it, so the file manager quietly decides this filesystem is not previewable and skips generation entirely — even with the preference set to "always". There is no checkbox that fixes this. I looked.

The workaround is to stop waiting for the file manager and generate the thumbnails yourself, in the exact format it expects to find. The freedesktop thumbnail spec is simple once you know it:

• The file lives at ~/.cache/thumbnails/normal/<hash>.png (128 px) or large/ (256 px).
• <hash> is the MD5 of the file's URI, i.e. md5("file://" + url_quoted_path).
• The PNG must carry two text chunks: Thumb::URI (that same URI) and Thumb::MTime (the file's modification time in seconds). Without them the file manager treats the thumbnail as stale and ignores it.

Generating those is a few lines of Python with Pillow. For each image: compute the URI and its MD5, read the modification time, make the 128 px and 256 px versions, and embed the two text chunks:

import hashlib, urllib.parse, os
from PIL import Image, PngImagePlugin

def thumb(path):
    uri = "file://" + urllib.parse.quote(path)
    h = hashlib.md5(uri.encode()).hexdigest()
    mtime = int(os.path.getmtime(path))
    for size, px in (("normal", 128), ("large", 256)):
        out = os.path.expanduser(f"~/.cache/thumbnails/{size}/{h}.png")
        img = Image.open(path)
        img.thumbnail((px, px))
        if img.mode not in ("RGB", "RGBA"):
            img = img.convert("RGB")
        meta = PngImagePlugin.PngInfo()
        meta.add_text("Thumb::URI", uri)
        meta.add_text("Thumb::MTime", str(mtime))
        img.save(out, "PNG", pnginfo=meta)

Run that over a folder, refresh the view, and the previews appear — all of them, instantly, because the file manager now finds them ready instead of refusing to make them. I wired the script to a right-click action in Nemo so I can switch previews on for a specific image folder when I want them, and leave them off everywhere else for speed.

Bonus: offsite backups, for free

Once the remote exists, you get cheap offsite backups as a side effect. You do not even need the mount for this — rclone sync talks to the remote directly, which is more robust than relying on a FUSE mount being healthy inside a cron job:

rclone sync ~/my-backups gdrive:Backups

I run that nightly to push a small but important dataset to Drive, so it no longer lives on a single disk.

Takeaways

• rclone is the way to put Google Drive on Linux. Mount it as a systemd user service so it is always there.
• Browsing feels slow because of API latency. Cache the directory tree aggressively, keep change-polling on, and warm the cache on startup.
• If your file manager freezes, it is probably counting items and building thumbnails over the network. Turn both off.
• Thumbnails do not generate on FUSE mounts because the filesystem does not advertise previews. Generate them yourself in the freedesktop cache format and the file manager will happily display them.

None of this is exotic, but no single page told me all of it, and the thumbnail behaviour in particular looks like a bug until you understand it is a deliberate "I don't preview unknown filesystems" decision. Now my Drive is a fast, normal folder — and a backup target — and I can stop fighting it. Could I have clicked two buttons in GNOME instead? Probably. But I learned exactly how my machine talks to Google Drive, I had fun doing it, and in 2026 that is reason enough.