## Managing Usershares properly, under SAMBA (meaning, under the SMB emulation given by Linux).

Just to encapsulate the subject of this posting… ‘SMB’ is a file-sharing protocol which is really Windows-owned. Granted, ‘SMB1‘ cannot be fully Windows-owned, but, on the assumption that a ‘SAMBA’ server is being used to emulate ‘SMB2′ and ‘SMB3′ (under Linux), there are many ways in which the (root-owned) configuration file at ‘/etc/samba/smb.conf’ could be faulty, and could result in weird error messages. The fixes which are highlighted in this posting worked for me, but my reader could be suffering from mistakes of an entirely different nature. I am posting this, in case the reader happens to be suffering from the same configuration mistakes which I was.

Also, my configuration issues arose partially, because I’ve switched this configuration file from a configuration in which Home Directories are being shared out in their entirety, to a configuration in which individual users can decide to share out specific folders they own. This system is one of ‘Usershares’.

What I was eventually doing was, to give the command ‘net usershare add <Share-Name> "<Path-Name>" "<Comment>" Host\\user1:f,Host\\user2:f‘. The comma and the absence of spaces in the Access Control List are important. I was getting the error-message stating, that these user-names, part of the ACL, could not be converted into SIDs. What I found was, that I had the following error in my ‘smb.conf’ file:


map to guest = bad user
guest account = nobody

(...)

server max protocol = SMB3
server min protocol = SMB2




Amazingly, the error message went away, if I changed that last detail to:


client max protocol = SMB3
server min protocol = SMB2



But, there is more to be known about my configuration:


usershare allow guests = no
usershare max shares = 10
usershare owner only = false
usershare path = /var/lib/samba/usershares



What this last set of parameters actually requests is, that individual users should not be able to grant Guest Access – unauthenticated access – to any of their folders, but potentially, to grant access which is authenticated by another SAMBA username, with their enabled password, as existing on the server.

Again to my amazement, I found that, if the server is massaged adequately, it will implement the settings exactly as requested. But it will do so with a crucial limitation. Locally on the server, the non-owner username must already have access to the exact folder named in the usershare. What level of access that username has (to the named folder itself), will cap whatever level of control is granted by way of a SAMBA client.

This observation could also be rephrased as follows: Even though (Linux) SAMBA has an impressive-looking feature in “Usershares”, while that creates rule-files in the folder ‘/var/lib/samba/usershares’, which even possess Access-Control Lists, those ACLs finally disappoint, in NOT guaranteeing what the behaviour of the SAMBA server will be, once a usershare has finally granted access (to a folder, for the client). (:2)

Usually, in order to grant such access locally on the server, some strategy with group memberships and permission-bits gets used. Which exact arrangement of groups and permission-bits gets used, is not set in stone. Any arrangement will work that grants full access. But, because it’s usually unwieldy for users to set up such local sharing of their folders, they are also not likely to succeed – without compromising their security completely – unless they also have the help of someone with root access. Therefore, the ability to give this feature to users in user-space, is theoretical at best. (:1)  And, if the user wants to activate this extension, he or she must use the CLI, and cannot count on the GUI within ‘Dolphin’ to do so. But, the final command given via the CLI can be given as user.

By default,  declaring a usershare ‘the easy way, via the GUI’, remains owner-only.

There is one more caveat to mention. According to my recent experiences, if ‘Dolphin’ is being used as the SAMBA client, and if it’s to authenticate with the server, using any username other than the current username on the local client-computer, then the credentials need to be specified under ‘System settings -> Network -> Connectivity’ (where the Plasma 5.8 Desktop manager puts them). If there is a set of credentials there, they will not be stored encrypted, but only stored with casual obfuscation, and Dolphin will use them. If the user wants the credentials to be stored in the ‘kwallet’ (and thus encrypted), he needs to make his username, to log into the server with, identical to his username on the local client. Otherwise, illogical error messages will appear again, this time, from the Dolphin file-browser not being consistent, in whether to try to authenticate at all. And, if an attempt is made to access the share without authenticating, then Dolphin generates an illogical error message, which can be paraphrased as a ‘File Exists’ error message.

