KDE Online Accounts - Not Signing In

Hi all, I found this problem was solved with Fedora39!
(Or 28 also with new update? I don’t know…)

Hi all, I installed KDE 6.0 and this happens again, I can’t create an online account, and having the same message.
If you can try without @gmail.com, as I was able to map it, even though Dolphin does not show the mapped drive.

1 Like

Try to log in pressing blue buttons with your mouse.
When I use only the keyboard, the auth. fail, complaining about an unsecure browser blah blah…
When I gently click the big blue buttons to validate, its ok.
I can reach my gdrive trough dolphin, even its buggy AF.

2 Likes

Struggling with the same issue with KDE Neon. This is defietively a KDE bug, as the Gnome distros don`t have problem to connect to google account
at all.

That advice actually worked. I am on latest arch:

local/signon-kwallet-extension 24.02.2-1 (kde-applications kde-network)
    KWallet integration for signon framework
local/signon-plugin-oauth2 0.25-3
    OAuth 2 plugin for signon
local/signon-ui 0.17+20231016-2
    UI component responsible for handling the user interactions which can happen during the login process of
    an online account
local/signond 8.61-3
    A D-Bus service which performs user authentication on behalf of its clients

I managed to complete the sign-in process on Kubuntu 24.04 by right clicking the window background and selecting “reload” at the point where it appears to hang. Doing that gives an updated window where it’s waiting for you to complete the 2FA with a security key (which I never got to work), but there’s a button to “try another way” that then allows logging in with other 2FA methods.

However, when trying to access gdrive:/ I now get

[1482353.987091] kioslave5[1598827]: segfault at 0 ip 0000741858b0a9e4 sp 00007fff48635698 error 4 in libKPim5GAPIDrive.so.5.24.5[741858b06000+46000] likely on CPU 6 (core 12, socket 0)
[1482353.987100] Code: 05 06 00 48 89 de 48 8d 15 39 06 06 00 e8 44 cc ff ff 4c 89 e7 e8 5c c8 ff ff 48 89 d8 5b 41 5c 5d c3 0f 1f 40 00 f3 0f 1e fa <8b> 07 31 d2 85 c0 74 0a 83 f8 ff 75 0f ba 01 00 00 00 89 d0 c3 0f

in dmesg. My libkpim5gapidrive5 version is 23.08.5-0ubuntu3.

Same problem here with up-to-date KDE Neon (user edition).
After many attempts I was able to enter the google credentials (by pressing TAB to nagivate, when the blue button is highlighted, press ENTER); but then the connection fails anyways. Opening dolphin from the terminal I get

  $ dolphin 
"Failed to I/O session data to/from the signon daemon."
kf.kio.workers.gdrive: GetCredentialsJob failed: "Failed to I/O session data to/from the signon daemon."
qt.network.http2: connection error: GOAWAY invalid stream/error code

Hi, since the issue happens with KDE Neon, it’s not clear to me that this is not KDE related.

I tried again from another network (home) and now here is what I get
``$ `dolphin
org.kde.kgapi: Bad request, Google replied ’ “{\n "error": {\n "code": 400,\n "message": "Invalid field selection etag,kind,nextLink,nextPageToken,selfLink,items(,labels,exportLinks,lastViewedByMeDate,alternateLink,kind)",\n "errors": [\n {\n "message": "Invalid field selection etag,kind,nextLink,nextPageToken,selfLink,items(,labels,exportLinks,lastViewedByMeDate,alternateLink,kind)",\n "domain": "global",\n "reason": "invalidParameter",\n "location": "fields",\n "locationType": "parameter"\n }\n ]\n }\n}\n” ’
kf.kio.core: UDSEntry for ‘.’ not found, creating a default one. Please fix the “kio_gdrive” KIO worker.

Same as for kulak above. This solution actually works on up to date manjaro. It fails seemingly randomly though but after a few attempts I can get it to work.

Clearly this is not due to an outdated signon-ui package as the accepted answer says. Looks more like bug id=480779 (I am not allowed to include a link…)

local/signon-kwallet-extension 24.05.2-1 (kde-applications kde-network)
    KWallet integration for signon framework
local/signon-plugin-oauth2 0.25-3
    OAuth 2 plugin for signon
local/signon-ui 0.17+20231016-2
    UI component responsible for handling the user interactions which can happen during the login process of an online account
local/signond 8.61-3
    A D-Bus service which performs user authentication on behalf of its clients

I had the same issue trying to get this running on Garuda linux / Arch KDE. I got the same ‘Authentication’ error but got it to work, after I tried to update KIO again in the terminal. (It updated the app but showed the same version number, for whatever reason.) After that, I was able to login to my Gdrive and works fine now! Maybe some weird bug or something? I really don’t know.

Could any report what the console outputs when reproducing the issue, when launching dolphin with command:

QT_LOGGING_RULES=org.kde.kgapi.debug=true dolphin

