It is possible to mistake a configuration file for a shell script.

One source of error which I’ve observed, was even recommended in the old ‘linpopup’ package documentation.

ICYMI, “Linpopup” was a Linux extension to the Samba server, meant to allow messages to be passed directly from one computer to another on a LAN. It was based on the old “WinPopup” feature, which Microsoft discontinued with Windows XP (Service Pack 2 ? )

I think that one of the problems with the original WinPopup was, that its messages were allowed to be rich text, including URLs, which users were tricked into clicking on, because users did not recognize that pop-up windows they were getting, were in fact intended as a feature, but that these messages were eventually sent out to blocks of IP addresses as a form of spam, sometimes carrying a payload of malware.

Unlike its Windows predecessor, LinPopup only allows Plain Old Text to be sent. But this posting is not meant to describe this, as a feature of Samba. I’m intending to showcase this as an example of a type of mistake, which modern-day thinkers make when creating configuration files. In order to ready a Samba server to receive these messages, a Linux user is given the suggestion to put the following into their /etc/samba/smb.conf, near the end of their [global] section:

message command = /usr/local/bin/LinPopUp "%f" "%m" %s; rm %s

I know this, because I custom-compiled the old package, and this was stated in the documentation.

Now, it is possible to configure some other program to receive the message, which Samba leaves in the temporary file ‘%s’, as long as we remember that any message command which Samba runs, will be run as user ‘nobody’, with the privileges of user ‘nobody’. That’s not a problem. But there is a problem with this configuration line, which users ran in to, and which users had trouble pinpointing.

This is meant for a configuration file, but the above syntax would be suitable for a shell script. A configuration file will often allow for an executable program to be specified, and will even go so far as to allow command-line parameters to be passed in. But a configuration file will not go so far, as to allow two programs to be executed in sequence. That is a luxury which too many modern coders take for granted, apparently.

The two programs referred to above are



In fact, this configuration mistake will pass in the semicolon, as part of the parameters to /usr/local/bin/LinPopUp , thereby mangling the ability of this program to identify the file the message is in. And then it will pass in the string “rm” as well…

What I had to do myself, was something like

message command = bash -c '/usr/local/bin/linpopup "%f" "%m" %s ; rm %s' &

The one program I’m telling Samba to run, is ‘bash’. It, in turn, can run several other programs synchronously, asynchronously, etc..

Also, it should be noted that the ‘&’ at the end of my line, is not equivalent to its use in shell scripts, where it tells a running instance of ‘bash’, to disconnect the child process immediately, and to continue running the rest of the script. My ‘&’ does not assume that ‘bash’ is already running, and appears as a parameter to ‘bash’ itself.

For all I know, ‘bash’ could simply ignore this. But I do know, that this ‘&’ does not interfere in my message command working…


(Edit : ) And, It is up to the way the Samba server parses its configuration file, whether it expands the variables, which begin with ‘%’ , inside single quotes. It doesn’t matter that ‘bash’ would not do so.


Possible Solution to ‘Dropbox Missing Systray Icon’ under KDE

Just yesterday I installed the proprietary version of “Dropbox” on my ‘Debian / Jessie’ computer named ‘Phoenix’. I had the extra HD space to spare, and also had an existing Dropbox account to link to. But what I soon noticed, was the fact that I was suffering from the same problem many other users of ‘KDE 4′ were having with the newest Dropbox for Linux.

It seems that the Linux versions of Dropbox are tuned to work best under ‘Ubuntu’, not ‘Debian’. And in General, Ubuntu uses either ‘GNOME’ or ‘Unity’ as its desktop manager, which leaves many KDE users having to use the official Command Line Interface for Dropbox.

Mind you, this CLI is not bad as those go, but missing the System Tray Icon was annoying me. I had to install ‘libappindicator…’ as well as ‘python-appindicator’ from the package manager, and even after having done that, and after having restarted Dropbox using the CLI, the systray icon did not appear for me, because in recent Dropbox versions, only the ‘Nautilus’ support is included. Nautilus is the Ubuntu / GNOME counterpart, for what ‘Dolphin’ does under KDE. Luckily, there is an open-source Dolphin plugins package named


But that package assumes we already have Dropbox installed, and does not affect the system tray.

Further, I was disappointed by the fact that most of the other complaints I could Google involved KDE 5, while I needed to solve this problem with KDE 4.

And so after doing some more reading, I wrote the following script:

(Edit 03/31/2016 : ) I would like to thank Darwin Silva, who suggested a solution below, which works better for me, than the solution which I had first posted. Specifically, the solution by Mr. Silva allows Dropbox to animate the icon correctly, to show its status. I apologize for taking so long to test Mr. Silva’s solution, but often have limited time to go after all the things I should be doing on my own computers:


# "Restart"

# Allow Dropbox 3.14.7 to show a system-tray icon.
# Works under KDE 4.14...
# Only drawback: Icon has generic page as image.
# Systray Icon Context Menu fully functional.


dropbox stop

sleep 30

dbus-launch dropbox start

This seems to have done the trick for me. But be warned: This will serve us at best, Until the Next Reboot. Possibly, this script may need to be run more often. There is a workaround which fully automates that problem, but that workaround was not worth my while.

It may be possible to edit


But doing so is pointless, because Dropbox will overwrite that file, every time it updates itself…



I needed to remove the Samba share, which was forcing encryption.

Yesterday I had created a special Samba share which set SMB encryption to ‘mandatory’, for testing purposes.

Today I removed it again, because the risk was great that I might just click on it from my Windows 7 client named ‘Mithral’, and doing so would mess up the client.

So my default assumption for now is, that all my Samba sharing is unencrypted, with the possible exception of what has been requested by the Windows 8 laptop ‘Maverick’, because the default on the server remains

smb encrypt = auto



Forcing Samba Encryption from the Server

(This article corresponded to the best of my knowledge, on February 16, 2016. Please forgive me as I will correct some of my mistakes, and yield a more-satisfying answer to my own question… )

I have recently been digging into the settings of my /etc/samba/smb.conf file, in an effort to tighten up its security.

One fact about Samba which I don’t particularly like, is that too many options are controlled from the client. Thus, on my Samba 3.2 client I had the [Global] option set as a default:

client use spnego = yes

What this did successfully, was secure the way in which the password is authenticated, without exposing it. It causes the server to invoke Kerberos. Additionally, it is possible to set

client NTLMv2 auth = yes

which is default on Samba 4, but which was not set by default on Samba 3 clients. This asks the server for NTLMv2 if available, which is the Windows default for SMB2. It was not set in older Samba clients, to improve compatibility with older SMB shares.

( 03/26/2018 :

The above paragraph really just stated a misconception of mine. The order in which authentication schemes have evolved, are something like:

  1. LAN-Man, aka NTLMv1, NTLMv2,
  2. SMB1, aka NT1,
  3. SMB2 and SMB3 Under One Hat.

The first of these three authentication schemes should really be avoided these days, unless we need to network Windows 98 machines, because NTLMv2 etc., are really quite insecure.

The second scheme has represented the mainstream of how Linux has adopted SMB in its Samba software-suite. But, because the Windows version of SMB1 lacked transport encryption, Linux specifically devised its own solution to that, which only works with Linux implementations of SMB1. This is what the ‘smbclient’ command-line program will use, as well as the ‘Smb4K’ GUI-application.

The third flavor of Samba, is what has come to Samba v4 anew, which is an attempt to keep up with the Windows version of ‘SMB with encryption’. If configured to do so, Dolphin will attempt to emulate SMB3. But Dolphin currently fails to query the Master-Browser, if the Master-Browser is just a Linux, Samba 4 server, that has been configured to insist on implementing SMB3. In that case, an error can take place in which Dolphin can connect to specific Servers if their Names are known, but just not view the entire network neighborhood. )