With enough effort, and, sacrificing some security, it can all be done.

(Updated 3/29/2021, 15h10… )

## Observations, on how to insert Unicode and Emojis into text, using a KDE 4 / Plasma 5.8 -based Linux computer.

One of the earliest ‘inventions’ on the Internet, were ‘Smilies’, which were just typed in to emails, and which, when viewed as text, evoked the perception of whichever face they represented. But, graphical user interfaces – GUIs – replaced simple text even in the 1990s, and the first, natural thing which developers coded-in to email clients was, the ability to convert typed, text-based smilies, into actual images, flowed with the text. Also, simple colon-parenthesis sequences were replaced with other, more varied sequences, which could be converted by some email clients into fancier images, than simply, smiling faces.

Actually, the evolution of the early Internet was slightly more complex than that, and I have even forgotten some of the real terms that were used to describe that History.

But there is an even more recent shift in the language of the Internet, which creates a distinction between Smilies, and ‘Emojis’. In this context, even many ‘Emoticons’ were really just smilies. Emojis distinguish themselves, in that these pictograms are represented as part of text in the form of Unicode values, of which there is such a large supply, that some Unicode values represent these pictograms, instead of always representing characters of the Earth’s many languages, including Chinese, Korean, Cyrillic, etc. What some readers might ask next could be, ‘Traditionally, text was encoded as 7-bit or 8-bit ASCII, how can 16-bit or 32-bit Unicode characters simply be inserted into that?’ And the short answer is, through either UTF-8 or UTF-16 Encoding. Hence, in a body of text that mainly consists of 8-bit codes, half of which are not normally used, sequences of bytes can be encoded, which can be recognized as special, because their 8-bit values do not correspond to valid ASCII characters, and their sequences complete a Unicode character.

One fact which is good to know about these Emojis is, that they are often proprietary, which means that they are often either the intellectual property of an IT company, or part of an Open-Source project. But the actual aspect of that which can be proprietary is, the way in which Unicode values are rendered to images.

What that means is that, for example, I can put the following code into my blog: 🤐 . That is also referred to as Unicode character ‘U+1F910′. Its length extends beyond 16 bits by 1 bit, and the next 4, most-significant bits are all 1’s, as expressed by the hexadecimal digit ‘F’. It’s supposed to be a pictogram of a deceased entity, as if that were stated correctly by a head which has had certain features crossed out. But for my blog, the use of such a code can be a hazard, because it will not display equally on Android devices, as it displays on iOS devices. And, on certain Linux computers, it might not be rendered at all, instead just resulting in a famous rectangle that seems to have dots or numbers inside it. This latter result will form, when the client-program could not find the correct Font, to convert this code into an image. (:3)

Those fonts are what’s proprietary. And, they also provide some consistency in style, between Android devices, OR between iOS devices, OR between Windows devices, etc.

Well, I began this posting by musing about the early days of the Internet. During those days, some users – myself included 😊  – did some things which were truly foolish, and which included, to put background images into our HTML-composed emails, and, to decorate documents with (8-bit) dingbat fonts, just because it was fun to pass certain fancier documents around, than POT. I don’t think there is really anything wrong with potential readers, who still put background images into their emails. What I mean is that many of my contacts today, prefer emails which are not even HTML.

This earlier practice, of using dingbat fonts etc., tended to play favourably into the hands of the tech giants, because the resulting documents could only be viewed by certain applications. And so today, I needed to ask myself the question, of how often the use of Emojis can actually result in a document, which the recipient cannot read. And my conclusion is that today, such an indecipherable outcome is actually rare. So, how I would put a long story short is to say, that Commercialism is back, riding on the desire of younger people to put more-interesting content into their messages, and perhaps, without some of the younger people being aware that when they put Emojis, they are including themselves as the software-disciples of one larger group or another. But that larger group mainly seems to be drawing its profits, from the ability of certain software to insert the images, rather than, the ability of only certain software to render them at the receiving end (at all). Everybody knows that, even though the input methods on our smart-phones don’t lead to massively good prose, they almost always offer a rich supply of Smilies, plus Emojis, all displayed to the sender using his or her own font, but later displayed to the recipient, using a potentially different font.