This has been going on since at least 2020 when I first ran into it, but I was not the first one to post the bug. KDE devs blame someone else, whoever else blames the KDE devs. They say its fixed upstream. Its totally ludicrous. KDE is a great GUI, but seriously… This feature works in every other GUI on every other GNU/Linux distro. They take away Dolphin root capabilities because its “dangerous” which made a pile of people mad, but they cant fix this issue over a 4+ year period. Just so things are clear. Using a loaded cocked firearm as a yard stick is “dangerous”. Inadvertently destroying your OS because some person used Dolphin as root, causing a reinstall is not “dangerous”. I love Linux, am passionate about it, I love GNU and Open Source but sometimes the tens of thousands or maybe millions of global volenteers that make GNU/Linux and all the things that go along with it like for example KDE really do some stupid stuff and are like a bunch of children when it comes to certain things. As far as this accounts sign on issue, you all might as well just give up on it. Whoever is at fault isn’t fixing it. No one else is fixing it, and after at minimum 4 or 5 or maybe even more years it just adds another reason to the list of why people tend to gravitate back to paid OS’s like Windows and MAC. Some stuff just doesn’t work and never will because there’s always a blame game going on amongst all the devs. Idiotic…

I am using KDE Neon Plasma 6 and I managed to sign on to my Google account by just using my email address WITOUT @gmail.com.

I have three installations of Fedora 41, the two with Kinoite both have no problem when signing into Online Accounts with Google credentials.

My other fresh installation of F41 with KDE, does have a problem when signing into Google through Online Accounts

I have not yet been able to workout why Kinoite works and my normal installation does not.

I will keep on looking.

The same thing is happening to me on a fresh Endeavour OS install…
Three or four days ago, it worked on another fresh Endeavour OS install from the very same ISO.
My only guess is that Google changed something very recently…?

Edit: KDE, of course.

I’m also seeing this on the latest Bazzite KDE (Fedora Atomic with extra stuff)

1 There is a problem that has been reported by users of Arch and derived distributions. Before entering the password, the user goes to a screen that says: This browser or app is not secure.

This problem is in a patch called fake-user-agent.patch in the signon-ui package. It is not a Plasma problem, but I had not found information about the cause of the error anywhere. Repackaging without the patch makes this error disappear.

2 - The second error probably occurs in all distributions. In the last 2 days I tested the following distributions: BigLinux, Manjaro, Fedora, KDE Neon, OpenSuse and Solus. The error occurred in all of them.

The error occurs after entering the password: This app is blocked

The problem is in parts of the file: /usr/share/accounts/providers/kde/google.provider

If you remove the line with the content: https://www.googleapis.com/auth/drive

The problem does not occur, the account is added, but there is no way to access or send files to Google Drive, if you replace it with this other line, then it is possible to send files, but not access the files that were already in Google Drive: 'https://www.googleapis.com/auth/drive.file',

I did hundreds of tests and modifications until I got to the point where I went to see how it was being done in Gnome, so I adapted the google.provider file to use the data used in Gnome and it worked, Google Drive became fully functional.

The real problem seems to be in the ClientID used in kaccounts-providers: 317066460457-pkpkedrvt2ldq6g2hj1egfka2n7vpuoo.apps.googleusercontent.com

The Google Provider file using the Gnome ClientID ( /usr/share/accounts/providers/kde/google.provider ):

<?xml version="1.0" encoding="UTF-8"?>
<provider id="google">
  <name>Google</name>
  
  <description>GNOME-ID, Google Drive and YouTube</description>
  <icon>im-google</icon>
  <translations>kaccounts-providers</translations>
  <domains>.*google\.com</domains>

  <template>
    <group name="auth">
      <setting name="method">oauth2</setting>
      <setting name="mechanism">web_server</setting>
      <group name="oauth2">
        <group name="web_server">
          <setting name="Host">accounts.google.com</setting>
          <setting name="AuthPath">o/oauth2/auth?access_type=offline</setting>
          <setting name="TokenPath">o/oauth2/token</setting>
          <setting name="RedirectUri">http://localhost/oauth2callback</setting>
          
          <setting name="ResponseType">code</setting>
          <setting type="as" name="Scope">[
              'https://www.googleapis.com/auth/userinfo.email',
              'https://www.googleapis.com/auth/userinfo.profile',
              'https://www.googleapis.com/auth/calendar',
              'https://www.googleapis.com/auth/tasks',
              'https://www.googleapis.com/auth/drive'
          ]</setting>
          <setting type="as" name="AllowedSchemes">['https']</setting>
          <setting name="ClientId">44438659992-7kgjeitenc16ssihbtdjbgguch7ju55s.apps.googleusercontent.com</setting>
          <setting name="ClientSecret">-gMLuQyDiI0XrQS_vx_mhuYF</setting>
          <setting type="b" name="ForceClientAuthViaRequestBody">true</setting>
        </group>
      </group>
    </group>
  </template>
</provider>

10 Likes

Thanks a lot! Using the Gnome ClientID indeed solved the issue!

1 Like

Thanks, this fixes it for me too on KDE Manjaro.

1 Like