"No keychain service available" - 1.5.2, Gnome

[aruhier]

Hello,
Since the last upgrade (1.5.1->1.5.2), I saw that you use a keyswallet to save the password. On Gnome 3.10 on ArchLinux, it doesn't work on my 2 PC, owncloud is always asking me the password at startup.

This is the logfile at startup :

02-28 01:59:02:581 "################## ownCloud fr_FR () 1.5.2" 
02-28 01:59:02:581 void Mirall::Application::setupTranslations() Using "fr_FR" translation 
02-28 01:59:02:586 * Setup folders from  "/home/anthony/.local/share/data//ownCloud/folders" 
02-28 01:59:02:586   ` -> setting up: "ownCloud" 
02-28 01:59:02:586     -> file path:  "/home/anthony/.local/share/data/ownCloud/folders/ownCloud" 
02-28 01:59:02:586 Checked local path ok 
02-28 01:59:02:587 setting remote poll timer interval to 30000 msec 
02-28 01:59:02:587 Adding folder to Folder Map  Mirall::Folder(0x1790f10) 
02-28 01:59:02:587 (+) Watcher: "/home/anthony/ownCloud/" 
02-28 01:59:02:611     `-> and 575 subdirectories 
02-28 01:59:02:611   ==> returning exclude file path:  "/etc/ownCloud/sync-exclude.lst" 
02-28 01:59:02:611   ==> returning exclude file path:  "/home/anthony/.local/share/data/ownCloud/sync-exclude.lst" 
02-28 01:59:02:611 Schedule folder  "ownCloud"  to sync! 
02-28 01:59:02:617 SocketApi:  ctor:  "/home/anthony/.local/share/data/ownCloud/socket" 
02-28 01:59:02:617 SocketApi:  server started 
02-28 01:59:02:715 Sys Info size:  93 
02-28 01:59:02:719 Error while reading password "No keychain service available" 
02-28 01:59:02:719 0 
02-28 01:59:04:611 FolderMan: Syncing is disabled, no scheduling. 
02-28 01:59:06:244 Client is on latest version! 

Seahorse is installed and works.
Thank you !

[CRCinAU]

I'm got a similar problem... Fedora 20 using XFCE. The following is installed:
qtkeychain-0.1.0-4.20130805git.fc20.x86_64
libgnome-keyring-3.10.1-1.fc20.x86_64
gnome-keyring-3.10.1-1.fc20.x86_64
seahorse-3.10.2-1.fc20.x86_64

I get prompted for my password on every launch of the ownCloud client.

[CRCinAU]

Further to this - it seems I have to reenter the password via the "Modify Account" option in the Windows client too. It seems like the password is not saved on reboot in Windows either...

[ogoffart]

For security reason, we don't store the password anymore, and require the keychain to be properly configured.

[CRCinAU]

I think that we all understand this - however:

1. For whatever reason on our linux systems, it isn't working - with no verbose reason as to why.
2. Windows also forgets passwords.

