nextcloud client no longer working #26774

manfredu · 2020-11-28T18:58:38Z

Since last update of qt5 libraries the nextcloud client no longer works for me. It just hangs during start up after output "[ unknown ]: static bool LibSecretKeyring::findPassword(const QString&, const QString&, QKeychain::JobPrivate)"

Complete log:

020-11-28 19:15:41:984 [ info nextcloud.gui.application ]: "################## Nextcloud locale:[de_DE] ui_la
ng:[] version:[3.0.3git] os:[void]"
2020-11-28 19:15:41:984 [ info nextcloud.gui.application ]: Using "de_DE" translation
2020-11-28 19:15:41:984 [ info nextcloud.gui.socketapi ]: server started, listening at "/tmp/.runtime-manfr
ed/Nextcloud/socket"
2020-11-28 19:15:41:984 [ info nextcloud.gui.folder.manager ]: setting remote poll timer interval to 30000 msec
2020-11-28 19:15:42:013 [ info nextcloud.gui.account.manager ]: Account for QUrl("https://xxx.domain") using auth type "webflow"
2020-11-28 19:15:42:013 [ info nextcloud.sync.credentials.webflow ]: Get QNAM
2020-11-28 19:15:42:014 [ info nextcloud.gui.account.manager ]: Account for QUrl("https://yyy.domain") using auth type "webflow"
2020-11-28 19:15:42:014 [ info nextcloud.sync.credentials.webflow ]: Get QNAM
2020-11-28 19:15:42:067 [ debug default ] [ unknown ]: static bool LibSecretKeyring::findPassword(const QString&, const QString&, QKeychain::JobPrivate)

System

xuname:
manfred|~> xuname nextcloud
Void 5.8.18_1 x86_64 GenuineIntel notuptodate rrFFFFF
package:
nextcloud-client-3.0.3_1

Expected behavior

Starts as usual and is available in the panel

Actual behavior

Nothing happens except output of message "unknown LibSecretKeyring::findPassword()"

Steps to reproduce the behavior

Update system and enter nextcloud in the terminal.

manfredu · 2020-11-28T19:22:40Z

I found a way to make it work manually, start nextcloud client as follows:

DESKTOP_SESSION=kde KDE_SESSION_VERSION=5 nextcloud

This was suggested in #26275.

What do I need to do to make autostart of nc client work again?

yopito · 2020-11-28T21:57:56Z

nc uses qtkeychain-qt5 to manage the storage of its secret.
qtkeychain-qt5's first choice is to use gnome-keyring as backend, except on KDE as DE.

I suppose that you were using gnome-keyring before upgrading.

Could you do the following steps and provides the results ?

exit nextcloud
stop any process related to gnome-keyring or kwallet (see output of ps -ef | grep -E "key|wallet" to find them)
launch nextcloud, it should fails as you're indicated
does gnome-keyring-daemon is running ?
do you have package gnome-keyring-3.36.0 installed ?
inspect content of gnome-keyring storage with GUI (package seahorse). keys for nextcloud are stored in "Password and Keys" > Default : entries "nextcloud*"
stop nextcloud
cleanup all key for nextcloud with seahorse
start again nextcloud : should requires a new authorization and store a new key in gnome-keyring if suceeded

manfredu · 2020-11-28T22:24:09Z

nc uses qtkeychain-qt5 to manage the storage of its secret.
qtkeychain-qt5's first choice is to use gnome-keyring as backend, except on KDE as DE.

I suppose that you were using gnome-keyring before upgrading.

No, I was using kwallet.

This was configured automatically, I just installed the nextcloud-client package

It was working finde until around two or three days ago. Probably by an update of qt5 packages (Including qtkeychain?).

Could you do the following steps and provides the results ?

exit nextcloud

Done.

stop any process related to gnome-keyring or kwallet (see output of ps -ef | grep -E "key|wallet" to find them)

manfred|~> ps -ef | grep -E "key|wallet"
manfred 8370 1 0 11:23 ? 00:00:00 /bin/sh /bin/xdg-open https://cgit.kde.org/signon-kwallet-extension.git/
manfred 8442 8370 2 11:23 ? 00:14:34 /bin/falkon https://cgit.kde.org/signon-kwallet-extension.git/
manfred 17018 1 0 11:24 ? 00:00:01 /usr/bin/kwalletd5
manfred 30487 17939 0 23:12 pts/2 00:00:00 grep -E key|wallet

launch nextcloud, it should fails as you're indicated

Yes, it does.

does gnome-keyring-daemon is running ?

No:

