Desktop: nextcloud does not attempt to unlock the gnome keyring on startup

[vberger]

I'm running Gentoo, with the following versions of packages:

• nextcloud-client 2.3.3
• qtkeychain 0.8.0
• lignome-keyring 3.12.0
• gnome-keyring 3.20.1

Since my last system update, on startup of nextcloud-client I no longer get a popup prompting me for the password of my keyring, instead nextcloud-client directly prompts me for an app password. If I create a new one and enter it, then I am prompted for the password to unlock my keyring so that nextcloud can store it.

On the other hand, if I unlock the keyring beforehand (using seahorse for example) and start nextcloud afterwards, then it directly connects without prompting me for an app password.

[rullzer]

This should be fixed in master I believe.

[gerhardbeck]

snap connect nextcloud-client:password-manager-service might solve the problem when installed via snap

[ogasser]

I can confirm that this also happens for Arch Linux with the following package versions:

• nextcloud-client 2.3.3
• qtkeychain 0.9.0
• libgnome-keyring 3.12.0
• gnome-keyring 3.28.2

Manually unlocking the keyring before starting nextcloud works as a workaround.

[jancborchardt]

@rullzer @camilasan when is the next release scheduled which would include the fix? :)

[Eluminae]

Until the next release, how do you manually unlock gnome keyring ?

[vberger]

@Eluminae Personally I'm using seahorse

[bpcurse]

Confirmed with Manjaro Linux:

• nextcloud-client 2.3.3
• qtkeychain 0.9.0-1
• libgnome-keyring 3.12.0-3
• gnome-keyring 3.28.2-1

Unlocking the keyring with seahorse prior to opening the client helps as described above.

[camilasan]

Hi All :) Could you try one of the daily builds?
https://download.nextcloud.com/desktop/daily/Linux/
As @rullzer said this should be fixed in master.

[bpcurse]

@camilasan
Thank you for proposing the daily builds. The issue is gone in my setup with 2.5.0.20180730 (tried only the latest)

[camilasan]

@bpcurse Just be aware that this is for testing, built from master. We should have a release soon..
but good to know it is fixed.

[jamfx]

I can confitm this bug on latest Linux Mint Cinnamon with deb-package (not Snap).

[mase76]

On my system (Debian Buster) the gnome-keyring is unlocked with pam. But nc seems
not to find the service. I log into my account, permit access, and with the next start, the login
is forgotten. Maybe a problem with libqt5keychain1.

[anders-larsson]

Hi. It appears I might have this issue as well. It doesn't appear Nextcloud is able to retrieved the saved password and returns "Unknown Error" . Other applications does not appear to have any problems retrieving passwords from gnome-keyring.

Tried to enable logging and this is the result. I'm not sure if it's of much use though. If there is anything else I can do to get more information to resolve this issue please tell me.

10-10 18:23:47:493 20014 OCC::ConnectionValidator::setAndCheckServerVersion: QUrl("https://<fqdn>") has server versioni"14.0.1.1"descheduling sync folders
10-10 18:23:47:493 20014 OCC::AccountState::slotConnectionValidatorResult: AccountState connection status change:  "Undefined" -> "Credentials Wrong"
10-10 18:23:47:493 20014 OCC::HttpCredentials::fetchFromKeychain: -------- -----> QSslCertificate("", "", "<string>", (), (), QMap(), QDateTime(Invalid), QDateTime(Invalid)) QSslKey(PrivateKey, OPAQUE, -1)
10-10 18:23:47:493 20014 OCC::AccountState::setState: AccountState state change:  "Disconnected" -> "Configuration error"
10-10 18:23:47:493 20014 OCC::FolderMan::slotAccountStateChanged: Account "<user>@<fqdn>" disconnected or paused, terminating or descheduling sync folders
10-10 18:23:50:548 20014 OCC::PassiveUpdateNotifier::backgroundCheckForUpdate: virtual void OCC::PassiveUpdateNotifier::backgroundCheckForUpdate()
10-10 18:23:50:548 20014 OCC::OCUpdater::backgroundCheckForUpdate: virtual void OCC::OCUpdater::backgroundCheckForUpdate() checking for available update
10-10 18:23:50:688 20014 OCC::PassiveUpdateNotifier::versionInfoArrived: Client is on latest version!
10-10 18:26:29:341 20014 OCC::AccountState::setState: AccountState state change:  "Configuration error" -> "Signed out"
10-10 18:26:29:341 20014 OCC::FolderMan::slotAccountStateChanged: Account "<user>@<fqdn>" disconnected or paused, terminating or descheduling sync folders
10-10 18:26:33:736 20014 unknown: QString::arg: Argument missing: "https://docs.nextcloud.com/desktop/2.2/" , 2
10-10 18:26:33:736 20014 unknown: QString::arg: Argument missing: "https://docs.nextcloud.com/desktop/2.2/" , 3

Nextcloud: 2.3.3
qtkeychain: 0.9.0

