Reading from keychain failed with error: No keychain service available Ubuntu 18.04 #6455
Comments
|
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: #6440 |
|
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. |
|
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. |
|
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? |
|
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. |
|
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. |
|
@SamuAlfageme have you been able to reproduce the problem? |
|
@ogoffart I've been struggling to get a properly working 18.04 VM this morning, will try the old fashioned way. |
|
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: 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: Owncloud Client 2.3.17.10 (funciona en (Ubuntu 17.10, no en Ubuntu 18.04): 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. |
|
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? |
|
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 |
|
CC @hefee |
|
@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 |
|
Update from tests in a VM:
Why is it trying to connect to |
|
|
|
@jnweiger I got the updated 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. |
|
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... |
|
@jnweiger Currently the only workaround I see would be uninstalling libsecret. Maybe we can help with getting frankosterfeld/qtkeychain#103 merged such that users can have some control over backend choice at least. |
|
Thanks @ckamm @jnweiger for fixing. @ckamm Manual control (frankosterfeld/qtkeychain#103) sounds good. But what about automatic fallback so it "just works"? |
|
@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? |
|
@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. |
|
@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. |
|
@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. |
|
@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, |
|
@hefee Would you be up for checking out the debian side of things? (#6455 (comment) in particular) |
|
@jnweiger There will likely be changes to qtkeychain to make this work more smoothly on kde. Will let you know when that's ready. |
|
@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. |
|
If we decide for a 2.4.2 before 2.5.0, it would be cool to have this included |
|
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 :) |
|
@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. |
|
frankosterfeld/qtkeychain#111 is merged. |
|
@hefee @jnweiger There is a 0.9.0 of qtkeychain now. https://github.com/frankosterfeld/qtkeychain/releases/tag/v0.9.0 |
|
pushed 0.9.0 into https://build.opensuse.org/package/show/isv:ownCloud:Qt5101/ocqt5101-qt5keychain and internal build service |
|
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! |
Ubuntu 18.04 + 16.04 vanilla VMssudo apt install owncloud-client-nautilus owncloud-client version 2.5.0daily20180601 Version of installd qtkeychain should be 0.9+ We should pull in libgnome-keyring0 with ubuntu 16.04 We should pull in libsecret-1-0 with ubuntu 18.04 OK: gnome-keyring can be removed, libgnome-keyring0 was not installed. Login Keyring password is queried once, after entering the initical credentials. After quit and restarting the client, system does not ask for password. Syncing starts automatically. 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' check if libsecret-1-dev headers were used when compiling our own qtkeychain. |
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
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
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)
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 linesowncloud --logwindoworowncloud --logfile log.txt(On Windows using
cmd.exe, you might need to firstcdinto 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.
Web server error log:
Server logfile: ownCloud log (data/owncloud.log):
The text was updated successfully, but these errors were encountered: