SUMMARY When starting kmail over ssh on a remote host, kmail doesn't send any mail, it asks for the transport password instead. This is at least when there still is a local KDE desktop session running on the remote host, even when kmail and akonadi are not running. STEPS TO REPRODUCE 1. Log into host A, KDE desktop session. 2. Start kmail. 3. Quit kmail, stop akonadi. 4. Log into host B, KDE desktop session. 5. ssh from B to A. 6. Start kmail on A, compose mail, send. 6b. pkill kwallet; Start kmail on A, compose mail, send (no difference; kmail may or may not ask for the wallet password, but even if it does, it still asks for the transport password when sending). OBSERVED RESULT kmail asks for the password for the mailtransport. EXPECTED RESULT Mail is sent without more pop-ups, the mailtransport password is already saved in the wallet. SOFTWARE/OS VERSIONS kmail Version 5.19.3 (21.12.3) openSUSE Leap 15.4 kded-5.90.0-150400.1.4.x86_64 Qt Version: Name : libQt5Core5 Version : 5.15.2+kde294 Release : 150400.6.3.1 ADDITIONAL INFORMATION This used to work fine on openSUSE 12.3, kmail 4.10.5; kmail didn't even have to be quit, only akonadi had to be stopped.
If I don't redirect stdout/err of the kmail started over ssh, there is a bunch of these on the screen when clicking "send": We have an error during reading password "The name org.freedesktop.secrets was not provided by any .service files" It looks to me like somehow kmail isn't finding the wallet, although the wallet is running and can be opened, showing expected content.
(In reply to Volker Kuhlmann from comment #1) > If I don't redirect stdout/err of the kmail started over ssh, there is a > bunch of these on the screen when clicking "send": > > We have an error during reading password "The name org.freedesktop.secrets > was not provided by any .service files" This error means that something is looking for the Secret Service API on DBus, while that service is not running. DBus is trying to auto-start it, but can't find any files that define how. The Secret Service API was "traditionally" provided by Gnome keyring daemon. There was initial support added for it in KWallet very recently, but it doesn't include DBus auto-start files yet. (There are also a few other possible providers.) 1. Do you, or did you previously have Gnome keyring installed on this system? 2. What version is your KDE Frameworks? 3. If it's 5.97 or later, do you have Secret Service enabled in the KWallet settings? 4. Are you using a blowfish or GPG wallet? (Might be related to Bug 458085 if it's a GPG wallet.) 5. What happens if you try to send a mail locally (not via ssh)? In any case, it is strange that kmail is looking specifically for the Secret Service API, and is not falling back to the old KWallet API when it's not available... (or maybe it does, and the actual problem is elsewhere?) > This used to work fine on openSUSE 12.3, kmail 4.10.5; Those are pretty ancient.
> 1. Do you, or did you previously have Gnome keyring installed on this system? No, I never install anything gnome explicitly. openSUSE 15.4 KDE desktop. This is also a clean new install with an empty user account, without any old ~/.config/, ~/.local/. > 2. What version is your KDE Frameworks? See versions, kded rpm. kmail help -> about doesn't say. systemsettings -> about says Operating System: openSUSE Leap 15.4 KDE Plasma Version: 5.24.4 KDE Frameworks Version: 5.90.0 Qt Version: 5.15.2 Kernel Version: 5.14.21-150400.24.28-default (64-bit) Graphics Platform: X11 > 3. If it's 5.97 or later, do you have Secret Service enabled in the KWallet settings? It's 5.90. There is nothing about secret service in systemsettings -> KDE wallet that I can see. > 4. Are you using a blowfish or GPG wallet? (Might be related to Bug 458085 if it's a GPG wallet.) How do I find out which it is? There is a ~/.local/share/kwalletd/kdewallet.kwl It's likely not gpg, gpg --list-keys is empty. > 5. What happens if you try to send a mail locally (not via ssh)? "Locally" is ambiguous here. I am logged into A from B via ssh when the problem occurs, kmail running on A via ssh. When I quit the kmail started via ssh, stop akonadi, pkill kwallet, then go back to host A and start kmail on the KDE desktop session, kmail must be starting the wallet because something asks for the *wallet* password for "mailtransports", and everything works as expected. When I quit kmail, stop akonadi and kill the wallet on A, then log into A from B via ssh and start kmail, kmail does NOT ask for the wallet password, but then asks for the password for the SMTP server that's configured for the mail being sent, when clicking on "send". Note the interactive desktop session remains running on host A, but kmail and akonadi are stopped. Leaving the wallet running on A or not makes no difference, kmail doesn't open the wallet maybe? > > This used to work fine on openSUSE 12.3, kmail 4.10.5; > Those are pretty ancient. Agreed! But they provide the Unix mantra of things still working as expected when $DISPLAY is different! Currently, kmail is only capable of single-user machine stuff :-(.
That is some useful info, thank you. Since it's 5.90, there is no Secret Service code in KWallet in that version, and kmail should not be asking for Secret Service either. It also shouldn't matter whether it's a blowfish or GPG wallet. You can try to check exactly which process is asking for Secret Service by running `dbus-monitor "destination=org.freedesktop.secrets"` and checking the sender bus ID (which should look something like "sender=:1.137") with e.g. `busctl --user` while that process is still running. When you run kmail from machine B through SSH, I'm guessing you're using the CLI (not a GUI remote desktop)? Whereas when you tried to run it directly from A's KDE session (without SSH), did you use the GUI? If so, that may be the source of the difference. Try running it from a command line terminal on A... (there might also be a difference between a CLI terminal inside the desktop session vs a separate TTY session).
Thank you, I will get you the details when starting kmail from a terminal on B asap. Yes, on A it's an interactive KDE desktop session, with kmail started from the launcher (button in lower left corner of the screen). When I quit kmail, stop akonadi, pkill -e kwallet, and then start kmail from the konsole shell, it behaves as expected and as if started from the launcher, asking for the wallet password and sending emails without problems. If this is not what you meant me to try on A (I won't try the text console ctrl-alt-f3 or so... ;-) ), could you please clarify? Thank you.
(In reply to Volker Kuhlmann from comment #5) > When I quit kmail, stop akonadi, pkill -e kwallet, and then start kmail from > the konsole shell, it behaves as expected and as if started from the > launcher, asking for the wallet password and sending emails without problems. > If this is not what you meant me to try on A (I won't try the text console > ctrl-alt-f3 or so... ;-) ), could you please clarify? Thank you. Just to clarify, what I meant was taking the steps that you do though SSH from B, and doing those same steps from the local konsole on A. Sounds like that's indeed what you did here. Trying the same steps from a text console on A (ctrl-alt-f3 or etc) is also interesting, since I *think* that mimics closer how an SSH session would behave. AFAIK, an SSH session doesn't actually connect to your running desktop session on the host (A), but instead creates a new text session. Anyway, all of this is just trying to double-check whether it's really the SSH's fault, or just text vs GUI.
I don't understand why testing this from a text console has any merit. A Linux text console (e.g. ctrl-alt-f3) can only render characters, not graphics. The DISPLAY variable is undefined. No X-application is going to start. If you must, the kmail error is: > kmail qt.qpa.plugin: Could not load the Qt platform plugin "xcb" in "" even though it was found. This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem. Available platform plugins are: eglfs, linuxfb, minimal, minimalegl, offscreen, vnc, wayland-egl, wayland, wayland-xcomposite-egl, wayland-xcomposite-glx, xcb. This was predictable (and it's a pretty bad error message after doing something stupid). E.g. trying to start an xterm: > xterm xterm: Xt error: Can't open display: xterm: DISPLAY is not set The error message is spot on. This will work when the earth stops spinning.
(In reply to Volker Kuhlmann from comment #7) > I don't understand why testing this from a text console has any merit. A > Linux text console (e.g. ctrl-alt-f3) can only render characters, not > graphics. ... AFAIK, an SSH session is also text only. Hence I expect them to behave the same. But maybe I'm wrong. It's understandable that you can't launch GUI stuff in text-only, but some applications have CLI mode or dedicated CLI tools. I don't know if kmail does or not, but somehow you are trying to launch it through SSH. (I guess it's worth mentioning that I am not a kmail developer. Just trying to narrow down the bug.)