Bug 480779

Sorry, versions:

SOFTWARE/OS VERSIONS
Linux/KDE Plasma:  KDE Neon Unstable
(available in About System)
KDE Plasma Version: 6.0.80
KDE Frameworks Version: 5.249.0
Qt Version: 6.6.1

Indeed, it looks like we're going to need to make some changes here.

Works fine for me on Fedora Rawhide. Likely has to do with signon-ui/QtWebengine, but there's no obvious difference between Fedora and Neon as far as I can tell

*** Bug 482808 has been marked as a duplicate of this bug. ***

I can reproduce this bug on my machine. 

Operating System: Arch Linux 
KDE Plasma Version: 6.0.1
KDE Frameworks Version: 6.0.0
Qt Version: 6.6.2
Kernel Version: 6.7.8-arch1-1 (64-bit)
Graphics Platform: Wayland
Processors: 12 × AMD Ryzen 5 5625U with Radeon Graphics
Memory: 14.5 GiB of RAM
Graphics Processor: AMD Radeon Graphics

Hi all, I can confirm this bug either in a HP Zbook running Plasma 6.00 and also in a virtual machine running VMWare also running Plasma 6.00.
My google account is 2FA activated.
If you need more details, just let me know.

I have he same issue on KDE Neon based on Ubuntu 22.04 with KDE 6 upgraded from KDE 5.

Additionally, existing Google accounts do not show any files any more (the loading never stops).

Running systemsettings from the command line and trying to add a new google account I get:

"google"
Looking for plugin ""
Starting auth session with "oauth2"
Info:
        Id: 105
        caption: "google"
        owner: ""
        userName: ""
qt.dbus.integration: Could not disconnect "com.google.code.AccountsSSO.SingleSignOn.Identity" to "destroyed(QObject*)" : Pointers are not supported: QObject*


This occurs in a Gentoo system with plasma-6.0.3 with qt-6.7.0

*** Bug 484741 has been marked as a duplicate of this bug. ***

*** Bug 489645 has been marked as a duplicate of this bug. ***

*** Bug 489435 has been marked as a duplicate of this bug. ***

I'm 99% sure that "qt.dbus.integration" error from post #8 is not related to the issue at hands, and in fact is just a side effect of automatic runtime method registration which was not supposed to register the pre-descruction signal.

I just tripped on this, and here's a workaround that worked for me, combined from an earlier workaround posted in #485286 and my own experimentation:

 1. I maximized the embedded browser window that displays the authentication page
 2. I switched the language to Polish (my language)
 3. As per the original workaround (which was insufficient on its own in my case), I clicked Next with mouse instead of using Enter

No further problems encountered.

*** Bug 490925 has been marked as a duplicate of this bug. ***

