Bug 2054473 - unable to access google drive, Invalid credentials
Summary: unable to access google drive, Invalid credentials
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: gnome-online-accounts
Version: 36
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: GNOME SIG Unassigned
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: RejectedBlocker AcceptedFreezeException
Depends On:
Blocks: F36BetaFreezeException
TreeView+ depends on / blocked
 
Reported: 2022-02-15 02:19 UTC by Chris Murphy
Modified: 2023-05-25 16:41 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2023-05-25 16:41:28 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
GNOME Gitlab GNOME gnome-online-accounts issues 190 0 None None None 2022-02-16 08:14:41 UTC

Description Chris Murphy 2022-02-15 02:19:27 UTC
Description of problem:

Click on google drive icon in Files and I get an error. Works OK in Fedora 35.

Version-Release number of selected component (if applicable):
gvfs-1.49.1-2.fc36
AND
gvfs-1.49.90-1.fc36.x86_64

How reproducible:
Always

Steps to Reproduce:
1. click on google drive icon in Files
2.
3.

Actual results:

Unable to access
Invalid credentials


Expected results:

I should see my files

Additional info:

This is an upgrade from Fedora 35 to Fedora 36, Workstation edition. Clean install root, preserving /home.

Comment 1 Fedora Blocker Bugs Application 2022-02-15 03:31:32 UTC
Proposed as a Blocker for 36-final by Fedora user chrismurphy using the blocker tracking app because:

 All applications that can be launched using the standard graphical mechanism after a default installation of Fedora Workstation on the x86_64 architecture must start successfully and withstand a basic functionality test. 
https://fedoraproject.org/wiki/Fedora_35_Final_Release_Criteria#Default_application_functionality

Comment 2 Ondrej Holy 2022-02-15 14:21:03 UTC
Just a note that this is not an upgrade from Fedora 35, nor a fully clean Fedora 36 installation as the home partition was preserved, so I suppose this is not a blocker bug, rather a "configuration" issue caused by restoring the home directory. Trying to find out more info about it over the upstream issue though.

Comment 3 Adam Williamson 2022-02-15 17:55:03 UTC
If it doesn't happen on a clean install or an actual upgrade it's not a blocker, no. We don't cover this scenario in the criteria.

Comment 4 Chris Murphy 2022-02-16 02:26:11 UTC
I'll do a dnf system-upgrade from 35 to 36, but I'm running into bug 2054921. But if the google account works following system-upgrade, doesn't it suggest something related tothe user google account is stored outside of ~/?

Comment 5 Chris Murphy 2022-02-16 03:04:42 UTC
Problem remains with an in place system upgrade.

Feb 15 20:03:25 fovo.local systemd[1670]: Started app-gnome-org.gnome.Nautilus-0.scope - Application launched by gnome-shell.
Feb 15 20:03:25 fovo.local nautilus[2677]: gtk_stack_get_child_by_name: assertion 'GTK_IS_STACK (stack)' failed
Feb 15 20:03:25 fovo.local nautilus[2677]: ../gobject/gsignal.c:2653: instance '0x7fbd28263ba0' has no handler with id '2305'
Feb 15 20:03:25 fovo.local nautilus[2677]: ../gobject/gsignal.c:2695: instance '0x7fbd28263ba0' has no handler with id '2305'
Feb 15 20:03:25 fovo.local nautilus[2677]: ../gobject/gsignal.c:2653: instance '0x7fbd28263ba0' has no handler with id '2305'
Feb 15 20:03:25 fovo.local nautilus[2677]: ../gobject/gsignal.c:2695: instance '0x7fbd28263ba0' has no handler with id '2305'
Feb 15 20:03:25 fovo.local nautilus[2677]: gtk_stack_get_child_by_name: assertion 'GTK_IS_STACK (stack)' failed
Feb 15 20:03:27 fovo.local goa-daemon[1952]: secret_password_lookup_sync() returned NULL
Feb 15 20:03:28 fovo.local goa-daemon[1952]: secret_password_lookup_sync() returned NULL
Feb 15 20:03:28 fovo.local goa-daemon[1952]: secret_password_lookup_sync() returned NULL
Feb 15 20:03:28 fovo.local gnome-calendar[2671]: source_credentials_required_cb: Failed to authenticate 'Holidays in United States': Failed to obtain an access token for “Holidays in United States”: No credentials found in the keyring
Feb 15 20:03:28 fovo.local gnome-calendar[2671]: source_credentials_required_cb: Failed to authenticate 'chris': Failed to obtain an access token for “chris”: No credentials found in the keyring
Feb 15 20:03:28 fovo.local gnome-calendar[2671]: source_credentials_required_cb: Failed to authenticate 'Contacts': Failed to obtain an access token for “Contacts”: No credentials found in the keyring
Feb 15 20:03:30 fovo.local systemd[1670]: tracker-extract-3.service: Consumed 4.814s CPU time.
Feb 15 20:03:35 fovo.local gnome-shell[1803]: Object 0x7f6684065cb0 of type IBusText has been finalized while it was still owned by gjs, this is due to invalid memory management.
Feb 15 20:03:40 fovo.local systemd[1]: systemd-localed.service: Deactivated successfully.

Comment 6 Chris Murphy 2022-02-16 03:16:05 UTC
As mentioned in the upstream bug, functionality is restored by reauthenticating the account in the Online Accounts panel. While a little suboptimal for the functionality to be lost on upgrade, requiring reauthenticating the account to restore that functionality is probably not goint to pass the "last blocker" test. cc: mcatanzaro for another opinion.

Comment 7 Ondrej Holy 2022-02-16 07:22:25 UTC
Not sure why GOA can't access the credentials after an upgrade, but anyway this is not a GVfs bug, thus moving to GOA to see whether something can be improved there. A re-authentication is common and has to be done also in other scenarios, not only upgrades, so I suppose this should not be a blocker. But it would be nice at least to show a notification when a certain Online Account needs attention (https://gitlab.gnome.org/GNOME/gnome-online-accounts/-/issues/190).

Comment 8 Geoffrey Marr 2022-02-21 16:27:47 UTC
The decision to classify this bug as a "RejectedBlocker (Final)" and an "AcceptedFreezeException (Beta)" was made based off voting here: [0]

[0] https://pagure.io/fedora-qa/blocker-review/issue/608

Comment 9 Ben Cotton 2023-04-25 16:54:02 UTC
This message is a reminder that Fedora Linux 36 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora Linux 36 on 2023-05-16.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
'version' of '36'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, change the 'version' 
to a later Fedora Linux version. Note that the version field may be hidden.
Click the "Show advanced fields" button if you do not see it.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora Linux 36 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora Linux, you are encouraged to change the 'version' to a later version
prior to this bug being closed.

Comment 10 Ludek Smid 2023-05-25 16:41:28 UTC
Fedora Linux 36 entered end-of-life (EOL) status on 2023-05-16.

Fedora Linux 36 is no longer maintained, which means that it
will not receive any further security or bug fix updates. As a result we
are closing this bug.

If you can reproduce this bug against a currently maintained version of Fedora Linux
please feel free to reopen this bug against that version. Note that the version
field may be hidden. Click the "Show advanced fields" button if you do not see
the version field.

If you are unable to reopen this bug, please file a new report against an
active release.

Thank you for reporting this bug and we are sorry it could not be fixed.


Note You need to log in before you can comment on or make changes to this bug.