EDIT: As further to this, it seems Google Chrome uses the keychain without any problems. I can also see info from within Seahorse - leading me to believe that it is not a keychain problem (but I'll gladly be proved wrong!)

[twouters]

Same here.
gnome-keyring-daemon has been started with /usr/bin/gnome-keyring-daemon --start --components=gpg,pkcs11,secrets,ssh
GNOME_KEYRING_CONTROL environment veriable is set to the correct control dir.
It contains the following sockets:

control
gpg
pkcs11
ssh

[CRCinAU]

From within XFCE, I managed to fix this by going into Settings -> Session and Startup -> Advanced.

Place a tick in the option "Launch GNOME services on startup".

[aruhier]

Seahorse is running, and, like @twouters, my GNOME_KEYRING_CONTROL environment variable is correctly set. No problem with other programs that use gnome-keyring, just with owncloud-client.

[eigengrau]

I too get Error while reading password "No keychain service available" although the Gnome keyring is working properly and I have qtkeychain 0.1 installed.

[eigengrau]

The keyring support appears to work with the latest head from the qtkeychain git, but not with the latest release (which is 0.1).

[danimo]

@eigengrau That means we need to make sure to depend on our latest version of qtkeychain //cc @dragotin

[dragotin]

Ok, I added explicit version dependencies for libowncloudsync (on %{version}) and libqtkeychain (>= 0.20140128). That should solve it. Repository is isv:ownCloud:desktop

[CRCinAU]

Is the versioning on this consistent with other distributions?

In Fedora 20, I see:
Installed Packages
qtkeychain.x86_64 0.1.0-4.20130805git.fc20 @updates

I think more research is required before putting dependencies on X... I don't have a problem using Fedora 20 + XFCE after setting the option to start gnome services on login.

[CRCinAU]

Now we're causing problems again...

Fedora has the packages qtkeychain. ie:

yum list qtkeychain*

Installed Packages
qtkeychain.x86_64 0.1.0-4.20130805git.fc20 @updates
Available Packages
qtkeychain.i686 0.1.0-4.20130805git.fc20 updates
qtkeychain-devel.i686 0.1.0-4.20130805git.fc20 updates
qtkeychain-devel.x86_64 0.1.0-4.20130805git.fc20 updates

These work. They have been working fine.

Now you've added a dep on libqtkeychain - which is also present in your repos:

yum list libqtkeychain*

Available Packages
libqtkeychain-debuginfo.i686 0.20140128-2.1 isv_ownCloud_desktop
libqtkeychain-debuginfo.x86_64 0.20140128-2.1 isv_ownCloud_desktop
libqtkeychain-devel.i686 0.20140128-2.1 isv_ownCloud_desktop
libqtkeychain-devel.x86_64 0.20140128-2.1 isv_ownCloud_desktop
libqtkeychain0.i686 0.20140128-2.1 isv_ownCloud_desktop
libqtkeychain0.x86_64 0.20140128-2.1 isv_ownCloud_desktop

Problem is, these two sets of packages conflict.

When trying to upgrade, we get this:
Transaction check error:
file /usr/lib64/libqtkeychain.so.0.2.0 from install of libqtkeychain0-0.20140128-2.1.x86_64 conflicts with file from package qtkeychain-0.1.0-4.20130805git.fc20.x86_64

[CRCinAU]

Futher, if you now try to install the client on Fedora 20, you get this:

Package Arch Version Repository Size

Installing:
owncloud-client x86_64 1.5.2-7.1 isv_ownCloud_desktop 381 k
Installing for dependencies:
libowncloudsync0 x86_64 1.5.2-7.1 isv_ownCloud_desktop 362 k
libqtkeychain0 x86_64 0.20140128-2.1 isv_ownCloud_desktop 51 k
owncloud-client-l10n
x86_64 1.5.2-7.1 isv_ownCloud_desktop 223 k
qtkeychain x86_64 0.1.0-4.20130805git.fc20 updates 50 k

Transaction Summary

Install 1 Package (+4 Dependent packages)

Total size: 1.0 M
Installed size: 3.5 M
Is this ok [y/d/N]: y
Downloading packages:
Running transaction check
Running transaction test

Transaction check error:
file /usr/lib64/libqtkeychain.so.0.2.0 conflicts between attempted installs of libqtkeychain0-0.20140128-2.1.x86_64 and qtkeychain-0.1.0-4.20130805git.fc20.x86_64

[dragotin]

ok, now I understand. Fedora 19 and 20 have the qtkeychain package upstream. Ok, so I will disable our package for these platforms, hoping that upstream will stay up to date.

For CentOS and RHEL no upstream package is available, right?

[danimo]

@dragotin the question is wether upstreams packages are not too old.

[eigengrau]

The latest official release is 0.1. This appears to be the one causing this bug. Upstream’s head is using 0.2 as the soname and also advertises itself as 0.2.0 in the installed cmake config.

[CRCinAU]

The stock Fedora 20 package for qtkeychain works as it should.

EL6 (CentOS etc) does not have qtkeychain.

[dragotin]

I can not disable the packages because the OBS with which we build the Fedora packages does not know the upstream packages because they are only in Fedora Update. That's a pitty, but I see no other solution than obsoleting the upstream qtkeychain package by ours on Fedora 19 and 20.

It's of cause bad behave from the packaging POV, but currently the only solution I see. Once the qtkeychain is more stable and we have a proper upstream release, this will go away.

I checked the change in to isv:ownCloud:community:nightly, it would be good if it could be tested on Fedora (starting tomorrow). Thx.

[twouters]

How about providing the required version of the library in the owncloud package?

[CRCinAU]

Before we get a little 'commit happy', what are we actually trying to fix here?

I can confirm that all works correctly on Fedora 20 / XFCE without this interference with libqtkeychain versions. So, what situation are we trying to fix? I don't see much in the way of actual details as to the problem or any diagnosis of any type of fault.....

[ghost]

Hi,

as already written in #1495 (comment) this problem also affects users using the distro package from Debian/Ubuntu instead of the OBS packages as Debian/Ubuntu is also shipping libqtkeychain 0.1.0 without gnome-keyring support.

[aruhier]

The 1.5.3 version doesn't fix the problem for me on ArchLinux with Gnome 3.10

03-10 22:16:35:921 "################## ownCloud fr_FR () 1.5.3" 
03-10 22:16:35:921 void Mirall::Application::setupTranslations() Using "fr_FR" translation 
03-10 22:16:35:924 * Setup folders from  "/home/anthony/.local/share/data//ownCloud/folders" 
03-10 22:16:35:924   ` -> setting up: "ownCloud" 
03-10 22:16:35:924     -> file path:  "/home/anthony/.local/share/data/ownCloud/folders/ownCloud" 
03-10 22:16:35:924 Checked local path ok 
03-10 22:16:35:924 setting remote poll timer interval to 30000 msec 
03-10 22:16:35:924 Adding folder to Folder Map  Mirall::Folder(0x25018c0) 
03-10 22:16:35:924 (+) Watcher: "/home/anthony/ownCloud/" 
03-10 22:16:35:942     `-> and 623 subdirectories 
03-10 22:16:35:942   ==> returning exclude file path:  "/etc/ownCloud/sync-exclude.lst" 
03-10 22:16:35:942   ==> returning exclude file path:  "/home/anthony/.local/share/data/ownCloud/sync-exclude.lst" 
03-10 22:16:35:942 Schedule folder  "ownCloud"  to sync! 
03-10 22:16:35:946 SocketApi:  ctor:  "/home/anthony/.local/share/data/ownCloud/socket" 
03-10 22:16:35:946 SocketApi:  server started 
03-10 22:16:35:966 Sys Info size:  93 
03-10 22:16:35:977 !!! Mirall::CheckServerJob created for  QUrl( "https://owncloud.X.X" )  querying "status.php" 
03-10 22:16:36:109 SSL-Errors happened for url  "https://owncloud.X.X/status.php" 
03-10 22:16:36:110  Error in  QSslCertificate( "1" , "a9:4d:c1:3b:bd:d7:8f:c2" , "W1oeaCbGl5EYKMP5+hfmvw==" , "X.X" , "X.X" , QMap() , QDateTime("mer. déc. 11 22:29:51 2013") , QDateTime("sam. déc. 9 22:29:51 2023") ) : "Le nom d'hôte ne correspondait à aucun des hôtes valides pour ce certificat" ( "Le nom d'hôte ne correspondait à aucun des hôtes valides pour ce certificat" ) 
03-10 22:16:36:110  Error in  QSslCertificate( "1" , "a9:4d:c1:3b:bd:d7:8f:c2" , "W1oeaCbGl5EYKMP5+hfmvw==" , "X.X" , "X.X" , QMap() , QDateTime("mer. déc. 11 22:29:51 2013") , QDateTime("sam. déc. 9 22:29:51 2023") ) : "Le certificat n'est pas sécurisé car auto-signé" ( "Le certificat n'est pas sécurisé car auto-signé" ) 
03-10 22:16:36:112 Certs are already known and trusted, Errors are not valid. 
03-10 22:16:37:099 status.php returns:  QMap(("edition", QVariant(QString, "") ) ( "installed" ,  QVariant(QString, "true") ) ( "version" ,  QVariant(QString, "6.0.2.2") ) ( "versionstring" ,  QVariant(QString, "6.0.2") ) )    0  Reply:  QNetworkReplyImpl(0x24fa390) 
03-10 22:16:37:099 ** Application: ownCloud found:   QUrl( "https://owncloud.X.X/status.php" )   with version  "6.0.2" ( "6.0.2.2" ) 
03-10 22:16:37:100 Error while reading password "No keychain service available" 
03-10 22:16:37:100 0 

[danimo]

Installing a more recent version of QtKeychain will. That's out of scope for us, sorry. You can ask upstream to release a new version

[CRCinAU]

Is there any ETA of having the fixed dependencies for Fedora?

As advised previously, Fedora has a working version of qtkeychain - the required one from the ownCloud repo conflicts with the one in Fedora...

[aruhier]

Thank you for your answer, but there only is one release of QtKeychain, and I don't think that a lot of distributions use the git version of qtkeychain. Don't you think it mights be good to target the actual QtKeychain release ?

[danimo]

@Anthony25 Unfortunately, that's not possible.

[aruhier]

Ok thank you, I close the issue and will ask to the owncloud-client package maintainer for ArchLinux to add qtkeychain-git in the dependencies.

[CRCinAU]

No comment on the Fedora packages? o_O

[aruhier]

@CRCinAU, do you want me to reopen the issue ?

[CRCinAU]

@Anthony25 I'm not sure if this should be in the same bug report - or maybe a different one - however the change made because of this bug report causes the conflict with the default Fedora install. As such, I believe it may be better to keep it all in the one report. I'm happy for peoples opinions on this though!

This is the situation with Fedora:

Possible Solutions:

1. Add a Conflicts: qtkeychain to the ownCloud libqtkeychain package
2. Don't generate the libqtkeychain for Fedora and instead add a Requires: qtkeychain.
3. Something else?

[CRCinAU]

@dragotin Ping for comment?

[ogoffart]

We should ask @frankosterfeld to make a release of qtkeychain

[dragotin]

@CRCinAU I added an Obsoletes: qtkeychain to the libqtkeychain package we provide. Also, the client requires libqtkeychain >= 20140128, so what should happen is that the new client pulls libqtkeychain from OBS which in turn obsoletes the upstream one which is being uninstalled.

That works here on Fedora 20. Please check again.

[CRCinAU]

Sounds good to me!

[dragotin]

@CRCinAU does it also work for you? :-)

