< the skull

WHEN KDE'S NATIVE GOOGLE DRIVE QUIETLY GAVE UP
==============================================
2026-06-21

I run Kubuntu on a Dell XPS 13, customized to within an inch of its life, and
for a while I just wanted one boring thing to work: my Google Drive showing up
as a folder in Dolphin. KDE advertises this. You open Online Accounts, add your
Google account, and Dolphin is supposed to grow a tidy little `gdrive:/` entry
you can browse like any other folder.

So I added the account. It authenticated. The entry showed up. I clicked it —
Access denied.

Not "wrong password." Not "try again later." A flat, permanent denial. Every
folder, every time.

It's not you, it's `kio-gdrive`
-------------------------------

If you go digging in the logs instead of staring at Dolphin, the real message is
uglier and a lot more honest:

  org.kde.kgapi: Requested resource is forbidden

Here's what's actually happening. KDE's Google Drive integration runs through
`kio-gdrive`, which talks to Google using the `kgapi` library and a shared OAuth
client ID that belongs to the KDE project. Google has been tightening the screws
on apps that request "sensitive" scopes — like full Drive access — without going
through their verification circus. The KDE project's client got caught in that
net. So the authentication step still works (the account adds fine, the entry
appears), but the moment you try to read anything, Google slams the door.

It's not your machine. It's not a misconfiguration. It's a credential the whole
KDE userbase shares, and Google decided it's had enough.

There's a workaround floating around the forums: register your own OAuth client
in Google Cloud and somehow feed it into `kio-gdrive`. I'd skip it. The people
who actually tried it report that it either still fails outright, or — worse —
it lists your files but refuses to copy anything down to disk. A file manager
that shows you files it can't open is more frustrating than one that just admits
defeat.

So I stopped trying to resuscitate `kio-gdrive` and did the thing everyone who's
been burned by it eventually does.

rclone, and a real folder
-------------------------

`rclone` mounts your Drive as an actual filesystem over FUSE. That distinction
matters more than it sounds. This isn't a KDE-only protocol that lives inside
Dolphin — it's a plain folder on disk that every app on the machine can see.
Your terminal, your editor, your scripts, your image viewer. All of them.

First, install rclone and FUSE. The version in Ubuntu's repos tends to lag, so I
use the official installer:

  sudo -v && curl https://rclone.org/install.sh | sudo bash
  sudo apt install -y fuse3

Then create the remote:

  rclone config

It's an interactive wizard. Pick `n` for a new remote, name it something you'll
recognize (I went with `gdrive-pablo`), choose `drive` as the type, leave the
client ID and secret blank for now, and pick scope `1` for full Drive access.
When it asks to use auto config, say yes — it pops open your browser, you log
in, you authorize, done. Confirm and quit.

Test it:

  rclone lsd gdrive-pablo:

If it lists your top-level folders, you're already further than KDE ever got
you.

Make it survive real use
------------------------

You can mount it by hand:

  rclone mount gdrive-pablo: ~/GoogleDrive --vfs-cache-mode full --daemon

That `--vfs-cache-mode full` is not optional, and it's the flag most people
forget. Without it, editing or writing files that are already open breaks in
ugly ways. With it, rclone uses a local disk cache and behaves like a normal
disk. It's the single setting that turns rclone from "technically works" into
"actually usable."

But mounting by hand every login is a chore, and I had two Drives to deal with.
So I let systemd handle it — as a user service, not a system one, because the
mount belongs to my session and my credentials.

Rather than write two near-identical service files, I used a systemd template —
one file with an `@` in the name. Whatever you put after the `@` when you enable
it becomes the `%i` variable inside. One file, any number of drives.

`~/.config/systemd/user/rclone-gdrive@.service`:

  [Unit]
  Description=rclone mount (%i)
  After=network-online.target
  Wants=network-online.target
  
  [Service]
  Type=notify
  ExecStartPre=/bin/mkdir -p %h/GoogleDrive/%i
  ExecStart=/usr/bin/rclone mount %i: %h/GoogleDrive/%i \
    --vfs-cache-mode full \
    --vfs-cache-max-size 2G \
    --dir-cache-time 12h \
    --poll-interval 15s \
    --umask 022
  ExecStop=/bin/fusermount3 -u %h/GoogleDrive/%i
  Restart=on-failure
  RestartSec=10
  
  [Install]
  WantedBy=default.target

Then enable one instance per drive, and turn on lingering so the mounts come up
even before I open a graphical session:

  systemctl --user daemon-reload
  systemctl --user enable --now rclone-gdrive@gdrive-pablo.service
  systemctl --user enable --now rclone-gdrive@gdrive-skull.service
  loginctl enable-linger "$USER"

Now both Drives mount themselves at boot, restart if they crash, and live as
ordinary folders under `~/GoogleDrive`.

The part nobody tells you: your own client ID and the 7-day trap
----------------------------------------------------------------

When you left the client ID blank earlier, rclone fell back to its shared client
— the one bundled with the tool and split across millions of users. It works,
but under any real load you'll start hitting `userRateLimitExceeded`. With two
drives competing for the same shared quota, it gets old fast.

The fix is to register your own OAuth client in Google Cloud. The short version:
create a project, enable the Google Drive API, set up the consent screen with
audience External, and create an OAuth client of type Desktop app. Copy the
client ID and secret, drop them into each remote, and reconnect.

And here is the detail that will save you a confused afternoon a week from now.

When you set up the consent screen, Google leaves the app in Testing mode by
default. In that mode, your refresh token expires after seven days. Everything
works beautifully — until exactly one week later, when every mount silently dies
and you have no idea why.

So before you walk away, publish the app to production. Google will warn you
that production normally requires verification; ignore it. For a personal app
you use yourself, it works fine unverified, and — critically — the token stops
expiring. That one toggle is the difference between "set it and forget it" and
"re-authenticate every Monday forever."

To apply the new credentials without nuking your config:

  rclone config update gdrive-pablo client_id "YOUR_ID" client_secret "YOUR_SECRET"
  rclone config reconnect gdrive-pablo:

The same client ID works for every drive — it identifies the app, not the
account, so each remote authorizes its own Google account separately.

Two rough edges worth sanding down
----------------------------------

A couple of things surfaced once the mounts were live.

The first was log spam — endless lines like `Dangling shortcut "..." detected`.
Those are broken shortcuts inside Drive itself, pointing at files you've since
deleted or lost access to. They're harmless, but rclone tries to resolve each
one, which costs API calls and slows down the first listing. Tell it to stop
bothering:

  --drive-skip-dangling-shortcuts

The second was Dolphin freezing hard enough to ask me to restart it. The culprit
turned out to be thumbnails. Because the mount is FUSE, Dolphin treats it as a
local folder — so when it tries to generate a preview for a 4 GB video, it
dutifully downloads the whole file to make a thumbnail. Open a folder full of
those and it grinds to a halt. The fix lives in Configure Dolphin → General →
Previews: uncheck the generators that read entire files (video, archives) and
drop the maximum file size to something small like 10 MB. Small images and PDFs
still preview; the giant stuff no longer drags everything down.

Two Google accounts, mounted as plain folders at `~/GoogleDrive/gdrive-pablo`
and `~/GoogleDrive/gdrive-skull`, coming up automatically at boot, on my own API
quota, with a token that doesn't quietly expire. Every app on the system can
read them, not just Dolphin. The local disk cache makes editing feel native.

KDE's Online Accounts still shows a Google Drive entry. It still throws Access
denied. I just don't click it anymore.


< the skull