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:
- /usr/bin/kwalletd5
- /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