ps -ef | grep -E "key|wallet"
manfred 8370 1 0 11:23 ? 00:00:00 /bin/sh /bin/xdg-open https://cgit.kde.org/signon-kwallet-extension.git/
manfred 8442 8370 2 11:23 ? 00:14:35 /bin/falkon https://cgit.kde.org/signon-kwallet-extension.git/
manfred 17018 1 0 11:24 ? 00:00:01 /usr/bin/kwalletd5
manfred 32417 26499 0 23:16 pts/0 00:00:00 grep -E key|wallet

do you have package gnome-keyring-3.36.0 installed ?

No, no version of that package is installed.

inspect content of gnome-keyring storage with GUI (package seahorse). keys for nextcloud are stored in "Password and Keys" > Default : entries "nextcloud*"

Package seahorse now installed, no entries for nextcloud.
But KWalletManager shows entries for nextcloud. As expected, because when it was still working after every system start I was asked for the keyword / passphrase for kwallet...

stop nextcloud

Done.

cleanup all key for nextcloud with seahorse

Nothing to do.

start again nextcloud : should requires a new authorization and store a new key in gnome-keyring if suceeded

No, same error as before:

nextcloud
2020-11-28 23:23:29:444 [ debug default ] [ unknown ]: static bool LibSecretKeyring::findPassword(const QString&, const QString&, QKeychain::JobPrivate*)

manfredu · 2020-11-28T22:27:46Z

So you recommend to install the gnome-keyring package and the nextcloud client will use this then?

Ok. But if gnome-keyring is required it should be installed as a depency but the nextcloud-client package automatically, right?

Why does nc client not use kwallet when it is available und gnome-keyring not. It looks like it did before. Or an older version of qtkeychain did?

yopito · 2020-11-28T22:38:41Z

ah, I didn't know you were using kwallet, sorry for somehow useless diags.
I don't recommend gnome-keyring especially.
And runtime dep kwallet|gnome-keyring is for qtkeychain-qt5, that is weird from using nc's point of view.

I have to perform additional tests with kwallet, stay tuned

yopito · 2020-11-29T00:37:34Z

qtkeychain backend's choice is complex and does not match your context or mine. See detectKeyringBackend() in https://github.com/frankosterfeld/qtkeychain/blob/master/keychain_unix.cpp.
It also does not perform a real availability of backend, nor it let choose the order of detection/choice.

I fail to use kwallet OOTB with nextcloud-client here, with fluxbox DE and libresecret installed (required by other packages).

So right now your choices to launch nextcloud-client:

using kwallet: have to launch nc this way to force nextcloud-client using it: DESKTOP_SESSION=kde KDE_SESSION_VERSION=5 nextcloud. Not required if using KDE Plasma DE of course. Depending
install gnome-keyring (just for nextcloud) and launch nextcloud

I don't know yet why it was working for you before, sorry.

I have to ensure my understanding is correct. I could then provide wrappers with the nc package to make life easier.

yopito · 2020-11-29T00:41:06Z

"you're not alone" : see frankosterfeld/qtkeychain#171

manfredu · 2020-11-29T15:45:08Z

Thank you for your in-depth analysis. For the moment I will stay with setting the env vars.

manfredu · 2020-11-29T16:02:45Z

qtkeychain backend's choice is complex and does not match your context or mine. See detectKeyringBackend() in https://github.com/frankosterfeld/qtkeychain/blob/master/keychain_unix.cpp.
It also does not perform a real availability of backend, nor it let choose the order of detection/choice.

