# KdeWallet, and Using Smb4K, under Plasma 5

One fact which I’ve written about before, is that I have an up-to-date Linux computer, that uses the ‘Plasma 5′ desktop manager, which is actually the successor to ‘KDE 4′. When using this desktop manager, we can still install numerous packages that ‘belong’ to the old, KDE 4, and most of them will continue to work. One of those is ‘smb4k’, which is a point-and-click utility, to mount a network SMB share – aka, a Windows-file-share, such that it will be visible in our home folder, as though that share was a local sub-folder.

There exist command-line methods to do the same thing, which would mount that network share, and declare it’s of the ‘cifs’ file-system-type, but the use of a simple GUI to do so may be easier.

But then one problem which ensues, is that Smb4K will use the KDE 4 Wallet, to store our password, for that share. It will function in this way, by depending on the package ‘kde-runtime’. In truth, this latter package probably pulls in numerous (old) KDE 4 libraries, and not just the old KWallet, but the existence of this KDE 4 Wallet, on our Plasma 5 machine, is most obvious…

Smb4K still works! But, once it has been used, we end up with two KDE Wallets running at the same time:

1. /usr/bin/kwalletd5
2. /usr/bin/kwalletd

Some people might find that this is an unacceptable situation by its nature, but I’ll highlight one important reason, fw this could be a problem: ‘Debian 9′ / ‘Debian Stretch’, no longer provides us with a wallet-management application, that connects to the old, KDE 4 Wallet. Such a management application will ultimately be important, because we’ll want to state what the policy of the wallet is, regarding how long it should stay open, which applications may access it, without requiring a password reprompt, if it’s still open, etc.. As it is, this KDE 4 Wallet will have some initial settings, based on dialogs which appeared briefly, and which we may no longer modify, once they have been set, because an application chose to use, the KDE 4 Wallet. And so we could end up with the following result:


dirk@Plato:~$ps fu -A | grep wallet dirk 1997 0.0 0.5 601024 68132 ? SLl Feb22 0:04 \_ /usr/bin/kwalletd5 dirk 540 0.5 0.5 606148 68852 ? Sl 14:39 0:00 | | \_ /usr/bin/kwalletmanager5 dirk 670 0.0 0.0 12784 984 pts/0 S+ 14:40 0:00 \_ grep --color=auto wallet dirk 628 1.1 0.2 288824 36284 ? SL 14:39 0:00 /usr/bin/kwalletd dirk@Plato:~$




My main priority here would be, that ‘/usr/bin/kwalletd’ would just stay open, and no longer require a password reprompt, before a user can just remount the remote share. And so at this moment, I’d solve that issue, with the command:

kill -15 628

Because my command was a ‘kill -15′, the KDE 4 Wallet closes, gracefully.

I suppose that a user would need to make sure, not to enter the following command:

killall kwalletd

Because that command, would actually kill both wallets! Unless, that’s really what a user wants to do.

I’ve created a little shell-script, which facilitates this:

#!/bin/bash

PID=ps fu -A | grep 'kwalletd$' | gawk '{print$2}' -
kill -15 \$PID




There’s only one little caveat in using this script (as user):

If we still have Smb4K running, while we click on this script, then Smb4K will ‘remember’ the PID which was once the KDE 4 Wallet, because by default, these wallets belong to the session, and their PIDs should be persistent. In that case, if we additionally try to mount another share, then Smb4K will detect that the wallet has died, and will prompt the user for his full credentials.

I can find no settings in the Smb4K GUI, to quit the application once all shares are closed.

And so, actually closing Smb4K is a good user-policy, every time the user decides ‘to kill a wallet’.

Dirk

This site uses Akismet to reduce spam. Learn how your comment data is processed.