The way Linux computers can be given such fonts, is through the installation of packages such as ‘fonts-symbola’ and ‘ttf-ancient-fonts’, or of ‘fonts-noto‘… The main drawback of the open-source ‘Symbola’ font, for example, is simply, that it often gives a more boring depiction of the same Unicode character, than the depiction which the true Colour Noto Font from Google would give.

One interesting way in which Linux users are already in on the party is, in the fact that actual Web-browsers are usually set to download fonts as they are needed, even under Linux, for the display of Web-pages. Yet, email clients do not fall into that category of applications, and whether they render Emojis depends on whether these font packages are installed.

Hence, if the ability to send Emojis from a Linux computer is where it’s at, then this is going to be the subject of the rest of my posting. I can put two and two together, you know…

(Updated 7/31/2020, 15h10… )

## Latte-Dock 0.6.0 Tested

One of the facts about Linux that may not be very popular with some computing enthusiasts is that the mainstream Desktop Managers – ‘KDE’, ‘Plasma’, ‘Unity’, ‘GNOME’, ‘LXDE’, etc., are different from each other, are sometimes similar to a Windows-layout – especially KDE / Plasma – but are not very similar to a MacIntosh, OS/X layout. Yet, efforts have existed to create OS/X -like desktop managers for Linux, and one of the more recent projects is “Latte-Dock“.

What makes Latte-Dock different from otherwise similar projects such as “Cairo-Dock”, is that Latte-Dock assumes that we have Plasma installed, which must be of at least version 5.8, and does not conflict with the fact that we do. And the fact that my Debian / Stretch computer, which I name ‘Phosphene’, is not even a Ubuntu computer, did not prevent me from installing Latte-Dock 0.6.0. Latte-Dock does not start unless the user starts it, and the way I go about testing such software is, that I create additional users on the computer in question, as if I was going to allow a guest to share my computer, so that in the user-space of the additional accounts, personal settings can activate Latte-Dock.

One of the ways in which Debian, Plasma 5 -based computers are strong, is in allowing the user to create more than one graphical log-in, to more than one virtual session, between which we can switch by clicking <Ctrl>+<Alt>+<F8>, or, back to the first virtual session, with <Ctrl>+<Alt>+<F7>… So my auxiliary user-identity is installed with this desktop manager, that’s designed to be similar to OS/X, at least in its appearance.

I think that this is nice software, with two major flaws:

1. On ‘Phosphene’, if I select the settings either to Preview Windows (of open applications, as the mouse passes over the dock-icons), or to Highlight those windows, these settings cause the Dock to die. This is not tragic, because when running Latte-Dock, we still have at least one Plasma-Panel active, along the top of the screen, from which we can still choose applications to run, or from which we can drag application-icons to the Dock. (:1)  This means that when the Dock has in fact crashed, I can simply have a Favourite Application -icon ready, to restart it. But the down-side with this could be, that it makes the application look bad, when in fact the culprit just seems to be, the fact that my graphics card is not strong enough to display these previewed or highlighted windows. And Latte-Dock is extremely GPU-intensive.
2. With Plasma 5.8 as the limiting factor, there appears to be no way to get a Global Application Menu working. Such applets do exist as software-projects for higher versions of Plasma than 5.8, but it cannot seem to be achieved for version 5.8 . So the OS/X experience is not 100% complete.

But if I respect these two limitations, that may not even be the fault of the Devs, I find this to be an interesting and stable piece of software.

(Updated 3/27/2019, 21h35 … )