[Photon89]

I installed libqtkeychain from git (v. 0.1.0.58.gc130727, git checked out right now) along with owncloud-client 1.5.3 under Xfce 4.10.1, Arch Linux and the issue persists. Any hints?

[ghost]

Hi,

@Photon89

you might want to checkout 0.3.0:

https://github.com/frankosterfeld/qtkeychain/releases/tag/v0.3.0

instead of 0.1.0 which is known to not support gnome-keyring.

[Photon89]

Hi RealRancor,

thanks for the hint! I'm a bit confused, is the master branch bumped to 0.3.0 state already, or is it not? Comparing the master branch with the 0.3.0 I see only cosmetic changes: frankosterfeld/qtkeychain@master...0.3 It looks to me as if the master branch already had all the changes of 0.3.0 besides of the right version number.

[ghost]

@Photon89
Ah, you have mentioned that you have used something like 0.1.0.58.gc130727 and not stated that you have checked out the master branch of the qtkechain git repos. Normally this should include all needed changes.

[Photon89]

Yep, this was the version, git reported it to be. So, in the end, the problem appears even with latest qtkeychain...

[ghost]

Mhhh, then you might have a problem with your gnome-keychain setup / configuration as you're running XFCE and the needed services are probably just not started.

[aruhier]

Yes, because I am running on ArchLinux with gnome and the qtkeychain git version and it works well.
@Photon89, try to re-adding your account in your owncloud client, I saw a comment on AUR that says he solved your problem by doing it.