[vberger]

This still reproduces with nextcloud 2.5.1 (with qtkeychain 0.9.0).

[ericzolf]

Wouldn't this issue be addressed by solving issues #883 resp. #990 i.e. make sure nextcloud-client uses libsecret instead of libgnome-keyring?

[elbaulp]

Hello,

I am using Gentoo and I am facing the same error. Nextcloud-client seems to not remember credentials. I am not using an appimage, I am installing directly from portage.

I am running Nextcloud-client 2.5.1

This is the log I am seeing:

[OCC::WebFlowCredentials::fetchFromKeychain     Fetch from keyhchain!
[OCC::AccountState::slotCredentialsFetched  Fetched credentials for "https://nc-cluster02.yourownnet.cloud" attempting to connect
[OCC::WebFlowCredentials::createQNAM    Get QNAM
[OCC::ConnectionValidator::systemProxyLookupDone    No system proxy set by OS
[OCC::AccessManager::createRequest  2 "" "https://nc-cluster02.yourownnet.cloud/status.php" has X-Request-ID "......."
[OCC::AbstractNetworkJob::start     OCC::CheckServerJob created for "https://nc-cluster02.yourownnet.cloud" + "status.php" "OCC::ConnectionValidator"
[OCC::WebFlowCredentials::slotFinished  request finished
[OCC::WebFlowCredentials::stillValid    Still valid?
[OCC::WebFlowCredentials::stillValid    QNetworkReply::NetworkError(NoError)
[OCC::WebFlowCredentials::stillValid    "Unknown error"
[OCC::CheckServerJob::finished  No SSL session identifier / session ticket is used, this might impact sync performance negatively.
[OCC::CheckServerJob::finished  status.php returns:  QJsonDocument({"edition":"","installed":true,"maintenance":false,"needsDbUpgrade":false,"productname":"Your Own Net / Open IT Store - Shared 02","version":"14.0.6.0","versionstring":"14.0.6"})   QNetworkReply::NetworkError(NoError)  Reply:  QNetworkReplyHttpImpl(0x55e75f08a110)
[OCC::ConnectionValidator::slotStatusFound  ** Application: ownCloud found:  QUrl("https://nc-cluster02.yourownnet.cloud")  with version  "14.0.6" ( "14.0.6.0" )
[OCC::ConnectionValidator::setAndCheckServerVersion     QUrl("https://nc-cluster02.yourownnet.cloud") has server version "14.0.6.0"
[OCC::AccountState::slotConnectionValidatorResult   AccountState connection status change:  OCC::ConnectionValidator::Status(Undefined) -> OCC::ConnectionValidator::Status(CredentialsNotReady)
[OCC::AccountState::slotInvalidCredentials  Invalid credentials for "https://nc-cluster02.yourownnet.cloud" asking user
[OCC::AccountState::setState    AccountState state change:  "Disconnected" -> "Asking Credentials"
[OCC::FolderMan::slotAccountStateChanged    Account "**********" disconnected or paused, terminating or descheduling sync folders
[OCC::WebFlowCredentials::askFromUser   User needs to reauth!

I have gnome-keyring, and it's working for skype, for example.

[srgcdev]

I am using Fedora 29 and I have the same error. Nextcloud-client seems to not remember credentials. I am installing directly from fedora repository.
The version is Nextcloud-client 2.3.3.

I have tested nextcloud in the new fedora 30 beta too and I have the same problem.
In fedora 30 the version is Nextcloud-client 2.5.1.

In ubuntu 18.04 is working well. I have installed Nextcloud-client from this ppa: https://launchpad.net/~nextcloud-devs/+archive/ubuntu/client
Current version is 2.5.2, but with 2.5.1 was working well at all.

Any ideas why in ubuntu 18.04 is working properly and the rest of distribution is not?

[Eluminae]

Probably a missing dependency. Have a look at : https://wiki.archlinux.org/index.php/GNOME/Keyring

[elbaulp]

@Eluminae I dont think it is a dependency problem. The keyring is working properly for other programs, like skype.

[Eluminae]

does the default login keychain is unlocked at login ?

[srgcdev]

Yes, the default login keychain is unlocked at login and is working properly for other applications.
In fact, there is no entry for nextcloud in the keyring in fedora but in Ubuntu there is and works well.

El 25 de marzo de 2019 11:42:36 CET, Eddie Barraco [e-mail] escribió:

does the default login keychain is unlocked at login ?

--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/nextcloud/desktop/issues/427#issuecomment-476141420

[Eluminae]

All programs doesn't use the same dependencies to access the gnome keyring like the archlinux doc says.
I don't have any other ideas atm.

[srgcdev]

In the case of fedora 29 and 30, seems is not installed the deprecated package libgnome-keyring. Installing this package solves the issue.
Thanks @Eluminae

[rugk]

Indeed, on Fedora a dnf install libgnome-keyring should solve this.

Actually, this has also been reported to the downstream (package maintainer of Fedora), but no one has reacted there. After all, they just need to include this as a dependency.
So if you are affected by this, feel free to comment there…

[icf20]

on manjaro having libgnome-keyring installed does nothing, nextcloud still ask for login every time

[lockejan]

Indeed, on Fedora a dnf install libgnome-keyring should solve this.

Actually, this has also been reported to the downstream (package maintainer of Fedora), but no one has reacted there. After all, they just need to include this as a dependency.
So if you are affected by this, feel free to comment there…

@rugk I installed libgnome-keyring under fedora30 but the issue still persists. Are there any additional hacks included to bring it in a working state? I did a restart afterwards, just for the protocol. (:

EDIT: Turned out that a second login/logout respective restart was necessary in my case. Thanks for the hint. It finally works :+1:

[juliushaertl]

The client uses qtkeychain which is already capable of using libsecret. So this is most likely a packaging issue of the fedora version.

[stale[bot]]

This request did not receive an update in the last 4 weeks. Please take a look again and update the issue with new details, otherwise the issue will be automatically closed in 2 weeks. Thank you!

[rugk]

no new details needed

[juliushaertl]

Let's close this as it seems to be a packaging issue and a fix is proposed in https://src.fedoraproject.org/rpms/nextcloud-client/pull-request/2

[Germano0]

Let's close this as it seems to be a packaging issue and a fix is proposed in https://src.fedoraproject.org/rpms/nextcloud-client/pull-request/2

I rejected that PR due
https://bugzilla.redhat.com/show_bug.cgi?id=1652973#c1
You may want to reopen this ticket

[juliushaertl]

Sorry, I didn't look into the detailed issue discussions. As mentioned above we use qtkeychain which is fully capable of using libsecret. So pulling in that as a dependency should also work.

[rugk]

…or better open a new issue?

Because now, after only a little more than one year, we do know what was _actually_ causing/the reason for this? :thinking:

[elbaulp]

In gentoo is still not working. In fact, right now I am using an AppImage and it ask me to log in every time a boot the computer :-(

[claneys]

I can confirm that installing libgnome-keyring on fedora solve this issue for me on f29 and f30

[FredericLespez]

I have the same when I am using the official AppImage.
By looking at the code building the AppImage, I think the problem lies in the fact that the qtkeychain is built without libsecret support.
See here : https://github.com/nextcloud/client-building/blob/master/linux/build-appimage-daily.sh

The building code should first build and install libsecret, then build qtkeychain.

[FredericLespez]

I rebuild an AppImage by installing libsecret-1-dev before building qtkeychain.

The next part may be Debian specific :
Then I made a link from libsecret-1.so.0 to libsecret-1.so, as described here:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=920984#66

And now it works My AppImage start without asking me my password.
Hope it helps.

[misch7]

@FredericLespez Thanks for your research and work! 🚀

Regarding AppImage creation: I'll follow-up on this at your new dedicated issue: https://github.com/nextcloud/client-building/issues/13

Everyone interested in the AppImage please have a look there.

[misch7]

Hey @elbaulp and everyone,

I've implemented @FredericLespez's suggestion in a test build (preview AppImage):
https://download.nextcloud.com/desktop/prereleases/Linux/Nextcloud-2.6.0-Qt-5.12.5-20191016-preview-x86_64.AppImage

You may give it a try and feedback is appreciated, helps for the next fix release 😼

[elbaulp]

Thanks!, will try as soon as possible and let you know.

Bests
-- Alejandro Alcalde - elbauldelprogramador.com
http://elbauldelprogramador.com/en

On Wed, Oct 16, 2019 at 4:22 AM Michael Schuster [e-mail]
wrote:

Hey @elbaulp https://github.com/elbaulp and everyone,

I've implemented @FredericLespez https://github.com/FredericLespez's
suggestion in a test build (preview AppImage):

https://download.nextcloud.com/desktop/prereleases/Linux/Nextcloud-2.6.0-Qt-5.12.5-20191016-preview-x86_64.AppImage

You may give it a try and feedback is appreciated, helps for the next fix
release 😼

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/nextcloud/desktop/issues/427?email_source=notifications&email_token=AADAMLOYIFX2VMXICHXRNXTQOZ3EPA5CNFSM4FFLBVQ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBKZWQY#issuecomment-542481219,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AADAMLOYXQRTAXG62R7LD3LQOZ3EPANCNFSM4FFLBVQQ
.

[elbaulp]

Hey @elbaulp and everyone,

I've implemented @FredericLespez's suggestion in a test build (preview AppImage):
https://download.nextcloud.com/desktop/prereleases/Linux/Nextcloud-2.6.0-Qt-5.12.5-20191016-preview-x86_64.AppImage

You may give it a try and feedback is appreciated, helps for the next fix release smirk_cat

Ey!, it's seem to be working, on login it asked me the password to unlock the keyring, then I closed the application and open it again, and did not ask me again to log in.

Thanks very much!