When KDE's Google Drive Integration Looks Right but Still Says “Access Denied”

I recently ran into one of those Linux desktop problems that looks simple at first and then slowly turns into a rabbit hole.

The setup was ordinary enough: KDE Plasma, Dolphin, Online Accounts, and kio-gdrive installed. The Google account was added successfully. The authentication window opened, the permissions were accepted, and Dolphin showed the Google Drive entry under Network. On the surface, everything looked correct.

Then came the actual test: opening the Drive.

Instead of files, Dolphin returned Access denied. Testing from the terminal told the same story. Listing the gdrive:/ root worked, which proved that KDE could see the registered online accounts. But trying to enter the actual account folder failed with messages like:

org.kde.kgapi: Requested resource is forbidden.
kioclient5: Access denied

That detail matters. If gdrive:/ lists the account names, the local KDE plumbing is at least partially working. The account exists. KIO is installed. The desktop knows about the provider. The failure happens later, when kio-gdrive tries to talk to the real Google Drive API.

In other words, this is not just “Dolphin being weird.” It is not a missing package. It is not a typo in the path. It is not fixed by logging in three more times and angrily clicking every permission checkbox Google shows you.

The problem appears to be in the relationship between KDE's Google Drive integration and Google's API authorization. Recent community reports point to the same pattern: authentication succeeds, but Drive access is rejected afterward. KDE's kio-gdrive depends on Google's API accepting KDE's OAuth client. When Google refuses or restricts that client, the local desktop can still know that the account exists, but the Drive contents remain blocked.

That is why this bug feels so misleading. The login flow gives you the impression that everything worked. KDE shows the account. Dolphin shows a Drive location. But the server-side API call comes back forbidden.

The OAuth workaround

There is a community workaround: create your own OAuth client in the Google Cloud Console and make KDE use your own credentials instead of the built-in provider credentials.

The rough idea is:

create a Google Cloud project;
enable the Google Drive API;
create an OAuth client ID;
add the needed redirect URI / desktop app configuration;
replace or override KDE's Google provider file so KDE authenticates using your own OAuth client;
remove and re-add the Google account in KDE Online Accounts.

This can work, but it is not a clean fix. It is a workaround. You are essentially taking responsibility for the OAuth client that KDE would normally provide. Some users also report that token refresh can still be fragile, meaning the setup may work for a while and then require re-authentication later.

So yes, the OAuth hack is real. But it is not what I would call a comfortable long-term desktop solution. It is the kind of fix you try when you enjoy debugging your desktop more than using it.

What people are using instead

The practical Linux answer, as usual, is less glamorous and more reliable: use another tool.

Rclone

For a free and dependable setup, rclone is probably the best option. It supports Google Drive well, can list files, copy files, sync folders, and mount a Drive as a local directory.

A typical setup looks like this:

sudo apt install rclone
rclone config

After configuring a remote, you can test it with:

rclone lsd mydrive:

And mount it locally with something like:

mkdir -p ~/GoogleDrive
rclone mount mydrive: ~/GoogleDrive --vfs-cache-mode writes

Once mounted, the folder can be opened from Dolphin like any normal directory. It is not as visually integrated as KDE's gdrive:/ location, but it actually works, and that counts for more.

Insync

If you want a polished GUI and do not mind paying, Insync is one of the better-known Google Drive clients for Linux. It behaves more like a traditional sync client: choose folders, sync locally, and manage things from a desktop interface.

It is not free, but it is probably the closest experience to “install it and stop thinking about it.”

overGrive

Another paid option is overGrive. It is simpler than Insync and focuses on syncing Google Drive to a local folder. For users who just want their Drive files available locally without touching command-line tools, it can be enough.

Browser-only access

The boring option is still valid: use Google Drive in the browser. It avoids the KDE integration problem entirely. Of course, it also means giving up the nice file-manager workflow that made kio-gdrive attractive in the first place.

My takeaway

KDE's Google Drive integration is a great idea. When it works, it feels native: Drive appears in Dolphin, KDE apps can open remote files, and the desktop experience stays consistent.

But right now, if you hit the Requested resource is forbidden error after successful login, the most likely problem is not your local setup. It is the Google Drive API refusing the KDE client or the current authorization path.

You can try the OAuth workaround if you want to experiment. You can wait and hope the KDE and Google side of the issue gets sorted out. But if you need access to your files today, the practical answer is simple:

Use rclone for a free setup, or use a paid client like Insync or overGrive if you want a GUI.

It is not as elegant as Dolphin's native gdrive:/ integration. But elegance stops mattering the moment the file manager says “Access denied.”

Related documents