GNOME 50 Drops Google Drive Integration — Nobody Stepped Up to Save It
GNOME 50 Drops Google Drive Integration — Nobody Stepped Up to Save It
- 60% of MD5 Password Hashes Can Be Cracked in Under an Hour with a Single GPU
- Dirty Frag: Root Access on Every Major Linux Distribution — No Patch, No Warning
- Ubuntu 26.04 LTS (Resolute Raccoon): The Most Ambitious Ubuntu LTS in a Decade
- Proton Mail: Data Transferred to FBI Again!
- How Close Are Quantum Computers to Breaking RSA-2048?
- How to Prevent Ransomware Infection Risks?
- What is the best alternative to Microsoft Office?
Linux & Open Source
GNOME 50 Drops Google Drive Integration — Nobody Stepped Up to Save It
After nearly four years without a maintainer, the libgdata library that powered Google Drive access in Nautilus has been quietly removed from GNOME’s virtual file system — and the community had ample warning.
Google Drive file access in GNOME’s Nautilus file manager is gone in GNOME 50, shipped with Fedora 44. Mail, contacts, and calendar integrations remain unaffected.
If you’ve upgraded to GNOME 50 — most visibly in the Fedora 44 beta — and suddenly found that Google Drive no longer appears in the Nautilus file manager’s left panel, you are not alone, and it is not a bug. The feature has been intentionally removed, the result of a slow-motion library abandonment that the GNOME project openly flagged long before the axe fell.
The issue traces back to libgdata, the library that GNOME’s virtual file system (GVfs) relied upon to communicate with Google Online Accounts for file access. libgdata has been effectively unmaintained upstream for close to four years. Because it still depended on the older libsoup 2.4 networking library — a version that has accumulated a string of security vulnerabilities and whose long-term maintenance is increasingly burdensome — distributions and the GNOME team could no longer justify keeping it.
“It is no longer supported, unfortunately. Libgdata, which was used to handle integration with some Google online services, has been unmaintained for nearly 4 years. GVfs has disabled the dependency by default 10 months ago, and GNOME Online Accounts checks for that.” — GNOME team response on the GNOME Discourse forum
Roughly ten months before GNOME 50’s debut, GVfs quietly disabled the Google Drive backend by default. GNOME Online Accounts (GOA), which manages third-party service logins, was updated to detect the missing backend and respond accordingly — which is why the “Files” toggle within a Google account in GNOME Settings has become non-functional.
A Call for Help That Went Unanswered
What makes the situation somewhat bittersweet is that the GNOME project did not simply delete the feature without warning. Developers posted a public appeal titled “Call for help with libgdata,” explicitly requesting a volunteer willing to take over maintenance of the library — or, ideally, port its Google Drive functionality to the modern libsoup 3 — until GNOME could engineer a cleaner replacement. The post attracted attention, discussion, and ultimately no takers. With no one to maintain it, removal became inevitable.
What still works / what doesn’t
Still functional: Gmail (mail), Google Contacts, and Google Calendar integration via GNOME Online Accounts are unaffected. These services use different, actively maintained libraries.
No longer available upstream: Mounting Google Drive as a virtual folder in Nautilus (the file manager) via GOA. The “Files” toggle within a Google account in GNOME Settings is non-functional in GNOME 50.
Distro caveat: Some Linux distributions — including Ubuntu and potentially others — may separately package a gvfs-google extension and maintain it independently. Whether your distribution offers this depends on its own packaging decisions.
A Broader Ecosystem Problem
The libgdata saga illustrates a recurring tension in open-source desktop Linux. Integrating with proprietary cloud services requires maintaining glue libraries that connect to constantly-evolving external APIs. When those libraries fall out of fashion — because no paid team owns them and volunteer interest wanes — the integration quietly rots until it becomes a security or compatibility liability.
In this case, libsoup 2.4 accumulated multiple CVEs through 2025 alone, creating pressure on Ubuntu’s security team and Debian maintainers to excise it. libgdata was the last significant user keeping libsoup 2.4 in Ubuntu’s “main” (supported) component. Removing libgdata allowed both projects to close a lingering security debt.
The upstream GNOME team and downstream distributions have suggested a path forward: someone could create a focused gvfs-google-drive library, porting only the Google Drive portion of libgdata to libsoup 3. That work has not yet materialised, but it remains the most realistic route to restoring native integration in the long term.
What Can You Do Now?
For users who relied on Nautilus’s Google Drive folder, a few alternatives exist. rclone is a mature command-line tool capable of mounting Google Drive as a local file system, though it lacks a graphical interface. Insync is a third-party graphical client for Google Drive on Linux, available as a paid one-time purchase. For many users, accessing Google Drive through a web browser remains the simplest and most reliable option — one that bypasses the libgdata problem entirely.
The situation is frustrating for casual users who simply expected the feature to keep working, but the GNOME project’s transparency throughout the deprecation process was notable. The warning signs were public; the call for help was genuine. The community had the opportunity to intervene. As one GNOME developer phrased it plainly: “We had our chance.”
