When KDE's Native Google Drive Quietly Gave Up

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.