But all that these options allow, is for the initial negotiation to be secured, by which an SMB share is connected. Further, it allows for a possible, later encryption key to be determined in a secure way.

A commonly-known fact about Samba, is that whether the actual exchange of data is encrypted, is determined by default by the client. The actual ‘smbclient’ command-line under Linux accepts the -e flag to do so. And under Windows 7 and 8, the use of 128-bit encryption is default, again set on the client. There are some people who cannot use this, because they are connecting to an older Samba server from Win 7 or 8 as the client, but I like the fact that this is enabled.

Yet, when I connected to my Samba server from a Linux client, not from the command-line, but from within the KDE browser, either ‘Konqueror’ or ‘Dolphin’, these GUI network browsers did not set encryption by default.

Therefore, the possibility still existed that I could be using a Linux client, and not benefiting from encryption in those cases. And so one setting on the server which I found could be helpful, was

smb encrypt = mandatory

This is a [Share] section setting on the server to force encryption, instead of the client deciding. In the case of my Windows clients, this produces no new behavior. But in the case of my Linux (Samba 3) client, it does produce new behavior.

My only personal problem with this setting is, that I don’t know of any Android SMB browsers that support share-level, data encryption. Putting this setting on my server, and then giving the command

smbcontrol smbd reload-config

simply causes all my Android SMB browsers to fail at connecting, apparently. And so one thing I needed to do after all, was to disable this setting, and consciously leave myself open to the possibility, that some of my exchanged data will not be encrypted (especially data exchanged with an Android device).


(Edit : ) I have been trying to obtain some sort of closure on this subject, by putting the configuration lines

smb encrypt = mandatory
guest ok = no

Into the [Homes] section.

However, I found that this does not resolve my issue completely, for three reasons:

1) The [Homes] section works differently from how I had thought. It actually determines which service is being asked for explicitly by the client, and then either clones the section specific to that share, or creates one on-the-fly.

2) Even if I create a different share specifically to have these options, the KDE 3 Konqueror GUI and the KDE 4 Dolphin GUI seem unable to abide by it, while the ‘smbclient’ command-line does so without problems. And so what I’ll need to accept, is that KDE 3/4 Samba browsing will simply need to remain without data encryption…

3) What this option does seems to differ, depending on whether the client is asking for SMB1, SMB2, or SMB3.

With SMB1, a form of encryption is possible, which only exists in the case of Linux, and which is invoked by the ‘smbclient’ command-line as described above.

With SMB2, this feature either seems to be broken or isn’t available.

And with SMB3, this feature actually works. Thus, the only client which seems to be fully compatible with this special share, is my Windows 8.1 laptop.


(Edit 03/15/2016 : ) Due to recent upgrades to the Samba server suite (v 2:4.1.17+dfsg-2+deb8u2 ), I can no longer recommend that older clients bet set to use NTLMv2. On the newer server, this mode only exists to provide compatibility with Windows clients. It only seems to work for me if password encryption is generally required by the server, but if the protocol is left open on the client. That way, a specific negotiation can use ‘Kerberos’ if necessary.

(Update 03/26/2018 : )

By now I have both v4.2 and v4.5 Samba Servers, and reasonably current Dolphin file-browsers. The solution that works best for me now is, to set:

smb encrypt = enabled

Globally, but to set:

smb encrypt = desired

on a Per-Share basis.

What this will do, if I’ve configured each Dolphin file-browser to use SMB3, is announce to the server that the client is SMB3 -capable. In response, the server will enforce encryption. In that case, older clients, Android clients, or the ‘smbclient’ command-line, will only announce SMB1 -capability, and encryption will not take effect. And this mixed result is my replacement, for GUI-based clients that would allow their user to select encryption, and which do not seem available.

In order to force my Dolphin clients to offer SMB3 in this way, I have created the file ‘~/.smb/smb.conf’, which contains the following lines of text:


   client max protocol = SMB3