Client: Reading from keychain failed with error: No keychain service available Ubuntu 18.04

[fabianbur]

Expected behaviour

Tell us what should happen
you should save the key and detect the credentials stored in the ubuntu repository

Actual behaviour

Tell us what happens instead
it does not save the key and therefore it asks for it every time it starts or each time the client closes and it opens again.

Steps to reproduce

1. install ubuntu 18.04 in its default configuration and update everything to date.
2. install the official client owncloud according to the official instructions:
   wget -nv https://download.opensuse.org/repositories/isv:ownCloud:desktop/Ubuntu_18.04/Release.key -O Release.key
   sudo apt-key add - < Release.key

sudo sh -c "echo 'deb http://download.opensuse.org/repositories/isv:/ownCloud:/desktop/Ubuntu_18.04/ /' > /etc/apt/sources.list.d/isv:ownCloud:desktop.list"
sudo apt install owncloud-client owncloud-client-nautilus

1. open the client, enter user url and password (it does not ask for the password of the deposit of keys, as it happens in a functional version, therefore it does not keep the key in the deposit of ubuntu)

2. when closing the client and then opening it again, ask for the key with the following message: when closing the client and then opening it again, ask for the key with the following message:

Server configuration

Operating system:
Ubuntu 16.04 update
Web server:
Apache2
Database:
maryadb
PHP version:
7.0
ownCloud version:
ownCloud 10.0.7 (production)
Storage backend (external storage):

Client configuration

Client version:
Version 2.4.1 (build 9083)
Operating system:
Ubuntu 18.04
OS language:
Spanish
Qt version used by client package (Linux only, see also Settings dialog):
Qt 5.6.2, OpenSSL 1.0.2n 7 Dec 2017
Client package (From ownCloud or distro) (Linux only):
Revisión Git cd60c2 en Apr 7 2018, 14:50:40 compilada usando Qt 5.6.2, OpenSSL 1.0.2n 7 Dec 2017
Installation path of client:
/etc/ownCloud

Logs