[Photon89]

@RealRancor , actually, this was most likely the problem. I checked a nice checkbox in the XFCE session settings: https://dl.dropboxusercontent.com/u/1507406/SessionandStartup_15-03-2014_19%3A34%3A19.png And afterwards I could use the gnome keyring to save the owncloud password. However, since I autologin into the X session, I still need to enter a password to unlock the keyring... So one password query has changed to another in my case. But I guess, now it's up to gnome keyring to disable the password query after autologin. This looks quite promising: http://nullroute.eu.org/~grawity/gnome-keyring-autologin.html Thanks for your support, everybody!

[kalinjul]

In kubuntu, this is also broken. Could you just provide a way to get back the old, unsafe behaviour instead of saying every user has to use the git version of qtkeychain? Or make it work with the old one, which is obviously the default on almost every distribution.

[ghost]

Hi,

@julakali

AFAIK the new version 1.5.3 is exactly using the old unsafe behavior. But as kubuntu is shipping the client 1.5.0 and this problem was first introduced in 1.5.2 you shouldn't see such an issue.

[danimo]

@RealRancor No, 1.5.3 is not storing plaintext passwords. All we did/tried to do is adding an explict dependency on the newer qtkeychain 0.2.xxx (and now 0.3.0) package.

[ghost]

Upps, sorry. Then i have misunderstood the changelog of the client 1.5.3.

[eigengrau]

This issue has reappeared for me since updating from 1.5.3 to 1.5.4. I was running qtkeychain-git before, since this solved the issue for me previously. I now installed qtkeychain 0.3, which has been released in the meantime, but this too is giving me “No keychain service available” in conjunction with 1.5.4.

[eigengrau]

Okay, apparently the problem was qtkeychain 0.3. I got owncloud client 1.5.4 to work by going back to qtkeychain-git, but now I’m on commit ga2437ac, which is tagged 0.3.0.9. So vanilla 0.3 doesn’t seem to work.

[ghost]

Just to point those who come across this issue via Google into the right direction: I fixed it in Debian, running LXDE with

export GNOME_KEYRING_CONTROL=/run/user/1000/keyring/

[akmc]

@mrbiber, thank's it worked in Fedora 20 | Gnome 3.12

[guruz]

I'm closing this issue.
If there are any issues with the > 1.6 client releases please open a new issue and comment its URL here.
Else it gets too confusing with so many comments here!
thanks :)