Desktop: Asks for password at every start

[NeoFromMatrix]

Fedora 30: client seems to be logged out after reboot or application restart. I have another laptop with Fedoa 29 (Gnome, Wayland) where it works as it should with client version 2.5.2git

Expected behaviour

Automatic login after reboot/restart of the application.

Actual behaviour

Application shows "No connection to Nextcloud at MYDOMAIN.TLD"
Then after some time, the login window pops up with "you have been looged out of [email protected]". Please login again

Steps to reproduce

1. setup Nextcloud client and let it sync
2. reboot or end application (background task) via any task manager
3. start application

Client configuration

Client version: 2.5.2
Operating system: Fedora 30 Workstation
OS language: Eng
Qt version used by client package (Linux only, see also Settings dialog): 5.12.1
Client package (From Nextcloud or distro) (Linux only): nextcloud-client-2.5.2-2.fc30.src.rpm
Installation path of client: /usr/bin/nextcloud

Server configuration

Tested with 15.0.7

Logs

1. Client logfile:
   log.txt with 15.0.7
   log2.txt WITH 16.0.1.1

2. Web server error log:

3. Server logfile: nextcloud log (data/nextcloud.log):

[FrostKnight]

This bug has been here since the 2.3.2 version of nextcloud's AppImage.

I thought someone would've noticed by now. My bad for not reporting it.

[MarcusE1W]

I have the same experience using Archlinux ARM. I hoped using an App-password might help, but that is also only used for one login and the next time I have to login again.
Desktop client 2.5.2

[pianycist]

Same here, on my raspberry pi

Client version: 2.5.2git
Operating system: Arch Linux ARM, raspberry pi 2B (armv7)
OS language: Eng
Qt version used by client package (Linux only, see also Settings dialog): 5.12.3
Client package (From Nextcloud or distro) (Linux only): nextcloud-client 2.5.2-1 from community repository
Installation path of client: /usr/bin/nextcloud

Edit: I initally included information about my desktop computer but it was in error, because this issue isn't actually happening on my 64-bit Manjaro desktop.

[b-m-f]

Same on Ubuntu 19.04 with 2.5.2

[MarcusE1W]

Is there something I can do to analyse the issue further ?

[Nesousx]

Hi,

Same issue here:

• Nextcloud version 2.5.2git
• Fedora 30.

[gloolim]

Hi,
Did you install libgnome-keyring package ?
https://bugzilla.redhat.com/show_bug.cgi?id=1674106

[Nesousx]

Hi,
Did you install libgnome-keyring package ?
https://bugzilla.redhat.com/show_bug.cgi?id=1674106

Hi,

Installing libgnome-keyring (Fedora), fixed the issue. Thank you!

[NeoFromMatrix]

Installed libgnome-keyring on Fedora 30 Gnome and it seems to work now.

[b-m-f]

Tried libgnome-keyring-common on Ubuntu 19.04. Problem still persists

Edit: Installing libgnome-keyring0 fixes the problem on Ubuntu 19.04

[BentHaase]

Hi,
Did you install libgnome-keyring package ?
https://bugzilla.redhat.com/show_bug.cgi?id=1674106

Thanks, worked for me too.

But should libgnome-keyring not be included in the dependencies for nextcloud-client then?

[pianycist]

A belated update:

I neglected to include the information that I don't have a display connected to the raspberry pi, so the only time I would use the Nextcloud client was when I would start a virtual display vnc session and connect to it from another device. I had problems ensuring gnome-keyring would start with vnc sessions on the pi.

(For unrelated reasons I've decided to install the aarch64 version of Arch ARM on this pi since it's a 3B+, and I chose not to have a desktop environment this time.)

[misch7]

I debugged this issue on Fedora 30 and 31 and nailed it down to the Qtkeychain library.

Apparently Clients built with version v0.9.1 (latest release) of the Qtkeychain library tend to rely on libgnome-keyring even though we've built them with libsecret. Switching to master seems to solve the issue because of recent fixes made to Qtkeychain.

So I created a new daily AppImage build of the Client, also containing fix #1646, built with Qtkeychain's master branch instead of v0.9.1 and successfully tested it on Fedora 30 and 31.

