Fedora 44 WS beta/ Gnome 50 .
Google Drive is not displayed in the file manager in the beta version of Fedor 44.
Is it no longer supported or is it a bug?
In the settings where you add a Google Online account, you can enable permissions for mail, contacts and calendar. It is impossible to give access to files. There is also no way to give this permission on the Google website.
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 by default 10 months ago, and GNOME Online Accounts checks for that.
If people wish to work on restoring this functionality, they can reach out to the GVFS maintainer.
Why do you say it doesn’t work? On Fedor 42 and 43 everything works fine. But I decided to test Fedora 44 with Gnome 50 and it doesn’t work here
As written before, Libgdata has been unmaintained for years. It pulled in ancient dependencies into the software stack (libsoup2), blocking improvements in other parts of our software stack. I’m happy for you that it had not broken for you yet, it might break in an uncontrolled way at any random point in the future though, plus there is no unlimited number of volunteers that will happily spend time to understand that unmaintained codebase once things break. You are free to experiment with the existing code and compile your own local versions if you feel adventurous and maintain such functionality for yourself.
Oh man, this is something very important to me; when I update my Fedora system, I’ll lose this functionality. 
There’s no point in contacting the GVfs maintainer about this unless you intend to fork and maintain libgdata. My last call back in December 2022 was not a joke. It’s been so long that libgdata is now archived, so you cannot contribute even if you want to.
GNOME had already disabled this functionality years ago, but distros sometimes move slowly. If Fedora had disabled it sooner, then perhaps users would have noticed the problem before the project was archived rather than after. Oh well.
Hi,
that check was for gvfs to allow you access Google Drive, but since
gvfs depends on libgdata and it was not ported to libsoup3, the gvfs
effectively did not use this for several versions already. A move was
done to hide it from the GUI, to avoid user confusion. Note the Drive
was visible in Files (nautilus), but it could not be accessed from
there.
Did you use it in other ways than through gvfs?
For the reference:
Bye,
Milan
Hi, big fan of google-drive-in-nautilus here.
Sucks to see it go. 
What would it take to bring it back? Is it only the libsoup migration or are there other things? I am happy to try and take a look.
Hi,
I can see two options, one is to port libgdata to libsoup 3 series, or
to write a built-in code into the gvfs, replacing the libgdata API it
uses.
You better ask the gvfs project maintainers what their preference would
be before starting on it. From my point of view, libgdata is dead, keep
it as that.
Bye,
Milan
Hello!
I just got the sad news that the Google Drive integration with Nautilus is going away (or maybe has been gone for a while). This means a significant reduction in QOL for me using GNOME.
So I’d like to ask, what would it take to bring it back?
Is it only about the libsoup migration? Or are there other things? I’m happy to try and take a look.
Libgdata is done, and you can’t really resurrect it.
You can check the subset of libgdata used by GVFS for the Google Drive backend, and reimplement it in a separate library that uses non-deprecated dependencies.
Thank you! I’ll take a look.
Start by reviewing Philip’s suggestions here.
Porting libgdata to libsoup3 would be a bare minimum. The most recent merge request is here, but it was broken.
Hi, gvfs maintainer here. There is no need to resurrect the libgdata library, certainly not the whole library. Gvfs only used a relatively small part of it, so it would be enough to resurrect and simplify just the Drive-related part. The problem with Google APIs is that they evolve quite quickly, which makes it difficult for them to maintain a universal library. So the way to restore the functionality would be to create a small Drive-related library without any API guarantees, either separately or as part of the GVfs codebase, similar to other GNOME projects that still support some Google services.
Hi all, I’ve created a lightweight(-ish) and self-contained reimplementation of Google Drive support directly in gvfs (removing the dependency on libgdata). The new backend is written from scratch and uses the modern Google Drive REST API via libsoup3. It supports the basic functions needed for Nautilus: browsing, upload, download, mkdir, rename, etc. I tried to keep it minimal and support exactly what Nautilus needs. I’ve been testing it on my personal Google Drive with Fedora Workstation 43 / GNOME 49.
Some advanced features and edge cases are still in the works (see below), but I believe the current state is clean and useful enough to start testing with the community.
Deliberate behavioral changes compared to libgdata:
delete on a file used to remove it permanently with libgdata, now it sends it to Drive’s trash. Pressing shift+delete removes it permanently.Main planned follow-ups:
Happy to get your thoughts and feedback. I’m happy to open a merge request to gvfs, and to help maintain this backend going forward.
I just have to thank you for the work you are doing. 
If you still need to connect Google Drive and have it mounted, you can use RaiDrive. I use Google Drive daily, and for me, having it readily available is essential; I was deeply saddened by the news that it would no longer be accessible via GNOME Accounts in GNOME 50. However, I remembered that I used this app back in my Windows days, and upon checking, I discovered there is a Linux version available. It is a CLI version, but it allows you to mount your Drive to a mount point of your choice, enabling you to use it just as you normally would through your favorite file manager.
One small detail: after mounting it, it takes a few seconds to appear as an additional drive in your file manager’s list of drives.
Update:
The libsoup3-based Google Drive integration can handle most day-to-day use now.
I’ve been dog-fooding it on my personal machine for the past few weeks, both with Nautilus and with my gio-based scripts. Since the last update: uploads have been optimized, shared drive support was added, multi-parent deletion was implemented, and more testing and fixing.
Current behavioral differences compared to libgdata:
Shared with me is now sorted by share time, mirroring Drive’s web UI.delete on a file sends it to trash.Still pending:
Happy to create a merge request. And happy to write instructions if people want to download my fork and test it. Feedback is welcome!
Please do write a small blurb for the folks like us who just moved to 50.
Hi @fluhus , thanks for your work. If I want to test it what is the best way to do so? Do I need to build gvfs locally and install manually or will there be development versions available I can install via a package manager like apt?