Thanks everyone for reporting. And thanks @skeller for the insight. You were right - the new versions outran the COPR version numbers.
I rebuilt the packages. Please dnf update and let me know if there are still any errors.
I ran a dnf update and I’m still getting the same error as ribeirov; any other suggestions?
sudo dnf update --refresh
did the trick, thank you!!
It worked for me too—thanks. What incredible work; congratulations to everyone involved.
Everything is working again. 
Tôi đã cài thử và rất tốt. Cảm ơn bạn đã chia sẻ : Ubuntu 26.04
sudo add-apt-repository ppa:fluhus/gnome-googledrive
sudo apt update
sudo apt install gnome-online-accounts gvfs
# You might need to log out and in again after installing.
Not a bug — intentionally dropped in GNOME 50. The library that handled the Drive connection (libgdata) went unmaintained for years, got archived, and GNOME cut the integration entirely. The missing files toggle in Online Accounts is part of that same change, not something you can recover through settings. Wrote up what happened and what you can use instead: GNOME 50 Dropped Google Drive: What Happened and What to Use Instead - Port & Patch
Funcionou! Obrigado!
Why? Review changes, move libgdata from the Archive, merge, enjoy Google Drive working again. Almost everything is ready to ship this library with new API alongside its previous version, so this is safe move.
Also, what is the rationale beyond dumping already working code which was missing a little few-liner and replacing it with vibe-coded counterpart?
Why?
Of course, from the perspective of somebody who just appeared out of nowhere and decided to be condescending for no reason whatsoever, this may seem trivial.
For that, you’ll have to ask @fluhus. GVFS has not been changed—the libgdata support is still deprecated and disabled by default.
I’m well aware of this situation. But your answer leaved alone question how is lack of maintainers solved by dumping code away and replacing it with new one. I see no evidence of bad design decisions in any comment neither in GVFS nor in libgdata, only people are missing. So I fixed bugs pointed out in discussions and I’ll fix the remaining ones if any, but that assumes alive libgdata. Again, a lot of work was already invested and all of that is wasted now yet merge request that made backend disables was almost done years ago.
Now, once answer is backed by code, let me get back to this snipped. The perspective is still the same across all the Free Software. Maintainership is, above all, a matter of trust. As somebody who just appeared out of nowhere I obviously cannot help here. A new maintainer has to be someone established. However I can provide easily reviewable code fixes and I did so as an alternative to single monster patch opening for a decision to:
- accept monster patch
- accept libgdata trivial fix and google backend fix
The later option assumes pulling libgdata out of Archive or point the build to my fork. Assuming this is impossible leaves monster patch the only viable option. I can help with fixing the code only and I’ll do so in case the later is accepted as I do not believe in code revolutions.
Amazing thank you. Being very new to desktop linux and fedora 44, i only got around to trying this today and it works perfectly.
I was then further impressed that copying gdocs and gsheets from Google drive to local machine automatically converted them into xls and doc for libre office to open.
EDIT that was short lived. After resuming from suspend I can no longer access the location.
This location could not be displayed.
Sorry, could not display all the contents of “My Drive”: Google API error: Request had invalid authentication credentials. Expected OAuth 2 access token, login cookie or other valid authentication credential. See Integrating Google Sign-In into your web app | Web guides | Google for Developers . (code 401)
EDIT EDIT although on unmounting / remounting the google drive in the files program, I can access it again.
So far this has been rock-solid.
I have also created a Rclone Google mount and will also test a google-drive-ocamlfuse, but so far this has been more solid than Rclone, with the exception that Rclone seems faster since I created a personal Google API key for it.
Beyond that, this is doing exactly what it says on the tin…
Hi, same error…
1: delete your account in online accounts
2: add again your account in online accounbs, but select new rights for managing files (gdrive)…
3: you should navigate your files
hi!
thank’s a lot from France, you’re awesome!
Gnome or KDE I don’t care (KDE gdrive blacklisted by google, gnome dropped gdrive support), now I have a modern desktop AND emmbedded gdrive!
Fedora 44 WS here.
It worked. Thanks.
However, I am receiving this error when trying to open a file directly from it:
“Cannot open file
‘/run/user/1000/gvfs/google-d…HdlHuMhxOyZ2CpGgOn5TUSuF0vHd’.
No suitable Importer found. Please check file format and extension.”
If anyone has an insight to solve this, please let me know.
Just installed this on Fedora 44. Enabling the copr site, and doing a dnf update is as simple as it can get. Thanks very much, I am extremely happy, that this works again on Fedora.
While we’re at it: One feature request, which most likely exceeds the scope of your work, but still: As far as I can tell, the directory with the Google files is being mounted, as soon as I open the respective folder in Files (aka Nautilus?). Would it be possible to make that happen as part of the login?