Please take the following steps to verify if it also works for you:

• Download and run the new AppImage:
  https://download.nextcloud.com/desktop/daily/Linux/Nextcloud-2.7.0.20191130-daily-x86_64.AppImage
• The Client should ask you for the password only once, re-login
• Reboot the system and check the result
• Then please report back here ;-)

[brrrrrrrt]

Please take the following steps to verify if it also works for you:

• Download and run the new AppImage:
  https://download.nextcloud.com/desktop/daily/Linux/Nextcloud-2.7.0.20191130-daily-x86_64.AppImage
• The Client should ask you for the password only once, re-login
• Reboot the system and check the result
• Then please report back here ;-)

did not reboot, just shut down the old client (2.6.0) and fired up the appimage, and tadaaa!

works like a charm!

no login needed, no more crazy IO/CPU usage from gnome-keyring-daemon.

thank you, you are awesome!

ah, and the appimage is already available via AUR, great!

[rdica]

I tried the new Appimage on a Fedora 30 XFCE4 installation with no prior run of the client.
Here's syslog output of client startup, ending ten minutes after startup:

Nov 30 15:17:31 toshiba systemd[1]: tmp-.mount_NextclHdrn5Q.mount: Succeeded.
Nov 30 15:17:31 toshiba systemd[1370]: tmp-.mount_NextclHdrn5Q.mount: Succeeded.
Nov 30 15:17:35 toshiba systemd[1370]: tmp-.mount_NextclvHI500.mount: Succeeded.
Nov 30 15:17:35 toshiba systemd[1]: tmp-.mount_NextclvHI500.mount: Succeeded.
Nov 30 15:17:41 toshiba systemd[1]: fprintd.service: Succeeded.
Nov 30 15:19:53 toshiba systemd[1370]: Started dbus-:[email protected].
Nov 30 15:19:53 toshiba gnome-keyring-daemon[6118]: couldn't access control socket: /run/user/1000/keyring/control: No such file or directory
Nov 30 15:19:53 toshiba journal[6118]: couldn't access control socket: /run/user/1000/keyring/control: No such file or directory
Nov 30 15:19:53 toshiba systemd[1370]: Created slice dbus\x2d:1.2\x2dorg.gnome.keyring.SystemPrompter.slice.
Nov 30 15:19:53 toshiba systemd[1370]: Started dbus-:[email protected].
Nov 30 15:20:13 toshiba gnome-keyring-daemon[6118]: asked to register item /org/freedesktop/secrets/collection/login/2, but it's already registered
Nov 30 15:20:13 toshiba journal[6118]: asked to register item /org/freedesktop/secrets/collection/login/2, but it's already registered
Nov 30 15:20:24 toshiba systemd[1370]: dbus-:[email protected]: Succeeded.

Not seeing continuous syslog spam.

Testing was performed against Nextcloud 16.0.6 using docker img nextcloud:16.0.6 (new install, not an upgrade).

On a side note, this is the first time the desktop client v2 login flow has worked, I had to downgrade all my mac/win/linux desktop clients back to 2.5.3 in order to use the app keys I created for them.

[Wivik]

New Appimage test OK for me (Fedora 30). Login at first time, closed, re-launched, no need to relog.
Thanks a lot !

[toxpal]

So if I understand right, this is a known issue, which seems to be fixed in AppImage, and fix will be ported into official (final) 2.6.2 (or 2.7) release, right?

[misch7]

@toxpal That's correct and this fix will get into our upcoming 2.6.2 release.

