So does that include this gnome id workaround? Because it allows me to sign in now. I just don’t now how to create a “shortcut” to it in Dolphin places
Ah - I’m not sure about systems where the workaround is still functioning, sorry!
ok thanks. Let me know if there are any other solutions…No native folder gdrive is a real pain 
Please don’t use the GNOME ID; this will result in that ID getting blocked once Google notices it, because it’s being used in software Google hasn’t re-authorized. This will break it for you and also all GNOME users.
The current situation is that someone with interest and patience needs to jump through the new security hoops Google put in place so that we can get our own access re-authorized. Until that happens, it will remain broken.
Many KDE developers try to avoid Google products, so it may take a long time, or never come at all, unless someone else steps up to help.
See 480779 – Can not add Google to Online Accounts anymore using a recent version of signon-ui.
7 Likes
This is the best solution at the moment, creating a Google app, following step by step what is described here and the rclone tutorial, I managed to solve the problem. I hope that the maintainers can find a native solution, I would love to create it myself but my knowledge is insufficient.
2 Likes
I applied this workaround yesterday. Everything works really great! Thank you!! This is why I L 
O V E Linux
Thanks a million Bruno, it worked perfectly ok for me in Ubuntu 20.04.6 with
Sorry, but you’re not being clear enough. First of all, you need to transparently explain why the Drive integration works on Gnome but not on KDE. Is this a success of the Gnome developers, or is it a concession they made to Google that you haven’t? If it’s the latter, then it seems like you have no reason to be concerned anyway!
Loyal KDE users have suffered a lot due to these uncertainties regarding Google Drive. While Kio-Gdrive works perfectly on Kubuntu 22.04, it doesn’t work on Kubuntu 24.04! In the end, if we’re not going to use a distro with customization options as limited as Gnome, the cost of that shouldn’t be losing access to essential tools like Google Drive integration. So, as the KDE team, please be part of the solution, not the problem. Thank you. We are all family here. One for all, all for one. Long live LINUX, long live FOSS, long live FREEDOM!
The post you are replying to contained a link to the bug report for this issue. I’m reproducing the key parts of Nate’s comments there below, just for ease of reading.
Can you please help me understand what you’re perceiving as a lack of clarity or transparency in what’s written below?
Google blocked us from using this back in June because we weren’t able
justify our API usage to their satisfaction.No one is in charge of managing this; KDE is not a company with people assigned to things in that manner.
Most KDE developers minimize their usage of Google services these days, so the overlap between “people who care about Google Drive integration working” and “people who have the interest and time to engage with Google to prove the security of KDE’s Google Drive client implementation” is becoming smaller over time. That’s the backstory to why this broke, why it’s not fixed yet, and why even my exceptionally crude change took so long to get done.
If anyone wants to take initiative to communicate with Google directly on KDE’s behalf to prove the security of our Google Drive client, and then also do it again every year when they make us re-certify, and then also do it again randomly when they tighten the requirements again, please let me know and I’ll be happy to direct you to the right place.
KDE is a primarily community-driven FOSS project. Work getting done requires the contributions of volunteers - or sponsored developers - with the time, ability, and interest to figure things out, implement them, and maintain them.
My dear friend,
First of all, I am not a Google advocate. In fact, I see Google’s monopolization as a danger to the free software world. That’s why I understand the reluctance of KDE developers and their stance against Google’s, in my opinion, absurd policies.
However, there is a contradiction here. Google has not blocked all Linux distributions from using the Drive API. If that were the case, GNOME users would have also lost their Drive integrations. So, this issue is specific to KDE! Besides, you yourself mention that KDE developers are unwilling to invest time and effort in this matter.
In that case, we need to discuss this attitude. Either the standards imposed by Google pose a threat to the entire Linux community, and GNOME developers have accepted this by taking a path that goes against Linux standards, or Google’s standards are at an acceptable level, but they simply do not interest KDE developers enough.
From what I understand, the second case is true. If the first were true, it would have sparked a major debate and made headlines. So, what we need to discuss is the second scenario.
As much as I don’t want to accept it, a large user base is forced to use Google Drive due to its low-cost and high-storage solutions. If KDE developers are not considering the needs of this user base and are instead following their own roadmap, then as KDE users, it makes us question our own value. Doesn’t it?
I may have a suggestion on what should be done. Please either completely discontinue Kiogdrive integration and officially announce that you will no longer support it on principle—at least until Google stops behaving like Google—so that, as supporters of free software, we can respect KDE’s stance and principles, even if they do not align with our needs. Or, provide us with a roadmap for resolving the issue so that we, as users, can have a clear understanding of the situation.
Thank you.
From Nate’s comment:
If anyone wants to take initiative to communicate with Google directly on KDE’s behalf to prove the security of our Google Drive client, and then also do it again every year when they make us re-certify, and then also do it again randomly when they tighten the requirements again, please let me know and I’ll be happy to direct you to the right place.
I interpreted Nate’s suggestion as irony. If he was serious, he might consider collaborating with GNOME and other distro developers. This could help eliminate the perception of fragmentation that a Windows or macOS user sees in the Linux ecosystem. At the same time, it could also establish a strong defense mechanism against such attacks from proprietary software on free software.
The information I provided was factual and serious, not ironic.
This isn’t really an attack from Google; they simply tightened their documentation and reporting requirements for software using the Google Drive API.
It doesn’t feel like an attack; rather it’s just a standard big corporate bureaucratic thing that isn’t unreasonable per se, it just happens to burden smaller entities like us.
GNOME had someone willing and able to jump through those hoops and provide the required documentation this time (no guarantee for next time, of course).
KDE had no such person who was willing and able. Today, we still don’t.
No collaboration with others to resolve the issue is workable. The issue is ours in KDE to resolve because we need to provide documentation and evidence that our software is secure. Nobody else outside of KDE would have a reason to be interested in helping us with this — any more than we would have a reason to be interested in helping GNOME prove the security of their Google Drive client implementation to Google if the situation were reversed.
To my knowledge there is no roadmap to resolving the issue. This makes kio-grdive effectively a dead zombie project. I expect it to be archived eventually if nobody can be found who’s willing and able to jump through Google’s new security hoops.
Hopefully that clarifies the situation adequately.
3 Likes
There wouldn’t be any fragmentation, real or perceived, if Google just released a Drive client for Linux the same way they do for Windows and macOS.
That would make the integration available to all users in a consistent way and implicitly satisfy Google’s requirements.
1 Like
Thank you for the clarity and information. On the other hand, I find it hard to believe such a justification for the KDE ecosystem, which, in my opinion, is at least five years ahead of Windows and macOS. As one of the leading DEs in the free software world, KDE has an experienced team that has overcome many challenges and thousands of users. You’ll understand that I cannot expect the KDE team to back down just because of a procedural imposition by Google, a company famous for its nonsense. Even if this is being stated by you!
Therefore, the most reasonable explanation to me seems to be that you dislike Google and are unwilling to collaborate with them, which I completely understand. But please also acknowledge that, as users, we have not been able to find another cloud solution that offers package prices and content as competitive as Google’s.
Regarding a solution, I will repeat my suggestion: Please consider creating a shared pool with the GNOME team and developers of other major DEs for Google Drive. This is already happening de facto through shared XML files. In times of crisis like this, a shared pool would be invaluable in preventing users from being left stranded. Such a pool would be beneficial even if it required a GNOME developer to review KDE’s procedures or a KDE developer to examine GNOME’s procedures in the future. In fact, this could even be seen as a positive contribution to reliability.
I assume that a Drive client from Google might not be open source. For this reason, even their official client might not have been a preferred choice for free software enthusiasts. The free software world was alone yesterday, is alone today, and as long as big corporations maintain these policies, it seems like it will continue to be alone. But I heard that Google has developed a Drive application for ChromeOS, which is Linux-based. But it needs to be researched whether it can be ported or not.
The fact that kio-gdrive is a zombie is frustrating, but by no means an obstacle.
It is possible to use the Gdrive web interface as a “classic” application with :
It may not be as convenient, but Gdrive is not the only cloud storage for which there is no kio slave.
Unfortunately, the solutions you mentioned are no different from using Google Drive through a browser. What we need is access to Drive folders directly from Dolphin. For this, there is rclone, but unfortunately, it is slower compared to kio-gdrive. Also, what we are discussing here is not alternative programs but the status of kio-gdrive.
Ultimately if KDE developers don’t like Google and don’t use their services, then KDE developers won’t write or maintain software that requires coordination with Google. It’s pretty much as simple as that.
@SquarePants you seem like a very passionate person; maybe you would like to volunteer to comply with Google’s bureaucracy on behalf of KDE here? Is that something you’d be willing to do?
3 Likes
My dear friend @ngraham
Of course, and that’s completely understandable. But KDE is not just a DE exclusive to KDE developers. Thousands of people use KDE, and Google Drive integration is of great importance to them—myself included. You can easily see this from the interest shown in this topic. So my expectation from you is this: Either completely leave the project and announce it, or consider collaborating with other distros. But please, do not leave the project in limbo. This uncertainty is detrimental both for users and for KDE’s reputation.
I am honored by your offer. Believe me, I am ready to voluntarily do whatever is necessary for free software and for KDE, which I admire. However, I have no experience in coding and am quite new to the Linux world. Still, if you would like to assign me a task, just let me know. Long live LINUX, long live FREE SOFTWARE, long live FREEDOM!