(In reply to Szczepan Hołyszewski from comment #13)
> I just tripped on this, and here's a workaround that worked for me, combined
> from an earlier workaround posted in #485286 and my own experimentation:
> 
>  1. I maximized the embedded browser window that displays the authentication
> page
>  2. I switched the language to Polish (my language)
>  3. As per the original workaround (which was insufficient on its own in my
> case), I clicked Next with mouse instead of using Enter
> 
> No further problems encountered.

This worked for me too, although I did not change the language.

Tokens expiring in Dolphin also. Also cant add Google account in Solus Plasma 6.

(In reply to gabriel.rilling from comment #15)
> (In reply to Szczepan Hołyszewski from comment #13)
> > I just tripped on this, and here's a workaround that worked for me, combined
> > from an earlier workaround posted in #485286 and my own experimentation:
> > 
> >  1. I maximized the embedded browser window that displays the authentication
> > page
> >  2. I switched the language to Polish (my language)
> >  3. As per the original workaround (which was insufficient on its own in my
> > case), I clicked Next with mouse instead of using Enter
> > 
> > No further problems encountered.
> 
> This worked for me too, although I did not change the language.

I've tried this a few times on two separate systems, I don't speak polish and even tried that part specifically but unable to reproduce today.
All items give an error indicating that there is an issue with the browser used for sign or the app setup to allow sign-in.

*** Bug 485286 has been marked as a duplicate of this bug. ***

(In reply to Elvis Angelaccio from comment #18)
> *** Bug 485286 has been marked as a duplicate of this bug. ***

Actually, even this report really looks like a duplicate of #420280

I guess we can close this one as well?

(In reply to Elvis Angelaccio from comment #19)
> (In reply to Elvis Angelaccio from comment #18)
> > *** Bug 485286 has been marked as a duplicate of this bug. ***
> 
> Actually, even this report really looks like a duplicate of #420280
> 
> I guess we can close this one as well?

Like https://bugs.kde.org/show_bug.cgi?id=420280#c105 , I'm facing this bug on Arch with a fairly recent signon-ui version (0.17+20231016), so this may not be the same bug as #420280 which is apparently due to a too old signon-ui version.

Seconded,

I am on signon-ui 0.17+20231016-2 and facing this issue.

(In reply to gabriel.rilling from comment #20)
> (In reply to Elvis Angelaccio from comment #19)
> > (In reply to Elvis Angelaccio from comment #18)
> > > *** Bug 485286 has been marked as a duplicate of this bug. ***
> > 
> > Actually, even this report really looks like a duplicate of #420280
> > 
> > I guess we can close this one as well?
> 
> Like https://bugs.kde.org/show_bug.cgi?id=420280#c105 , I'm facing this bug
> on Arch with a fairly recent signon-ui version (0.17+20231016), so this may
> not be the same bug as #420280 which is apparently due to a too old
> signon-ui version.

Right, I'll rename this report then.

Btw, I cannot reproduce on arch with signon-ui version 0.17+20231016-2

For Gentoo this bug is solved with =>signon-ui-0.15_p20231016-r2

(In reply to Szczepan Hołyszewski from comment #13)
> I just tripped on this, and here's a workaround that worked for me, combined
> from an earlier workaround posted in #485286 and my own experimentation:
> 
>  1. I maximized the embedded browser window that displays the authentication
> page
>  2. I switched the language to Polish (my language)
>  3. As per the original workaround (which was insufficient on its own in my
> case), I clicked Next with mouse instead of using Enter
> 
> No further problems encountered.

Incredibly, it works. Totally nonsensical, but it works.

(In reply to Guido from comment #24)
> Incredibly, it works. Totally nonsensical, but it works.

Okay, this gets me further into the sign on process, where it asks me to verify my Google account on my phone, it then momentarily appears to succeed, then the embedded browser page abruptly clears and switches to say: 

> This app is blocked
> This app tried to access sensitive info in your Google Account. To keep your account safe, Google blocked this access.

When starting systemsettings from the commandline and I run through this process, I get this message:

> org.kde.kaccounts.lib: Error:
> org.kde.kaccounts.lib:   "Access grant not present"

So it seems that this can work when the embedded browser window is made full-screen (which is very weird, and no, I didn't have to change the default language). Regarding making the embedded browser full-screen, if I double-click on the titlebar, then the process will fail like it always does; I have to click the maximize button on the titlebar to have any kind of progress.

Given the error "This app is blocked", maybe this issue is on Google's end?

(In reply to Michael from comment #25)
> Given the error "This app is blocked", maybe this issue is on Google's end?

Yeah, something about what KDE wants to do with the account is tripping some (seemingly newer?) protection on Google's end.

Ideally, KDE should use OAuth2 via the user's default browser instead of opening up an integrated browser that doesn't know any sessions.

See this interesting comment here about contents of `/usr/share/accounts/providers/kde/google.provider`:
https://discuss.kde.org/t/kde-online-accounts-not-signing-in/3411/38

(In reply to Diego from comment #28)
> See this interesting comment here about contents of
> `/usr/share/accounts/providers/kde/google.provider`:
> https://discuss.kde.org/t/kde-online-accounts-not-signing-in/3411/38

Changed provider details to those specified in the linked post used by gnome.  Mine works now.
It seems like the details specified in the google.provider file included by default with KDE are just invalid now.

*** Bug 496600 has been marked as a duplicate of this bug. ***

*** Bug 495192 has been marked as a duplicate of this bug. ***

Now, it is broken on openSUSE Leap 15.6 ; one more time .

The workaround of using the GNOME ClientID and/or replacing/editing the KDE google.provider file with the contents of the GNOME one works for several people - https://discuss.kde.org/t/kde-online-accounts-not-signing-in/3411/38

That suggests to this ignorant peasant that a fix might be straightforward? (Unless it means waiting for Google to provide an updated ClientID).

It's possible to do this without changing a package-owned file. Instead, you can create your own copy of that file in ~/.local/share/accounts/providers/google.provider, and whatever ClientId/ClientSecret you put there will override the one from /usr/share/accounts/providers/kde/google.provider . See discussion at Invent: https://invent.kde.org/network/kaccounts-providers/-/issues/6

You can also create your own client ID, instead of co-opting Gnome's. See the clone instructions for this: https://rclone.org/drive/#making-your-own-client-id

(In reply to devminer from comment #27)
> Ideally, KDE should use OAuth2 via the user's default browser instead of
> opening up an integrated browser that doesn't know any sessions.

I agree, this is what Gnome does since last year: https://gitlab.gnome.org/GNOME/gnome-online-accounts/-/merge_requests/139/diffs#e5013ca9537031cc64a62645433ba8c7f51deb1e  It's probably less likely to make Google unhappy. And it's more convenient to the user, since there's a good chance they've already authenticated to Google in their browser.

Here's a discussion from Gnome about Google getting upset about webviews: https://gitlab.gnome.org/GNOME/gnome-online-accounts/-/issues/157.

I tried to look into what Gnome did about verification, and didn't really find any equivalent to the recent request to KDE: https://invent.kde.org/network/kio-gdrive/-/issues/1 . Best are:

* Adding a new API key six years ago: https://gitlab.gnome.org/GNOME/gnome-online-accounts/-/commit/43a20cfe4d54ddf4fbb9c87996c0beab1b14be75
* Submitting for verification five years ago: https://gitlab.gnome.org/GNOME/gnome-online-accounts/-/issues/42

(In reply to Andrés Becerra from comment #23)
> For Gentoo this bug is solved with =>signon-ui-0.15_p20231016-r2

Using Gentoo and signon-ui-0.15_p20231016-r2 installed, but no luck.
Must be other build problem

Hi! 

On OpenSUSE Tumbleweed this doesn't work.. 

No matter if I change the language or maximize the window or use a password or let Google send me a confirmation code - nothing works, I always get 

"This app is blocked." 

Could someone break down the other workaround with gnome online accounts in the necessary steps? 

If I try to install gnome online accounts, zypper demands to pull basically all packages for the full gnome desktop - this is not an option for me (bad experiences with mixed desktop environments!). 

Also, worth mentioning: 

Merkuro Contacts can grab my Google addressbook! 
But kmail cannot be configured to work with the same Google account! 

Thx, p.

(In reply to piedro from comment #38)
> Hi! 
> 
> On OpenSUSE Tumbleweed this doesn't work.. 
> 
> No matter if I change the language or maximize the window or use a password
> or let Google send me a confirmation code - nothing works, I always get 
> 
> "This app is blocked." 
> 
> Could someone break down the other workaround with gnome online accounts in
> the necessary steps? 
> 
> If I try to install gnome online accounts, zypper demands to pull basically
> all packages for the full gnome desktop - this is not an option for me (bad
> experiences with mixed desktop environments!). 
> 
> Also, worth mentioning: 
> 
> Merkuro Contacts can grab my Google addressbook! 
> But kmail cannot be configured to work with the same Google account! 
> 
> Thx, p.

I can confirm that. I use the latest Tumblewed too. Merkuro contacts is ok but I can't connect to Google drive.
Kmail is working for me and I have configured my gmail account without problem.

This is still a problem for me with openSUSE 15.6 Leap with the experimental Plasma 6 repo (version 6.2.5).
Here is the workaround I use: I place the content of the codeblock in this comment https://discuss.kde.org/t/kde-online-accounts-not-signing-in/3411/38 in $HOME/.local/share/accounts/providers/google.provider

Just noticed this bug. Was trying to use google cloud in dolphin since my company requires it, but couldn't login. Guess I will have to look for different options.

(In reply to adamplusplus from comment #40)
> This is still a problem for me with openSUSE 15.6 Leap with the experimental
> Plasma 6 repo (version 6.2.5).
> Here is the workaround I use: I place the content of the codeblock in this
> comment https://discuss.kde.org/t/kde-online-accounts-not-signing-in/3411/38
> in $HOME/.local/share/accounts/providers/google.provider

That workaround worked flawlessly

Created attachment 177337 [details]
Result after login with a Google Account in KDE

A possibly relevant merge request was started @ https://invent.kde.org/network/kaccounts-providers/-/merge_requests/42

The suggested workaround to replace the service provider file works for me to add the Google account to the KDE system settings. 

But my original problem is still the same - I cannot add the Gmail account to Kmail!  

Without the option to add Google Mail accounts, Kmail is pretty much useless as a centra mail management application to handle all mail. 
Which is really sad - I am one of these rare users who really likes Kmail and it's vast functionality and configurability. 

p.

Git commit 1652091be7df65ea16e6eb6d044460c90c19b420 by Nate Graham.
Committed on 14/01/2025 at 20:27.
Pushed by ngraham into branch 'master'.

Google: stop requesting gdrive permission

Google blocked us from using this back in June because we weren't able
justify our API usage to their satisfaction. As such, the permission is
now blocked, and including it here prevents people from logging into
their Google accounts for any other purposes, making 25% of the
KAccounts KCM non-functional. Remove the gdrive permissions for now so
at least other Google things can work (at least in theory).
FIXED-IN: 24.12.2

M  +1    -2    providers/google.provider.in

https://invent.kde.org/network/kaccounts-providers/-/commit/1652091be7df65ea16e6eb6d044460c90c19b420

That's a bummer. I use this extension exclusively for exchanging files with Google Drive ... I'd hardly consider this "RESOLVED FIXED". :-(

What's more, the solution to use the GNOME configuration file at https://discuss.kde.org/t/kde-online-accounts-not-signing-in/3411/38 seems to work fine here, so this isn't even a technical issue, more like a configuration one. Can't we simply use the same line of reasoning to persuade Google to allow KDE access the Google ecosystem as the GNOME guys did? What did they do differently?

This report might be marked as RESOLVED FIXED, but a different bug report should be opened to fix the now missing google drive integration.

Yes, feel free. This bug report is purely about being unable to *add* a Google account. The fact that Google Drive is broken now is a separate (and worse) issue.

JFYI, the solution to use the GNOME configuration file is no solution at all; it's essentially impersonating GNOME and piggypacking on the work they *did* do to retain permission to access Google Drive that KDE wasn't able to do yet. If Google finds out about this, it's likely they'll revoke GNOME's authorization too to prevent others from using it for software that wasn't approved, permanently ban KDE from accessing Google Drive again, or both.

(In reply to Nate Graham from comment #50)
> JFYI, the solution to use the GNOME configuration file is no solution at
> all; it's essentially impersonating GNOME and piggypacking on the work they
> *did* do to retain permission to access Google Drive that KDE wasn't able to
> do yet. If Google finds out about this, it's likely they'll revoke GNOME's
> authorization too to prevent others from using it for software that wasn't
> approved, permanently ban KDE from accessing Google Drive again, or both.

I think the line of reasoning presented isn't "KDE should just steal the gnome config" but more along the lines of GNOME seems to have engaged with google and properly resolved this including the google drive concerns and could we find out who is in charge of managing these APIs/etc and assign this to them so that they can engage with google to properly fix this instead of removing functionality?  

It seems like at that point, we already know the current code itself is sound so any changes made to remove functionality here to make it work now would end up reverted, so would end up just being wasted effort, even if that effort is minimal.

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.

I use openSUSE Tumbleweed and replacing google privider with Gnome ID is solution for me. It works but Nate Graham has right in his latest comment.

Git commit 78a81aafedced524c1bc9f16788c4304acc3b807 by Nate Graham.
Committed on 16/01/2025 at 14:58.
Pushed by ngraham into branch 'release/24.12'.

Google: stop requesting gdrive permission

Google blocked us from using this back in June because we weren't able
justify our API usage to their satisfaction. As such, the permission is
now blocked, and including it here prevents people from logging into
their Google accounts for any other purposes, making 25% of the
KAccounts KCM non-functional. Remove the gdrive permissions for now so
at least other Google things can work (at least in theory).
FIXED-IN: 24.12.2


(cherry picked from commit 1652091be7df65ea16e6eb6d044460c90c19b420)

Co-authored-by: Nate Graham <nate@kde.org>

M  +1    -2    providers/google.provider.in

https://invent.kde.org/network/kaccounts-providers/-/commit/78a81aafedced524c1bc9f16788c4304acc3b807

(In reply to Roke Julian Lockhart Beedell from comment #55)
> Created attachment 177501 [details]
> Result after login with a Google Account in KDE
This is what's fixed here.


(In reply to Roke Julian Lockhart Beedell from comment #56)
> Created attachment 177502 [details]
> Error in KCM GUI
This is a different issue, typically seen in built-from-source sessions. Not related to this issue.

(In reply to OpenOS-Founder from comment #58)
You'll have more luck asking that at https://discuss.kde.org/new-topic. I don't think this is the place for that.

(In reply to Roke Julian Lockhart Beedell from comment #61)
> (In reply to Nate Graham from comment #57)
> If it's typically from built-in-source sessions, would it be of any use me
> making a report for it? I'm using solely the Fedora 41 RPMs.

If you haven't built Plasma from source, then your issue is caused by a local setup issue or else a distro packaging issue. Either way, let's stop spamming this bug report with it, since 54 people are subscribed and they probably aren't interested in getting emails about unrelated issues.

KMail has its own account system not connected to this, so connection issues there are not related.

Please take any discussion of login issues in KMail elsewhere. Thanks.

*** Bug 499725 has been marked as a duplicate of this bug. ***

(In reply to Camilo Bohórquez from comment #70)
> Please re-open... The issue stills with signon-ui 0.17.
> 
> My System is Ubuntu Studio 24.04.2 LTS with KDE Plasma 5.27.12.

The code changes mentioned in https://bugs.kde.org/show_bug.cgi?id=480779#c54 would need to be adopted in some way by the Ubuntu Studio / Kubuntu folks downstream for this change to be included in those long-term support versions.

*** Bug 500807 has been marked as a duplicate of this bug. ***

*** Bug 500918 has been marked as a duplicate of this bug. ***

*** Bug 501626 has been marked as a duplicate of this bug. ***

(In reply to Nate Graham from comment #54)
> Google blocked us from using this back in June because we weren't able
> justify our API usage to their satisfaction. As such, the permission is
> now blocked, and including it here prevents people from logging into

So if I understand correctly it is no longer an option either to create a personal oauth token, as I once did when the KDE one had expired?

It's beyond stupid (IMHO) if individual users can't indicate that they're fine with a particular piece of software accessing their supposedly sensitive data!

I agree that KDE shouldn't impersonate Gnome, but we *could* list the applications & components that need to be installed in order to have a working alternative to accessing GDrive via the browser?

Heck, maybe someone could write an adapter that allows *using* the Gnome component from KDE applications, instead of impersonating it?

*** Bug 508150 has been marked as a duplicate of this bug. ***

*** Bug 391186 has been marked as a duplicate of this bug. ***

(In reply to Antonio Rojas from comment #79)
> *** Bug 508150 has been marked as a duplicate of this bug. ***

Why? This bug report is marked as "closed fixed", even though nothing is fixed since obviously almost 2 years. Is it normal that such a small problem cannot be fixed for so long?

A Google Drive file browser like is essential and even an official part of Endeavour KDE.

As mentioned in my fresh "duplicate" bug report from yesterday, I could connect my Google accounts without any problem (authenticating the "app" via my phone, and without any errors within my Google accounts). Just no files are shown within Dolphin ("access denied").

So is there another bug report that's still opened and where my bug report from yesterday would belong better than here in this very old and already closed bug report?

(In reply to Mulder from comment #81)
> Why? This bug report is marked as "closed fixed", even though nothing is
> fixed since obviously almost 2 years. Is it normal that such a small problem
> cannot be fixed for so long?
> 
> A Google Drive file browser like is essential and even an official part of
> Endeavour KDE.

Unfortunately, KDE's hands are tied here. It's necessary for any software that wants to integrate Google Drive to use Google's API to do so. Google controls access to that, and if they deny us access they deny us. We did discuss this with them, and pushed hard to justify our use, but they still refused us. We will probably try to petition them again in the future, but there are no guarantees they will be more amenable than last time.

In the meantime, what might get Google to listen is for users like yourself who are negatively affected by their decision to speak up. Call them out on social media. Contact their support channels. Make noise. If they can be convinced to allow us the necessary code access, we would be able to take a look at re-enabling this integration.

An alternative for affected folks for now might be rclone, for which there are UIs available:
https://rclone.org/

(In reply to TraceyC from comment #82)
> (In reply to Mulder from comment #81)
> > Why? This bug report is marked as "closed fixed", even though nothing is
> > fixed since obviously almost 2 years. Is it normal that such a small problem
> > cannot be fixed for so long?
> > 
> > A Google Drive file browser like is essential and even an official part of
> > Endeavour KDE.
> 
> Unfortunately, KDE's hands are tied here. It's necessary for any software
> that wants to integrate Google Drive to use Google's API to do so. Google
> controls access to that, and if they deny us access they deny us. We did
> discuss this with them, and pushed hard to justify our use, but they still
> refused us. We will probably try to petition them again in the future, but
> there are no guarantees they will be more amenable than last time.
> 
> In the meantime, what might get Google to listen is for users like yourself
> who are negatively affected by their decision to speak up. Call them out on
> social media. Contact their support channels. Make noise. If they can be
> convinced to allow us the necessary code access, we would be able to take a
> look at re-enabling this integration.
> 
> An alternative for affected folks for now might be rclone, for which there
> are UIs available:
> https://rclone.org/

Thank you very much for the explanation, Tracey!

Here some feedback from a fresh EndeavourOS (and the Google Drive tool recommended by Endeavour):

Until your explanation, I wouldn't have understood that this is seemingly mainly a "political" issue, as forum discussion were mainly around authentication.

If it's a political thing, maybe you should note that right away (on the tool recommendation page). I'm sure users would be on your side, but if they don't know the background, they'll simply be frustrated by the tool and maybe leave EndeavourOS (or KDE) completely.

I'm still not sure what happened, but it sounds like another unfair market behaviour by one of the Goliath companies out there. Maybe Google wants to slow down Linux and foster its own OS, so maybe that's even a case for competition law (as the EU is quite after the big ones).

Google is a "gatekeeper", and if their tools can't be used, it's hard to use Linux. Rclone for instance "is a command-line program" - if you work with files on an online storage like Google Drive, a command line program is no practical alternative. You need to be able to simple open and later on save a file, without having to care about synchronization.

And I also don't get why programs like Insync and Rclone seem to work, and your tool not? Do they know someone personally at Google? ;)

Pd: I'm a business user of Google Drive, so what I can do is ask the support for a solution and see what excuse they come up with... they want more money every year, so they should also make it possible to use one of the most popular Linuxes (now that Windows 10 is coming to an end for too many).

FWIW, the status of this issue should probably be CLOSED/UPSTREAM rather than CLOSED/FIXED !

(In reply to Mulder from comment #83)
> tool recommendation page). I'm sure users would be on your side, but if they
> don't know the background, they'll simply be frustrated by the tool and
> maybe leave EndeavourOS (or KDE) completely.

> Maybe Google wants to
> slow down Linux and foster its own OS

No - and which OS, Android or CrOS? Both are Linux derivatives...

Gnome have a working whatever-they-call-it in Nautilus and I'm sure there must be an Electron+NodeJS based "app"  that might even integrate better with various DEs than the regular web browser interface, if you don't want to or cannot use Gnome.

(I could, but not anymore because I appear to have lost [access to?] my Gnome keyring...)

(In reply to RJVB from comment #85)
> FWIW, the status of this issue should probably be CLOSED/UPSTREAM rather
> than CLOSED/FIXED !
> 
> (In reply to Mulder from comment #83)
> > tool recommendation page). I'm sure users would be on your side, but if they
> > don't know the background, they'll simply be frustrated by the tool and
> > maybe leave EndeavourOS (or KDE) completely.
> 
> > Maybe Google wants to
> > slow down Linux and foster its own OS
> 
> No - and which OS, Android or CrOS? Both are Linux derivatives...
> 
> Gnome have a working whatever-they-call-it in Nautilus and I'm sure there
> must be an Electron+NodeJS based "app"  that might even integrate better
> with various DEs than the regular web browser interface, if you don't want
> to or cannot use Gnome.
> 
> (I could, but not anymore because I appear to have lost [access to?] my
> Gnome keyring...)

Here's my conclusion after having spent several hours trying to find a solution:

- I'll not mess around with the google.provider file anymore that's generated by KIO GDrive
- I'll wait for an official Google Drive sync program for Linux (like the good one from Windows)
- I'll also wait for KIO GDrive to solve to problem (or any other free open source replacement for Google Drive for Windows)
- Meanwhile, I'll have to boot Windows when I have to work with many different files and formats on my Google Drives

Here's why:

- The workaround with replacing the client ID within the google.provider file isn't working anymore ("App blocked")
- Also, setting up my own Google auth client was too complicated (as the app would have to be reviewed for Drive access)
- The web version of Google Drive (which logically can be used in a browser on Linux) is not suitable for working with different files and formats (therefore an easy synchronizing solution like the official Google Drive sync app for Windows is needed)
- Rclone is way too complicated and after reading about it, I think it cannot even sync files automatically (seems you have to individually download and upload files using commands - that's even more complicated than using the Google Drive web version)
- Insync could potentially work, but I'm not in favor of paying for every small program. That's too much administration and spendings summing up in the end (I see this more of an option for a bigger company switching several computers to Linux)

Here's my suggested "interim solution" for KDE developers:

- Don't officially recommend KIO Gdrive to users (like here, where I also found it: https://discovery.endeavouros.com/applications/kde-plasma/2024/09/) - you'll save users like me a lot of time and frustration, and we're less likely to mess up the system with dubious workarounds (they're never a good solution in the longer run, not even on Linux)

- Instead, add an honest explanation why there's currently no official easy solution, or links to currently (easily) working tools (with pros & cons, like mine above), like Insync or Google Drive browser version

- Get rid of workarounds in top positions on Google that are not working anymore (by either deleting them, or by adding a warning at the top), like the most popular one that suggested changing to a Gnome-ID and key in the google.provider file

- It would be cool to have a "crossover"-Linux open source replacement for the official Google Drive desktop app for Windows (like Insync, but really open source and free, so that everyone can use it). It should not only be able to individually download and upload files, though, but to automatically sync them and show them within a cache (whereby cache size should be able to be limited, like in the official Google Drive app)

Hope this helps other users and to potentially foster the ease of use and popularity of Endeavour / KDE.

The official app for MSWin doesn't work under Wine, by any chance?

(In reply to RJVB from comment #87)
> The official app for MSWin doesn't work under Wine, by any chance?

A better place to ask about workarounds and alternatives are on the forums:
[https://discuss.kde.org/c/help/6](https://discuss.kde.org/c/help/6)

The bug tracker isn't intended for conversations unrelated to fixing the bug. Thanks for your understanding.