It looks like the issue in my case is that I have libsecret installed (Don't ask me why):

I would expect that in my case the following code path would be executed since I use an unknown desktop environment (DESKTOP_SESSION="Lumina"):

    default:
        if (LibSecretKeyring::isAvailable()) {
            return Backend_LibSecretKeyring;
        }
        if (GnomeKeyring::isAvailable()) {
            return Backend_GnomeKeyring;
        }
        if (isKwallet5Available()) {
            return Backend_Kwallet5;
        }

So libsecret should detect that I have kwallet installed and not gnome-keyring?

yopito · 2020-12-04T07:47:49Z

nope: libsecret is a GNOME-only stuff

gt7-void · 2021-01-19T18:41:09Z

Since LibSecretKeyring::isAvailable() does not check if secret service is available, only that the library is installed (it seems the library doesn't provide any way to check availability of the service), the only reasonable fix seems to be changing the order of the tests as in:

     default:
+        if (isKwallet5Available()) {
+            return Backend_Kwallet5;
+        }
         if (LibSecretKeyring::isAvailable()) {
             return Backend_LibSecretKeyring;
         }
         if (GnomeKeyring::isAvailable()) {
             return Backend_GnomeKeyring;
         }
-        if (isKwallet5Available()) {
-            return Backend_Kwallet5;
-        }

Note that setting DESKTOP_SESSION=kde, etc. might have some undesirable side-effects, so this patch should be preferred.

Otherwise, there's no way to use any other backend than libsecret if libsecret is installed [1] , so you need to install a secret service provider. I could find two in void:

gnome-keyring
keepassxc (depends on keepassxc: enable fdosecrets by default #28020 to work)

Meanwhile I was using kwallet only because qtkeychain-qt5 did not work with gnome-keyring before. With the current qtkeychain-qt5nowgnome-keyringworks out of the box for me (just install it, no configuration necessary as long aslibsecretis installed). The alternativekeepassxc` seems to work, but I didn't like it (cf https://avaldes.co/2020/01/28/secret-service-keepassxc.html for a guide).

For pass users, there's this: https://pypi.org/project/pass-secret-service/ (source here: https://github.com/mdellweg/pass_secret_service) but I don't know if it works.

[1] for me libsecret is an (indirect) dependency of mediainfo (surprising, as I only use the command line tool).

yopito · 2021-02-13T20:06:07Z

thanks for you detailed answer.

I don't feel confident to patch qtkeychain the way you propose. it's too intrusive for me, at least because it's changing a lot the way it's working compared to upstream. It will also make even more difficult to discuss with upstream in case of trouble.

Instead, I prefer to make a wrapper via a dedicated package to help people using nextcloud with kwallet as credential storage, while not wihin KDE Desktop Environment.

…kwallet subpackage * shibboleth is "highly deprecated" by upstream, will be removed in 3.2. * webkit support is currently ineffective and difficult to fix. * fix ~dolphin build options * nextcloud-client-kwallet: dedicated package for kwallet as credential storage Closes: void-linux#26774

yopito · 2021-02-15T08:52:23Z

Added a subpackage nextcloud-client-kwallet in PR #28674.

Purpose: make nextcloud-client uses kwallet as credential backend storage while not using KDE as Desktop Environment.

…kwallet subpackage * shibboleth is "highly deprecated" by upstream, will be removed in 3.2. * webkit support is currently ineffective and difficult to fix. * fix ~dolphin build options * nextcloud-client-kwallet: dedicated package for kwallet as credential storage Closes: void-linux#26774

manfredu mentioned this issue Nov 28, 2020

qtkeychain-qt5: update to 0.11.1 #26497

Merged

gt7-void mentioned this issue Jan 18, 2021

keepassxc: enable fdosecrets by default #28020

Closed

yopito mentioned this issue Feb 13, 2021

nextcloud-client: update to 3.1.2, no shibboleth and webkit support, kwallet subpackage #28674

Merged

3 tasks

ericonr closed this as completed in aa116ab Feb 24, 2021

gt7-void mentioned this issue Mar 19, 2021

separate mediainfo cli from gui #29578

Closed

menaechmi mentioned this issue Feb 6, 2023

nextcloud-client: fix kwallet desktop file #42051

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

nextcloud client no longer working #26774

nextcloud client no longer working #26774

manfredu commented Nov 28, 2020

manfredu commented Nov 28, 2020

yopito commented Nov 28, 2020

manfredu commented Nov 28, 2020

manfredu commented Nov 28, 2020

yopito commented Nov 28, 2020

yopito commented Nov 29, 2020

yopito commented Nov 29, 2020

manfredu commented Nov 29, 2020

manfredu commented Nov 29, 2020 •

edited

Loading

yopito commented Dec 4, 2020

gt7-void commented Jan 19, 2021

yopito commented Feb 13, 2021

yopito commented Feb 15, 2021

nextcloud client no longer working #26774

nextcloud client no longer working #26774

Comments

manfredu commented Nov 28, 2020

System

Expected behavior

Actual behavior

Steps to reproduce the behavior

manfredu commented Nov 28, 2020

yopito commented Nov 28, 2020

manfredu commented Nov 28, 2020

manfredu commented Nov 28, 2020

yopito commented Nov 28, 2020

yopito commented Nov 29, 2020

yopito commented Nov 29, 2020

manfredu commented Nov 29, 2020

manfredu commented Nov 29, 2020 • edited Loading

yopito commented Dec 4, 2020

gt7-void commented Jan 19, 2021

yopito commented Feb 13, 2021

yopito commented Feb 15, 2021

manfredu commented Nov 29, 2020 •

edited

Loading