(Don't be confused: 2.7 is the development branch.)

[liedekef]

Is this really fixed in 2.6.2? I'm using the following libs on Fedora 31:

nextcloud-client-libs-2.6.2-1.fc31.x86_64
nextcloud-client-2.6.2-1.fc31.x86_64

and this issue still occurs. Or do I need to reinitialize anything?

Edit: ok, it seems the dependency on libgnome-keyring is not added to the rpm. I installed it, all is ok now.

[toxpal]

@liedekef, I confirm the issue is NOT fixed in 2.6.2 (using Antergos KDE).

@misch7, can you re-open the issue (since it's not resolved), please?

[FillyAgioro]

Same problem with my Debian 10. The client asked to log in every time I start the pc. I am using i3wm. Is my window manager causing problem?

I have the latest version of the Nextcloud Appimage.

[FillyAgioro]

My problem has solved with help of gnome-keyring with PAM_method.
https://wiki.archlinux.org/index.php/GNOME/Keyring#PAM_method

[dwaxweiler]

I can confirm that the issue persists on Ubuntu 18.04.1 with the latest version as well.

[MarcusE1W]

I have an interesting variant.

When using Manjaro ARM KDE plasma desktop the login works fine with kwallet. However when using LXQt on the same am machine nextcloud-client (also in the latest version) does not find the existing password.

When I then use gnom-keyring it works fine.

[toxpal]

In case this is important, I do NOT use KWallet (it's disabled on my system).

[claell]

Reopening as this does not seem to be fixed for some users.

[MarcusE1W]

Could someone of the experts explain what has to be in place for it to work, so how should it work, for these scenarios:

• kwallet
• gnome-keyring
• no wallet

So what is it exactly that nextcloud-client is using and what configuration has to be in place. Then people here can go and check if their confirmation meets the requirements and if not why not. I fi d it curious that it works for me with KDE but nit with LXQt on the same laptop. There must be some difference in the configuration used, but which one?

Does that make sense?

[toxpal]

So here are some updates. I currently use 3 computers with KDE - 2xManjaro KDE (Arch-based) and 1xKDE Neon (Ubuntu-based) - all have the same problem.

But... Recently, gnome-keyring was installed as a dependency for some app on one KDE machine. Right after that, NC desktop client started working perfectly. Once I uninstalled that extra app + gnome-keyring (which is not a part of KDE anyways), NC desktop client started asking for authentication at every start again.

I do NOT use Kwallet (it's installed, but disabled) on any of my computers. Hope that helps.

[claell]

@MarcusE1W sorry, I cannot help there.

From what I can see, this issue seems to only happen on Linux machines, at least in this thread nobody mentioned having this issue on Windows, might have happend in the duplicate issues, though.

If the client requires some dependencies (which I don't know), they should get installed, or be included in the AppImage probably. But again, I don't know whether that is the issue.

It might help if all of you having this issue can edit their post with the following information:

• OS (+version and desktop environment)
• Client (versions that work/don't work) and source (PPA, AppImage, other)
• Other information that is considered important

However, in the end someone probably has to take the time to track this issue down in the code and fix it. Providing as much information as possible to help with that might make that easier.

[MrManor]

Just to add my observations: I manage/support several system for less techsavy family and friends. I see they never manage to use the desktop syncclient - "Ohh that thing - it never works so got tired of it and just press close". When I observe them login, they often start login and leave to fetch coffie or whatever. When they return kdewallet is waiting for password - and NCSync apparently timed out waiting for keyring to be opened, and now also asking for password.
All system are KDE based and gnome-keyring is removed to avoid more than one password manager popping up and confusing users. All running

• OpenSUSE 15.1
• KDE Framework 5.55.0
• Qt 5.9.7
• nextcloud-client-2.5.3
• kwalletd5-5.55.0

I have observed that when I login myself - and I am fast enough to answer the kdewallet password prompt right after login, everything works as expected. But one typing error - another password popup stealing focus while typing - or a long passphrase - and you are doomed.

Edit: Well not completely doomed. I just tried to kill the instance prompting for password, and start a new after opening kdewallet. That worked to.

[toxpal]

So it looks we get closer to the issue - NC probably can only utilize password wallet built into OS and doesn't (can't) store password inside itself. It's just my guess based on my findings and reports/feedback by other users.

Hope devs can make the app to store authentication credentials inside the app itself, so no extra password managers are needed and NC works properly on all systems, with and without internal wallets.

[mnlipp]

Doesn't work for me. I have Fedora 31 with gnome-keyring 3.34 and nextcloud-client 2.6.4.

Nextcloud client doesn't store any credentials in gnome-keyring (I checked that gnome-keyring works by adding credentials for a remote share in nautilus). I also removed ~/.config/Nextcloud and re-added by accounts. Doesn't work.

[void-m4110c]

So it looks we get closer to the issue - NC probably can only utilize password wallet built into OS and doesn't (can't) store password inside itself. It's just my guess based on my findings and reports/feedback by other users.

Hope devs can make the app to store authentication credentials inside the app itself, so no extra password managers are needed and NC works properly on all systems, with and without internal wallets.

This is the real solution of the problem. I have a completely Gnome/KDE free system and I want to keep it that way. I don't want to install all the Gnome-Keyring-Ecosystem-Crap just to start a small sync-tool without re-authenticating on every start. It can't be that hard to store some hashed credentials by the application itself.

I would use the commandline tool "nextcloudcmd" calling it from a shell script with stored credentials. But the AppImage does not seem to provide that. Only the graphical client.

Using the source package (which provides the nextcloudcmd tool) is also not an option, as it pulls in QtWebengine which compiles for hours on every system update (I'm using Gentoo).

[mnlipp]

It can't be that hard to store some hashed credentials by the application itself.

Making unencrypted hashes available is considered bad practice for a loooong time (https://en.wikipedia.org/wiki/Passwd#Shadow_file). I can perfectly understand that the developers prefer to rely on a service for storing credentials reliably instead of implementing security holes for the nth time.

[void-m4110c]

It can't be that hard to store some hashed credentials by the application itself.

Making unencrypted hashes available is considered bad practice for a loooong time (https://en.wikipedia.org/wiki/Passwd#Shadow_file). I can perfectly understand that the developers prefer to rely on a service for storing credentials reliably instead of implementing security holes for the nth time.

I did not say that they have to be unencrypted and available. Do you really want to imply, that it is not possible for an application to handle credentials without using a third party wallet?

And even if there is no way to do it according to best practices, it would be great to be able to opt out if I can handle the risk. Why can't I be asked if I prefer the unsecure procedure of storing my credentials encrypted inside the app? (I still doubt that it has to be unsecure)

Because you know what happens with this "best practice"? People start to call command-line tools with clear text credentials stored in shell-scripts. This is like forcing people to remember 15 character passwords...they end up writing it on a postit and pin it to their monitor...

[mnlipp]

I did not say that they have to be unencrypted and available. Do you really want to imply, that it is not possible for an application to handle credentials without using a third party wallet?

Of course it is possible. Doing it right only requires, well, an effort comparable to re-implementing something that is already available as "third party wallet".

[void-m4110c]

Nevermind rclone is there for the rescue.

@mnlipp: You're telling me, in order to being able to ride the bike, someone has to build a car for me first.... m)
You don't need a full fledged wallet application in order to let me decide if I want to store my credentials (encrypted) inside the app, or let me call the app with my credentials as command line arguments or any other feasible way, like hundreds of other applications do. They most certainly have not implemented the same functionality as a wallet application has.

[mnlipp]

@mickmattes:

... let me call the app with my credentials as command line arguments

Trap one (of many): anybody on the same computer can see the command line arguments (and thus your credentials) using ps.

I suppose it's a matter of attitude. Your attitude is "I don't really care about having as much security as can be achieved". My attitude is "make sure that (especially casual) users are prevented from doing things in an insecure way if that can be done".

If I need a bike, I buy one from people who know how to build a safe one. I don't build one myself and take that risk that it kills me on the first pothole because I didn't get the statics right.

[void-m4110c]

@mnlipp:

Trap one (of many): anybody on the same computer can see the command line arguments (and thus your credentials) using ps.

First, I'm the only user that has access to my computer. But yeah, that's my special use case and definitely not suited for everybody.
Second, in my view it's utterly silly not to mount your /proc file system with hidepid=1/2, so users can see only their own processes. Especially on a multi-user system. So having your system misconfigured is not a good argument here.

I suppose it's a matter of attitude. Your attitude is "I don't really care about having as much security as can be achieved". My attitude is "make sure that (especially casual) users are prevented from doing things in an insecure way if that can be done".

My attitude is: If you don't know what you're doing, stick to the default way. If you know what you're doing, you should be able to deviate from the default way. I see no reason why you can't protect (casual) users from doing stupid things (i.e. default settings) while providing options to the more tech-savvy users (i.e. configurable default settings). Last time I checked my car could still drive over 250km/h even if there exist stupid people, that kill themselves bc. they drive too fast.

Let me give you an example. Look at the tool "msmtp". There you have a config file, where you can simply specify which command/tool should be executed to retrieve the password. Default is system-wallet and ${normal-user} won't even realize this setting is there. But I can also enter some other wallet app, or use gpg or use password-store or use some other en-/decryption function. If I really want or need, I can even insert my credentials in clear text and make the file non-readable for others. You see, there you are free to chose whatever you want, depending on your needs and skill. If I needed pampers, I'd buy a MacBook and use Dropbox or Google Drive.

If I need a bike, I buy one from people who know how to build a safe one. I don't build one myself and take that risk that it kills me on the first pothole because I didn't get the statics right.

You know what a straw-man argument is, right? But maybe I did not make myself clear enough. Let me try again:

I did not say, that I want to build a bike. I said, when I enter the bike shop I don't want the salesman to tell me "You have to use a car, because it's much safer for you."

[mnlipp]

I don't want the salesman to tell me "You have to use a car, because it's much safer for you."

I do. Matter of attitude, as I said.

[er-vin]

This looks mostly like a packaging issue to me. This should be solved in the binaries we produce because they come with a fixed qtkeyring which distro packages might not be using. For those still having the issue despite having kwallet or gnome keyring installed, could you check the version of qtkeyring your nextcloud client is linking against?

[dassio]

I debugged this issue on Fedora 30 and 31 and nailed it down to the Qtkeychain library.

Apparently Clients built with version v0.9.1 (latest release) of the Qtkeychain library tend to rely on libgnome-keyring even though we've built them with libsecret. Switching to master seems to solve the issue because of recent fixes made to Qtkeychain.

So I created a new daily AppImage build of the Client, also containing fix #1646, built with Qtkeychain's master branch instead of v0.9.1 and successfully tested it on Fedora 30 and 31.

Please take the following steps to verify if it also works for you:

* Download and run the new AppImage:
  https://download.nextcloud.com/desktop/daily/Linux/Nextcloud-2.7.0.20191130-daily-x86_64.AppImage

* The Client should ask you for the password only once, re-login

* Reboot the system and check the result

* Then please report back here ;-)

yes it is the the qtkeychain issue, the ubuntu qt5keychain-dev dependency libqt5keychain1 is not built with libsecret-1-dev(i don't see libsecret-1-dev in libqt5keychain1's dependency list, i don't know how to check it ).

after rebuild qtkeychain withlibsecret-1-dev, it works on Ubuntu18LTS.

Here is the configure output without libsecret-1-dev:

danny@xps:~/tools/qtkeychain/build$ cmake -D CMAKE_BUILD_TYPE=Debug -D CMAKE_INSTALL_PREFIX=/usr ../
-- The C compiler identification is GNU 7.5.0
-- The CXX compiler identification is GNU 7.5.0
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Found PkgConfig: /usr/bin/pkg-config (found version "0.29.1") 
-- Checking for module 'libsecret-1'
--   No package 'libsecret-1' found
-- Performing Test COMPILER_HAS_HIDDEN_VISIBILITY
-- Performing Test COMPILER_HAS_HIDDEN_VISIBILITY - Success
-- Performing Test COMPILER_HAS_HIDDEN_INLINE_VISIBILITY
-- Performing Test COMPILER_HAS_HIDDEN_INLINE_VISIBILITY - Success
-- Performing Test COMPILER_HAS_DEPRECATED_ATTR
-- Performing Test COMPILER_HAS_DEPRECATED_ATTR - Success
-- Configuring done
-- Generating done
-- Build files have been written to: /home/danny/tools/qtkeychain/build

here is the output with libsecret-1-dev:

danny@xps:~/tools/qtkeychain/build$ cmake -D CMAKE_BUILD_TYPE=Debug -D CMAKE_INSTALL_PREFIX=/usr ../

-- Checking for module 'libsecret-1'
--   Found libsecret-1, version 0.18.6
-- Configuring done
-- Generating done
-- Build files have been written to: /home/danny/tools/qtkeychain/build

[dassio]

i file a bug report for the ubuntu libqt5keychain1 pacakge :
https://bugs.launchpad.net/ubuntu/+source/qtkeychain/+bug/1888089

[er-vin]

Alright, since it gets confirmed this is a downstream issue I'll close it here.

[claell]

@er-vin I'd consider this to be upstream (from a Nextcloud perspective), correct?

Maybe we can add an appropriate label and leave this open until it got fixed.

[er-vin]

Well, if you want to be precise it's the downstream of one of our upstreams which is impacted. :-)

As for keeping it open, it's the kind of things where I'd be concerned we forget to close it later on, so I'd rather keep it closed.

[claell]

Hm. Reading through the reports here this is not Ubuntu specific. There are also People on Fedora (look at the original post for example) and probably other distributions affected. So this is not just one downstream of an upstream. Maybe many (all?) downstream projects do it wrong, but there might also be a different problem.

Afaik, leaving issues open until upstream is fixed is a common practice, although it is probably debatable whether this is an upstream issue.

[jgonsior]

Unless I've installed gnome-keyring the same issue applies to Arch Linux as well. But I see it more as a question if Nextcloud should take care of managing the login credentials on their own, or if that should be forwarded to Gnome Keyring/KDE Wallet (and the Mac OS/Windows equivalent).

[er-vin]

Unless I've installed gnome-keyring the same issue applies to Arch Linux as well. But I see it more as a question if Nextcloud should take care of managing the login credentials on their own, or if that should be forwarded to Gnome Keyring/KDE Wallet (and the Mac OS/Windows equivalent).

Well this is what we do. QtKeyring is the library we use to abstract the different platform specific APIs.

[er-vin]

Hm. Reading through the reports here this is not Ubuntu specific. There are also People on Fedora (look at the original post for example) and probably other distributions affected. So this is not just one downstream of an upstream. Maybe many (all?) downstream projects do it wrong, but there might also be a different problem.

Afaik, leaving issues open until upstream is fixed is a common practice, although it is probably debatable whether this is an upstream issue.

From the bug on the debian side this looks like it points toward a bug in qtkeychain. This got fixed with: https://github.com/frankosterfeld/qtkeychain/pull/139

This made it to qtkeychain 0.10.0

[claell]

From the bug on the debian side this looks like it points toward a bug in qtkeychain. This got fixed with: frankosterfeld/qtkeychain#139

This made it to qtkeychain 0.10.0

This is one example of a user with Fedora experiencing this:

Doesn't work for me. I have Fedora 31 with gnome-keyring 3.34 and nextcloud-client 2.6.4.

Nextcloud client doesn't store any credentials in gnome-keyring (I checked that gnome-keyring works by adding credentials for a remote share in nautilus). I also removed ~/.config/Nextcloud and re-added by accounts. Doesn't work.

Maybe they still use an older version of qtkeychain?

Regarding the other users I noticed that some probably don't have any credential manager available that can be used by qtkeychain? So that is basically a different cause for this issue. Maybe those issues should be split up. Is there a mechanism in place to maybe notify the user that they need such credential manager, so the desktop client can remember their login?

[er-vin]

From the bug on the debian side this looks like it points toward a bug in qtkeychain. This got fixed with: frankosterfeld/qtkeychain#139
This made it to qtkeychain 0.10.0

This is one example of a user with Fedora experiencing this:

Doesn't work for me. I have Fedora 31 with gnome-keyring 3.34 and nextcloud-client 2.6.4.
Nextcloud client doesn't store any credentials in gnome-keyring (I checked that gnome-keyring works by adding credentials for a remote share in nautilus). I also removed ~/.config/Nextcloud and re-added by accounts. Doesn't work.

Maybe they still use an older version of qtkeychain?

Yes, apparently Fedora still has 0.9.1 so unless they backported the patch they'd hit the bug.

Regarding the other users I noticed that some probably don't have any credential manager available that can be used by qtkeychain? So that is basically a different cause for this issue. Maybe those issues should be split up. Is there a mechanism in place to maybe notify the user that they need such credential manager, so the desktop client can remember their login?

Yes, different thing and maybe we could show a notification for that in the the activity list now. To be discussed separately IMO.

[claell]

Alright, makes sense then!