Please use Gist (https://gist.github.com/) or a similar code paster for longer
logs.

Template for output < 10 lines

1. Client logfile: Output of owncloud --logwindow or owncloud --logfile log.txt
   (On Windows using cmd.exe, you might need to first cd into the ownCloud directory)
   (See also http://doc.owncloud.org/desktop/2.2/troubleshooting.html#client-logfile )

there are no owncloud logs that can be obtained because the client is not initialized, by manually entering the password everything works fine and the logs are generated from that moment, not before the password is detected.

1. Web server error log:

2. Server logfile: ownCloud log (data/owncloud.log):

[SamuAlfageme]

Hey @fabianbur, thanks for your report. I'll try to reproduce with 18.04 since Ubuntu might have switched to a different library not compatible with the wrapper we use (https://github.com/frankosterfeld/qtkeychain) - cc/ @frankosterfeld

Somehow related: https://github.com/owncloud/client/issues/6440

[fabianbur]

The libraries are the same as far as I know: gnome keyring and seahorse, of course they are the latest versions and the qtkeychain library, which interacts with gnome keyring to store the key, is the same for two years. Correct me if I'm wrong, but I think that qtkeychain should be updated to be compatible with the new versions with which it interacts. Another query: should I report the bug in qtkeychain? Is there a developer working at this moment in a patch or at least trying to identify the problem and then solve it? The official version of Ubuntu 18.04 comes out next week and apparently it will come out with this bug that is also present in the distribution package owncloud-client 2.4.1 + dfsg-1 as well as no response report so far: https://bugs.launchpad.net/ubuntu/+source/owncloud-client/+bug/1761936

I must say that the only way to store the key is in an update from Ubuntu 16.04 or from Ubuntu 17.10, in fact it is the way I keep working from my main machine, but a clean installation this time is impossible, I have tried in virtual machines with the results described.

Thanks for the response of @SamuAlfageme , the only one at the moment, we wait for news about the reproduction of the bug.

PD: Apologies for the English with which I write, I must confess that I do it with the Google translator, my native language is Spanish.

Las librerías son las mismas hasta donde conozco: gnome keyring y seahorse, claro que son las últimas versiones y la librería qtkeychain, que interactúa con gnome keyring para almacenar la clave, es la misma desde hace dos años. Corríjame si me equivoco, pero pienso que qtkeychain debería actualizarse para ser compatible con las nuevas versiones con las que interactúa. Otra consulta: ¿debo reportar el bug en qtkeychain? ¿existe algún desarrollador trabajando este momento en un parche o al menos tratando de identificar el problema para luego resolverlo? La versión oficial de Ubuntu 18.04 sale la próxima semana y al parecer saldrá con este bug que también está presente en el paquete de la distribución owncloud-client 2.4.1+dfsg-1 como también reporte sin respuesta hasta el momento: https://bugs.launchpad.net/ubuntu/+source/owncloud-client/+bug/1761936

Debo decir que la única forma en que se logra almacenar la clave es en una actualización desde Ubuntu 16.04 o desde Ubuntu 17.10, de hecho es la forma en que sigo trabajando desde mi máquina principal, pero una instalación limpia este momento es imposible, la he intentado en máquinas virtuales con los resultados descritos.

Gracias por la respuesta de SamuAlfageme, la única al momento, esperamos noticias sobre la reproducción del bug.

PD: Disculpas por el ingles con el que escribo, debo confesar que lo hago con el traductor de Google, mi idioma nativo es español.

[fabianbur]

I just installed it on a virtual machine with Debian SID (Ubuntu is based on Debian SID) and exactly the same thing happens. It is a bug that is occurring in more than one recent Linux distribution apparently. What is the information that is needed in addition? Maybe he's able to provide it.

[fabianbur]

I installed the client 2.3.2, the same one that works in ubuntu 17.10 and all the previous ones, thinking that it would work in ubuntu 18.04 and the same problem.

I am trying to reproduce the bug in different scenarios, I can not do more because I am not a programmer like the developers that are here. Do you need more information? Have you reported any progress in this regard?

[fabianbur]

I found a temporary solution. Or maybe not so temporary in view that I do not see progress in these areas: the official client of Nextcloud works perfectly in Ubuntu 18.04. It is a bit similar to the client owncloud 2.3 so do not try all the options that the client 2.4

I will have to stay with that client and also the thousands of users that from Thursday April 26 will update to the LTS version of Ubuntu 18.04.

Please be kind and confirm the differences between these clients, advantages, disadvantages, compatibility and incompatibility.

[ogoffart]

The nextcloud client is just a branding of the owncloud client 2.3. I cannot think of a reason why they would work and not the owncloud client.
the difference might be the qt version and the qtkeychain version.
Have you been trying 2.5 daily builds?

[ogoffart]

@SamuAlfageme have you been able to reproduce the problem?

[SamuAlfageme]

@ogoffart I've been struggling to get a properly working 18.04 VM this morning, will try the old fashioned way.

[fabianbur]

Thanks for the interest of @ogoffart @ckamm @guruz With developers of their experience I hope that a solution is soon found. @SamuAlfageme the normal way is to download the image from this address, it is easy to find the link by searching the Internet: http://cdimage.ubuntu.com/daily-live/current/bionic-desktop-amd64.iso I do not know what the "old fashioned way" The Daily Build images of Ubuntu 18.04 are considered Release Candidate from last week, will not have major differences with those of launch that will be within 48 hours and are functional for some months ago.

@ogoffart I just tried with the Daily Build 2.5 and the result is the same. The packages differ in some significant options between Nextcloud and Owncloud:
```
Nextcloud Client:
libbrotli1_1.0.3-1ubuntu1_amd64.deb
libdouble-conversion1_2.0.1-4ubuntu1_amd64.deb
libgnome-keyring0_3.12.0-1build1_amd64.deb
libgnome-keyring-common_3.12.0-1build1_all.deb
libnextcloudsync0_2.3.3-20180415.190957~bionic1_amd64.deb
libqt5core5a_5.9.5+dfsg-0ubuntu1_amd64.deb
libqt5dbus5_5.9.5+dfsg-0ubuntu1_amd64.deb
libqt5gui5_5.9.5+dfsg-0ubuntu1_amd64.deb
libqt5keychain1_0.7.0-3_amd64.deb
libqt5network5_5.9.5+dfsg-0ubuntu1_amd64.deb
libqt5positioning5_5.9.5+dfsg-0ubuntu2_amd64.deb
libqt5printsupport5_5.9.5+dfsg-0ubuntu1_amd64.deb
libqt5qml5_5.9.5-0ubuntu1_amd64.deb
libqt5quick5_5.9.5-0ubuntu1_amd64.deb
libqt5sensors5_5.9.5-0ubuntu1_amd64.deb
libqt5svg5_5.9.5-0ubuntu1_amd64.deb
libqt5webchannel5_5.9.5-0ubuntu1_amd64.deb
libqt5webkit5_5.212.0~alpha2-7ubuntu1_amd64.deb
libqt5widgets5_5.9.5+dfsg-0ubuntu1_amd64.deb
libqt5xml5_5.9.5+dfsg-0ubuntu1_amd64.deb
libwoff1_1.0.2-1_amd64.deb
libxcb-xinerama0_1.13-1_amd64.deb
nextcloud-client_2.3.3-20180415.190957~bionic1_amd64.deb
nextcloud-client-l10n_2.3.3-20180415.190957~bionic1_all.deb
qt5-gtk-platformtheme_5.9.5+dfsg-0ubuntu1_amd64.deb
qttranslations5-l10n_5.9.5-0ubuntu1_all.deb

Owncloud Client 2.3.17.10 (funciona en (Ubuntu 17.10, no en Ubuntu 18.04):
javascript-common_11_all.deb
libdouble-conversion1_2.0.1-4ubuntu1_amd64.deb
libicu57_57.1-6ubuntu0.3_amd64.deb
libjs-jquery_3.1.1-2_all.deb
libjs-sphinxdoc_1.5.6-2_all.deb
libjs-underscore_1.8.3~dfsg-1_all.deb
libowncloudsync0_2.3.2+dfsg-2_amd64.deb
libqt5core5a_5.9.1+dfsg-10ubuntu1_amd64.deb
libqt5dbus5_5.9.1+dfsg-10ubuntu1_amd64.deb
libqt5gui5_5.9.1+dfsg-10ubuntu1_amd64.deb
libqt5keychain1_0.7.0-3_amd64.deb
libqt5network5_5.9.1+dfsg-10ubuntu1_amd64.deb
libqt5opengl5_5.9.1+dfsg-10ubuntu1_amd64.deb
libqt5printsupport5_5.9.1+dfsg-10ubuntu1_amd64.deb
libqt5qml5_5.9.1-4ubuntu1_amd64.deb
libqt5quick5_5.9.1-4ubuntu1_amd64.deb
libqt5sql5_5.9.1+dfsg-10ubuntu1_amd64.deb
libqt5sql5-sqlite_5.9.1+dfsg-10ubuntu1_amd64.deb
libqt5svg5_5.9.1-2_amd64.deb
libqt5webkit5_5.9.1+dfsg-5ubuntu1_amd64.deb
libqt5widgets5_5.9.1+dfsg-10ubuntu1_amd64.deb
libqt5xml5_5.9.1+dfsg-10ubuntu1_amd64.deb
libxcb-xinerama0_1.12-1ubuntu1_amd64.deb
owncloud-client_2.3.2+dfsg-2_amd64.deb
owncloud-client-doc_2.3.2+dfsg-2_all.deb
owncloud-client-l10n_2.3.2+dfsg-2_all.deb
qt5-gtk-platformtheme_5.9.1+dfsg-10ubuntu1_amd64.deb
qttranslations5-l10n_5.9.1-1_all.deb
```
We can see that the package libqt5keychain1_0.7.0-3_amd64.deb is exactly the same, but there are other packs in Nextcloud that are not present in the Owncloud installation. Task for developers

I am sending to the emails that appear here from @ogoffart and @SamuAlfageme videos with some of the tests I have done. I am willing to collaborate in any other testing scenario, I have elementary knowledge of Linux, Debian and Ubuntu in particular, but I am not a programmer.

Gracias por el interés de @ogoffart @ckamm @guruz Con desarrolladores de su experiencia espero que pronto se encuentre una solución. @SamuAlfageme la vía normal es bajar la imagen desde esta dirección, es sencillo encontrar el vínculo buscando en Internet: http://cdimage.ubuntu.com/daily-live/current/bionic-desktop-amd64.iso Desconozco cual sea la “vieja usanza”. Las imágenes Daily Build de Ubuntu 18.04 son consideradas Release Candidate desde la semana pasada, no tendrá mayores diferencias con las de lanzamiento que será dentro de 48 horas y son funcionales desde hace algunos meses atrás.

@ogoffart acabo de probar con la Daily Build 2.5 y el resultado es el mismo. Los paquetes difieren en algunas opciones significativas entre Nextcloud y Owncloud:

Nextcloud Client:
libbrotli1_1.0.3-1ubuntu1_amd64.deb
libdouble-conversion1_2.0.1-4ubuntu1_amd64.deb
libgnome-keyring0_3.12.0-1build1_amd64.deb
libgnome-keyring-common_3.12.0-1build1_all.deb
libnextcloudsync0_2.3.3-20180415.190957~bionic1_amd64.deb
libqt5core5a_5.9.5+dfsg-0ubuntu1_amd64.deb
libqt5dbus5_5.9.5+dfsg-0ubuntu1_amd64.deb
libqt5gui5_5.9.5+dfsg-0ubuntu1_amd64.deb
libqt5keychain1_0.7.0-3_amd64.deb
libqt5network5_5.9.5+dfsg-0ubuntu1_amd64.deb
libqt5positioning5_5.9.5+dfsg-0ubuntu2_amd64.deb
libqt5printsupport5_5.9.5+dfsg-0ubuntu1_amd64.deb
libqt5qml5_5.9.5-0ubuntu1_amd64.deb
libqt5quick5_5.9.5-0ubuntu1_amd64.deb
libqt5sensors5_5.9.5-0ubuntu1_amd64.deb
libqt5svg5_5.9.5-0ubuntu1_amd64.deb
libqt5webchannel5_5.9.5-0ubuntu1_amd64.deb
libqt5webkit5_5.212.0~alpha2-7ubuntu1_amd64.deb
libqt5widgets5_5.9.5+dfsg-0ubuntu1_amd64.deb
libqt5xml5_5.9.5+dfsg-0ubuntu1_amd64.deb
libwoff1_1.0.2-1_amd64.deb
libxcb-xinerama0_1.13-1_amd64.deb
nextcloud-client_2.3.3-20180415.190957~bionic1_amd64.deb
nextcloud-client-l10n_2.3.3-20180415.190957~bionic1_all.deb
qt5-gtk-platformtheme_5.9.5+dfsg-0ubuntu1_amd64.deb
qttranslations5-l10n_5.9.5-0ubuntu1_all.deb

Owncloud Client 2.3.17.10 (funciona en (Ubuntu 17.10, no en Ubuntu 18.04):
javascript-common_11_all.deb
libdouble-conversion1_2.0.1-4ubuntu1_amd64.deb
libicu57_57.1-6ubuntu0.3_amd64.deb
libjs-jquery_3.1.1-2_all.deb
libjs-sphinxdoc_1.5.6-2_all.deb
libjs-underscore_1.8.3~dfsg-1_all.deb
libowncloudsync0_2.3.2+dfsg-2_amd64.deb
libqt5core5a_5.9.1+dfsg-10ubuntu1_amd64.deb
libqt5dbus5_5.9.1+dfsg-10ubuntu1_amd64.deb
libqt5gui5_5.9.1+dfsg-10ubuntu1_amd64.deb
libqt5keychain1_0.7.0-3_amd64.deb
libqt5network5_5.9.1+dfsg-10ubuntu1_amd64.deb
libqt5opengl5_5.9.1+dfsg-10ubuntu1_amd64.deb
libqt5printsupport5_5.9.1+dfsg-10ubuntu1_amd64.deb
libqt5qml5_5.9.1-4ubuntu1_amd64.deb
libqt5quick5_5.9.1-4ubuntu1_amd64.deb
libqt5sql5_5.9.1+dfsg-10ubuntu1_amd64.deb
libqt5sql5-sqlite_5.9.1+dfsg-10ubuntu1_amd64.deb
libqt5svg5_5.9.1-2_amd64.deb
libqt5webkit5_5.9.1+dfsg-5ubuntu1_amd64.deb
libqt5widgets5_5.9.1+dfsg-10ubuntu1_amd64.deb
libqt5xml5_5.9.1+dfsg-10ubuntu1_amd64.deb
libxcb-xinerama0_1.12-1ubuntu1_amd64.deb
owncloud-client_2.3.2+dfsg-2_amd64.deb
owncloud-client-doc_2.3.2+dfsg-2_all.deb
owncloud-client-l10n_2.3.2+dfsg-2_all.deb
qt5-gtk-platformtheme_5.9.1+dfsg-10ubuntu1_amd64.deb
qttranslations5-l10n_5.9.1-1_all.deb

Podemos ver que el paquete libqt5keychain1_0.7.0-3_amd64.deb es exactamente el mismo, pero existen otros paqutes en Nextcloud que no están presentes en la instalación de Owncloud. Tarea para los desarrolladores

Estoy enviando a los correos que acá aparecen de @ogoffart y de @SamuAlfageme videos con algunas de las pruebas que he realizado. Estoy dispuesto a colaborar en cualquier otro escenario de pruebas, tengo conocimientos elementales de Linux, Debian y Ubuntu en particular, pero no soy programador.

[ogoffart]

So what's interresting is that nextcloud depends on libgnome-keyring0_3.12.0-1build1_amd64.deb and libgnome-keyring-common_3.12.0-1build1_all.deb but not owncloud.

Can you try to install these separately?

[ogoffart]

So apparently, the nextcloud debian package has a dependency against libgnomekeyring, and the owncloud package hasnt. But this is something that should be reported downstream to your distribution as it is a bug in the distribution package.

You should try to install the official packages from https://software.opensuse.org/download/package?project=isv:ownCloud:desktop&package=owncloud-client
and see if there is this problem.

[guruz]

CC @hefee

[ckamm]

@fabianbur Are you using your distribution's package to test (the reference to 2.3.17.10 sounds like that) or using the packages from http://download.opensuse.org/repositories/isv:/ownCloud:/desktop/Ubuntu_18.04/ ?

Does installing libgnome-keyring0_3.12.0-1build1_amd64.deb and libgnome-keyring-common_3.12.0-1build1_all.deb manually help? (edit: @ogoffart also suggested that above, I see :) )

[ckamm]

Update from tests in a VM:

• I can reproduce the problem
• no libgnome-keyring* package exists in main, it has moved to universe
• the gnome-keyring package exists and is installed
• log says: Error while writing password "Could not open wallet: org.freedesktop.DBus.Error.ServiceUnknown; The name org.kde.kwalletd was not provided by any .service files

Why is it trying to connect to kwalletd? I'll check out qtkeychain code.

[ckamm]

XDG_CURRENT_SESSION=ubuntu:GNOME, DESKTOP_SESSION=ubuntu, GNOME_DESKTOP_SESSION_ID is set. Given that qtkeychain should determine DesktopEnv_Gnome - probably their GnomeKeyring::isAvailable() returns false because there is no libgnome-keyring0.so that can be loaded.

[ckamm]

@jnweiger @dschmidt For me installing libgnome-keyring0 (in universe since 18.04) fixes the problem. It should be a dependency.

[uwe347]

I had the same problem with xubuntu 18.04, which I installed three days ago (which is few days before "stable"-release) from the official bionic-repositories:
deb http://de.archive.ubuntu.com/ubuntu/ bionic main restricted
deb http://de.archive.ubuntu.com/ubuntu/ bionic-updates main restricted
deb http://de.archive.ubuntu.com/ubuntu/ bionic universe
deb http://de.archive.ubuntu.com/ubuntu/ bionic-updates universe
deb http://de.archive.ubuntu.com/ubuntu/ bionic multiverse
deb http://de.archive.ubuntu.com/ubuntu/ bionic-updates multiverse
deb http://de.archive.ubuntu.com/ubuntu/ bionic-backports main restricted universe multiverse
deb http://security.ubuntu.com/ubuntu bionic-security main restricted
deb http://security.ubuntu.com/ubuntu bionic-security universe
deb http://security.ubuntu.com/ubuntu bionic-security multiverse

...and I installed owncloud-client from the opensuse-repository:
$ wget -nv https://download.opensuse.org/repositories/isv:ownCloud:desktop/Ubuntu_18.04/Release.key -O Release.key
$ sudo apt-key add - < Release.key
$ sudo sh -c "echo 'deb http://download.opensuse.org/repositories/isv:/ownCloud:/desktop/Ubuntu_18.04/ /' > /etc/apt/sources.list.d/isv:ownCloud:desktop.list"
$ sudo apt-get update
$ sudo apt-get install owncloud-client

In this situation the owncloud-password was requested again and again at every program start.

After installing libgnome-keyring0:
$ sudo apt-get install libgnome-keyring0
http://de.archive.ubuntu.com/ubuntu bionic/universe amd64 libgnome-keyring-common all 3.12.0-1build1 [5.792 B]
http://de.archive.ubuntu.com/ubuntu bionic/universe amd64 libgnome-keyring0 amd64 3.12.0-1build1 [56,1 kB]
...it works as expected, i.e. the password is saved and is no longer requested at startup.

Thanks for delivering and describing this workaround!

[jnweiger]

thanks all. Yes libgnome-keyring0 should be a depdendency at least for Ubuntu-18.04 and up.

[fabianbur]

@ckamm I used all kinds of packages in the tests, the officers here and those of different distributions. That package reference I put it as the closest to the Nextcloud package

Effectively, in the first tests I did in Alpha versions, I referred to Kwalletd and I never knew the reason.

Thanks @ckamm this is the solution:

For the official package:

sudo apt install libgnome-keyring0 owncloud-client owncloud-client-nautilus

Hopefully it is included as a dependency and the bug is fixed in 2.4.2 and following.

Why has not it been marked as a bug?
Is not a bug not considered to include such an important dependency in the package? Also considering that the Nextcloud client has included it correctly.

PS: We are at different times apparently: around five hours less than GMT

@ckamm usé todo tipo de paquetes en las pruebas, los oficiales de acá y los de diferentes distribuciones. Esa referencia de paquetes la puse por ser la más parecida al paquete de Nextcloud

Efectívamente, en las primeras pruebas que hice en versiones Alpha remitía a Kwalletd y nunca supe la razón.

Gracias @ckamm esta es la solución:

Para le paquete oficial:

sudo apt install libgnome-keyring0 owncloud-client owncloud-client-nautilus

Esperemos que se incluya como dependencia y se arregle el bug en 2.4.2 y siguientes.

¿Por qué no se lo ha marcado como bug?
¿No se considera un bug no incluir una dependencia tan importante en el paquete? Considerando también que el cliente de Nextcloud si la ha incluido de forma correcta.

PD: Estamos en diferentes tiempos al parecer: por acá cinco horas menos que GMT

[fabianbur]

Thanks again to everyone. I just checked that in all versions of Debian up to 9 and Ubuntu until 17.10, it is installed by default libgnome-keyring0

In the current Debian SID (Ubuntu is based on Debian SID) is no longer installed by default, I ignore the reason.

Mark the dependency on the package is necessary this moment only in Ubuntu 18.04 and following. Debian 9 does not need it, but future versions do. I think it would not be a bad idea to mark that dependence always. If it is already installed, nothing would happen and if it is not installed, a bug is avoided.

Gracias de nuevo a todos. Acabo de comprobar que en todas las versiones de Debian hasta la 9 y de Ubuntu hasta la 17.10, se instala por defecto libgnome-keyring0

En el actual Debian SID (Ubuntu está basado en Debian SID) ya no se instala por defecto, ignoro el motivo.

Marcar la dependencia en el paquete es necesario este momento solo en Ubuntu 18.04 y siguientes. Debian 9 no lo necesita, pero las versiones futuras sí. Pienso que no sería mala idea marcar esa dependencia siempre. Si ya se encuentra instalada, no pasaría nada y si no se encuentra instalada, se evita un bug.

[jnweiger]

Tomorrows rebuild of https://software.opensuse.org//download.html?project=isv%3AownCloud%3Adesktop%3Adaily%3A2.5&package=owncloud-client
should have the libgnome-keyring0 dependency.

[severalthings]

Will there be a bugfix (backport) to 2.4.1? When will 2.5 be released to the public? Will it be days, weeks or months from now?
Thanks for all the work done here!!!

[jnweiger]

Can someone please confirm the patch works?
Then I'll trigger a rebuild of the 2.4.1 client for Ubuntu 18.04 with that patch.

[fabianbur]

It works perfect. I just tried it on Ubuntu 18.04. Thank you.

[jnweiger]

Thanks @fabianbur
Rebuild complete:
https://software.opensuse.org//download.html?project=isv%3AownCloud%3Adesktop&package=owncloud-client#manualUbuntu

[fabianbur]

Installed version 2.4.1 (build 9083) from the official packages in Ubuntu 18.04.

Expected behaviour in a clean environment.

Hopefully, the client of the distribution will also be fixed soon as it appears in this bug reported: https://bugs.launchpad.net/ubuntu/+source/owncloud-client/+bug/1761936

I close the incident by reiterating the thanks on behalf of Ubuntu and Owncloud users.

Instalada la versión 2.4.1 (build 9083) desde the official packages en Ubuntu 18.04.

Comportamiento esperado en un entorno limpio.

Esperemos que el cliente de la distribución también sea arreglado pronto tal como consta en este bug reportado: https://bugs.launchpad.net/ubuntu/+source/owncloud-client/+bug/1761936

Cierro la incidencia reiterando el agradecimento en nombre de los usuarios de Ubuntu y de Owncloud.

[guruz]

@severalthings are you still needing help?
Did installing libgnome-keyring0 improve things?

2.5.0 alpha is coming in the next 1-2 weeks

[severalthings]

@guruz: I'm fine. The patched 2.4.1 works for me. No manuall installation of libgnome-keyring0 necessary any more.

[olberger]

Can anyone please reference the patch in question ? I fear Debian is still affected (testing) ATM

[olberger]

Btw, AFAIU, libgnome-keyring0 may disappear from Debian soon (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=892359) ... is this problematic for owncloud client in Debian and Ubuntu ?

Thanks in advance.

[HorlogeSkynet]

Hi, I'm running Debian testing (Buster) ATM, and this is definitely problematic for Owncloud / Nextcloud clients...

[guruz]

Sounds like this issue: https://github.com/frankosterfeld/qtkeychain/issues/37
(ownCloud client is using QtKeychain)

[guruz]

Maybe it's just about having QtKeychain compiled properly?
https://github.com/akallabeth/qtkeychain/blob/master/CMakeLists.txt#L120
(Note this is relevant for our own binary packages and for the packages from Debian/Ubuntu).

Maybe a Linux developer can investigate further -> @ogoffart @ckamm @jnweiger FYI.

[HorlogeSkynet]

I've just installed libqtkeychain1 and qtkeychain-dev packages on the testing : same issue.

EDIT : 'keep trying with the Nextcloud client, naively assuming this part has not changed after the fork !

[ckamm]

So if gnome-keyring gets removed in favor of libsecret, can we somehow tell QtKeychain to use the libsecret backend? @guruz had also pointed me towards https://github.com/frankosterfeld/qtkeychain/pull/103

I'll look at it tomorrow. Maybe you can try adding backend=libsecret to /etc/xdg/qt5-keychain.conf to check whether forcing the other backend would work? - but as pointed out above, maybe QtKeychain is built without libsecret support.

[ckamm]

Never mind on the config file, that PR wasn't yet merged.

[ckamm]

However, libqtkeychain automatically prefers the libsecret backend if it can load it.

@jnweiger It looks like qtkeychain has libsecret support enabled by default, but it only gets compiled in if the libsecret headers are availabe. That means you probably want to add libsecret-1-dev to the environment where qtkeychain gets built.

With that done, my qtkeychain now tries to use libsecret and only falls back to gnome/kde keychains if it can't be reached.

Steps:

• Make sure that qtkeychain is build with libsecret support by having libsecret-1-dev available
• Ubuntu < 18.04: depend on libgnome-keyring (done)
• Ubuntu >= 18.04: depend on libsecret-1-0, remove dep on libgnome-keyring (it is still available but moved to universe, will probably be dropped eventually)
• Similarly for some debian versions, I don't know the details

[olberger]

I fear there's an issue with compiling qtkeychain with libsecret, as mentioned in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=866308 which refers to https://github.com/frankosterfeld/qtkeychain/issues/99

This needs some expertise as I'm just reading reports without any competence in these programs ;-)

[jnweiger]

compiling on 18.04 with

[   75s] [365/365] installing libsecret-1-dev-0.18.6-1
...
[   78s] -- Checking for module 'libsecret-1'
[   78s] --   Found libsecret-1, version 0.18.6
...
[   85s] [ 61%] Building CXX object CMakeFiles/qt5keychain.dir/libsecret.cpp.o
[   85s] /usr/bin/c++  -DHAVE_LIBSECRET=1 -DQT_CORE_LIB -DQT_DBUS_LIB -DQT_NO_DEBUG -Dqt5keychain_EXPORTS -isystem /opt/ownCloud/qt-5.10.1/include/x86_64-linux-gnu/qt5 -isystem /opt/ownCloud/qt-5.10.1/include/x86_64-linux-gnu/qt5/QtDBus -isystem /opt/ownCloud/qt-5.10.1/include/x86_64-linux-gnu/qt5/QtCore -isystem /usr/../opt/ownCloud/qt-5.10.1/lib/x86_64-linux-gnu/qt5/mkspecs/linux-g++-64 -I/usr/src/packages/BUILD/obj-x86_64-linux-gnu -I/usr/include/libsecret-1 -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include  -g -O2 -fdebug-prefix-map=/usr/src/packages/BUILD=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -O2 -g -DNDEBUG -fPIC   -Wall -fPIC -std=gnu++11 -o CMakeFiles/qt5keychain.dir/libsecret.cpp.o -c /usr/src/packages/BUILD/libsecret.cpp
...
[   95s] /usr/bin/c++ -fPIC -g -O2 -fdebug-prefix-map=/usr/src/packages/BUILD=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -O2 -g -DNDEBUG -Wl,-Bsymbolic-functions -Wl,-z,relro -shared -Wl,-soname,libqt5keychain.so.1 -o libqt5keychain.so.0.8.90 CMakeFiles/qt5keychain.dir/keychain.cpp.o CMakeFiles/qt5keychain.dir/keychain_unix.cpp.o CMakeFiles/qt5keychain.dir/gnomekeyring.cpp.o CMakeFiles/qt5keychain.dir/libsecret.cpp.o CMakeFiles/qt5keychain.dir/plaintextstore.cpp.o CMakeFiles/qt5keychain.dir/kwallet_interface.cpp.o CMakeFiles/qt5keychain.dir/moc_keychain.cpp.o CMakeFiles/qt5keychain.dir/moc_keychain_p.cpp.o CMakeFiles/qt5keychain.dir/moc_gnomekeyring_p.cpp.o -Wl,-rpath,/opt/ownCloud/qt-5.10.1/lib/x86_64-linux-gnu -lsecret-1 -lgio-2.0 -lgobject-2.0 -lglib-2.0 /opt/ownCloud/qt-5.10.1/lib/x86_64-linux-gnu/libQt5DBus.so.5.10.1 /opt/ownCloud/qt-5.10.1/lib/x86_64-linux-gnu/libQt5Core.so.5.10.1 

that should do the trick, I hope...
submitted to: https://build.opensuse.org/package/show/isv:ownCloud:Qt5101/ocqt5101-qt5keychain

[ckamm]

@jnweiger I got the updated ocqt5101-libqt5keychain1 and that's talking to libsecret.

Now, that's not entirely great - it doesn't look like the libsecret keychain is unlocked on login on kde, so it asks for the keychain password now. But the most-used vanilla ubuntu 18.04 configuration should do the right thing.

[jnweiger]

I read about that KDE issue. There is a 12 months lingering upstream issue. Can a KDE user workaround? like disable libsecret in the config file or something?

I could make two different keychain packages, one with and one without libsecret support, but I fear the installer cannot decide which one to pull in. ubuntu 18.04 can be both, gnomish or KDEish...

[ckamm]

@jnweiger Currently the only workaround I see would be uninstalling libsecret. Maybe we can help with getting https://github.com/frankosterfeld/qtkeychain/pull/103 merged such that users can have some control over backend choice at least.

[guruz]

Thanks @ckamm @jnweiger for fixing.
And thanks @olberger for bringing the issue up.

@ckamm Manual control (https://github.com/frankosterfeld/qtkeychain/pull/103) sounds good. But what about automatic fallback so it "just works"?

[ckamm]

@guruz Currently the backend choice in qtkeychain can't be influenced by us. So our builds either need to have libsecret enabled at compile time or not. Since gnome-ubuntu probably is the most widely used variant, I'd say we should have it compiled in.

@olberger @jnweiger Reading that Debian ticket about removing libgnome-keyring: so it would be correct to have libsecret support enabled in the Debian 10 builds (I don't think those exist yet)? Is libgnome-keyring already deprecated in Debian 9, and libsecret installed by default?

[jnweiger]

@ckamm on my ubuntu 18.04 with plasma KDE the kdewallet gets used correctly. owncloud-client 2.5.0-alpha1 with my new keychain 0.8.90 prompts to open the wallet, an if I allow that, it retrieves the password and starts syncing. if I let the dialogue hang there for several minutes an error pops up.

so I cannot reproduce errors with this. Will retry with a vanilla 18.04 where no plasma was installed.

[ckamm]

@jnweiger I get similar behavior. libsecret works on kde, but it shows an additional "open the wallet" message box where I'm asked for the password. That doesn't happen with the kwallet backend.

[ckamm]

@jnweiger Looking into this more: libsecret seems to talk to gnome-keyring-daemon on kubuntu 18.04. I think we want to prefer continuing to talk to kwallet.

[olberger]

@ckamm I don't know about the Debian packages (being a DD but now following current transitions in this area). Asking by mail in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=892359 would be a way to know... and/or talking to the Debian maintainers of owncloud-client: see https://tracker.debian.org/pkg/owncloud-client .

Hth,

[ckamm]

@hefee Would you be up for checking out the debian side of things? (https://github.com/owncloud/client/issues/6455#issuecomment-397215608 in particular)

[ckamm]

@jnweiger There will likely be changes to qtkeychain to make this work more smoothly on kde. Will let you know when that's ready.

[jnweiger]

@guruz @michaelstingl there is a 242-maybe milestone here. If that backport is needed, please give me a timely heads up. there is no testing branch in obs for 2.4.x as testing is occupied by 2.5.0 already.

[michaelstingl]

If we decide for a 2.4.2 before 2.5.0, it would be cool to have this included

[hefee]

Well the issue is a qtkeychain issue and can't been solved within owncloud-client.

And for me frankosterfeld/qtkeychain#99 is a blocker to update qtkeychain for Debian/Ubuntu. At the moment I have to choose either support KDE users (with the current build) or GNOME users (enabling libsecret support). So please help qtkeychain to solve this issue properly so both can happily use qtkeychain!

For Debian stable (9) there is qtkeychain 0.7.0-3 (there is no libsecret support in that version at all :)
But because GNOME version is also not updating in stable everything working smooth for Debian stable users.
For Debian testing and Debian unstable the version of qtkeychain is the same, so we have unhappy GNOME users.

[ckamm]

@hefee Thanks! We're working to get out of this dilemma with frankosterfeld/qtkeychain#111. Hopefully the version of QtKeychain in Debian could update then, and owncloud could use the appropriate keystore on both kde and gnome.

[guruz]

https://github.com/frankosterfeld/qtkeychain/pull/111 is merged.
But no release has been tagged. :/ https://github.com/frankosterfeld/qtkeychain/releases
CC @frankosterfeld

[guruz]

@hefee @jnweiger There is a 0.9.0 of qtkeychain now. https://github.com/frankosterfeld/qtkeychain/releases/tag/v0.9.0

[jnweiger]

pushed 0.9.0 into https://build.opensuse.org/package/show/isv:ownCloud:Qt5101/ocqt5101-qt5keychain and internal build service

[ckamm]

This issue is fixed in qtkeychain 0.9.0 which will be used by the 2.5 builds in the future. Please test with the build @jnweiger linked!

[jnweiger]

Ubuntu 18.04 + 16.04 vanilla VMs

sudo apt install owncloud-client-nautilus

owncloud-client version 2.5.0daily20180601

Version of installd qtkeychain should be 0.9+
OK: ocqt5101-libqt5keychain1-0.9.0-1+2.1

We should pull in libgnome-keyring0 with ubuntu 16.04
OK, and libsecret-1-0 is also installed.

We should pull in libsecret-1-0 with ubuntu 18.04

OK: gnome-keyring can be removed, libgnome-keyring0 was not installed.
libsectet-1-0_0.18.6-1 is installed due to 60 other dependencies,
BUT: no direct dependency from owncloud-client though, good enough.

Login Keyring password is queried once, after entering the initical credentials.
OK
BUT: not asked on ubuntu 16.04

After quit and restarting the client, system does not ask for password. Syncing starts automatically.
OK, even on ubuntu 16.04, despite there was no login keyring password asked.
BUT: After an explicit logout, login, the password is asked for.

Logs should not say 'Error while writing password "Could not open wallet: org.freedesktop.DBus.Error.ServiceUnknown; The name org.kde.kwalletd was not provided by any .service files'
OK: wallet does not appear in the F12 log after loging in.

check if libsecret-1-dev headers were used when compiling our own qtkeychain.
OK: Checking for module 'libsecret-1' Found libsecret-1, version 0.18.4 (ubuntu 16.04)
OK: Checking for module 'libsecret-1' Found libsecret-1, version 0.18.6 (ubuntu 18.04)