## 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… )

## File-Sharing under Linux, using Usershares – the Modernistic Way.

One concept which readers may already know, is that under Linux, we can set up a Samba-server, which makes the sharing-out of our home directories possible, and that if we fiddle with the ‘smb.conf’ configuration file thoroughly enough, it becomes possible to browse the available shares on a LAN, in a way semi-compatible with Windows computers that also reside on the same LAN.

Traditionally, this has always been a bit of a PITA, especially since the ‘/etc/samba/smb.conf’ configuration files have been finicky, and since each share practically needs to be configured individually, by a person with the ‘root’ password.

Well an alternative exists under Linux as well, which is the concept of ‘Usershares’. With this concept, each user who belongs to a specific group has the privilege, of designating a folder within his desktop manager, to share out, pointing-and-clicking. This is closer in ease-of-use, to how the process works under Windows. But, it needs to be set up correctly once, by the sysadmin, before it will work as often as simple users wish it to work.

I think that an existing Web-article on the subject, already explains well, what the settings in the ‘smb.conf’ file need to be, as well as what directories need to exist, in order for usershares to work. Except that the article I just linked to, refers to Fedora and SELinux systems and their norms. I happen to be based on Debian and KDE 4 or Plasma 5. And so I have a few observations to add:

Firstly, the following packages should be installed, under Debian also:


#apt-get install kdenetwork samba



Secondly, ‘/etc/samba/smb.conf’ needs to be edited like so:

Under Debian, the directory ‘/var/lib/samba/usershares’ already exists, If the relevant packages are installed. And its permission-bits have already been set as they should be set. Only, the feature is not configured in ‘smb.conf’ by default. And, the additional package named ‘kdenetwork-filesharing’ needs to be installed, in order for the tab to appear in Dolphin’s File-Properties box, that enables sharing from the GUI. Aside from that, enabled users need to be added to the ‘sambashare’ group, after which this membership only goes into effect, once the user in question has started a new session…

(Info Corrected 03/25/2018, 17h10,

Updated again 03/28/2018 … )

## Why visual SAMBA Browsing no longer works On My LAN.

One of the routine tasks which I recently carried out on my LAN, was to retire an old computer named ‘Walnut’. A day later I discovered that I could no longer browse my LAN, by way of my SAMBA shares. BTW, all my computers are by now either Debian / Jessie or Debian / Stretch computers. So what gives with the sudden inability to browse my shares via the GUI, which is the ‘Dolphin file browser’?

(Solved as of 03/23/2018 … )

Well in my ‘/etc/samba/smb.conf’ file, I gave the option:


[global]

(...)

smb encrypt = desired



The purpose of this was, for the Samba Server to query the Client, whether the  client supports encryption, and if affirmative, to enforce such encryption.

And, just to be sure that I haven’t made some silly mistake, I can run the following tests:


root@Phoenix:/etc/samba# cat smb.conf | grep "map to guest"
map to guest = Bad User
root@Phoenix:/etc/samba# cat smb.conf | grep "obey pam"
obey pam restrictions = no
root@Phoenix:/etc/samba#



But the disposition of the client to offer encryption, needed to be decided on the client machines, by creating a user-space file, i.e. a file in the home folder, which is named ‘~/.smb/smb.conf’, which contains the following lines:


[global]
client max protocol = SMB3



This is actually required, in order for the Dolphin / GUI-client even to offer the level of security which I wanted, which is SMB3 security. Without my specifying this, Dolphin would indicate to the Server, that SMB3 is not available, and no encryption would take place. This line of code can also be put into ‘/etc/samba/smb.conf’ , but I chose to put it into my home-folder like that.

## My router may have been flashed.

One of the ironies of my LAN is, I am hosting a Web-site from it, but I do not even own my present router. Mine is a router owned by my ISP, and which provides me with proprietary TV as well.

This means that my ISP has the right to perform a firmware update on the router, which can also be called ‘flashing the router’.

I suspect that this may have happened, around Wednesday Morning, November 9.

My main reason for suspecting this, was a subtle change in the way my router manages my LAN.

According to This Earlier Posting, I previously needed to set my router as the WINS server as well.

To explain in lay-terms what this means, I need to mention that the local IP addresses which computers have on a LAN do exist, in addition to which Windows has introduced its own way of giving the local computers names. Linux can mimic how this works, using its ‘Samba’ software suite, but also tries to avoid ‘NetBIOS’ (naming) as much as possible, outside of Samba network browsing, or ‘copying-and-pasting of files, between computers on a LAN’.

Just like domain-names need to be resolved into IP addresses on the Internet, which is the WAN to this LAN – the Wide-Area Network – on the Local Area Network, computer-names also need to be resolved into IP addresses, before the computers can actually ‘talk to each other graphically’. Traditionally, Windows offered its whimsical mechanism for doing so, which was named NetBIOS, by which any and every computer could act as the WINS server – thus offering its repository of LAN locations to the WINS clients, but alternatively, there could also exist one dedicated WINS server.

What I had grown used to, was that on my LAN, the router would insist that it be my WINS server, thus ‘not trusting’ any of my Linux boxes to do so in some way. I therefore had to defer to this service, as provided by the router.

I had previously set my ‘/etc/samba/smb.conf‘ to

   wins support = no

dns proxy = yes

Well as of Wednesday, the LAN had suddenly ‘looked different’ according to client-browsers. Each computer had suddenly remained aware only of its own identity, with no Workgroup of other computers to network with.

This was all happening, while my connection to the WAN still seemed secure and operative.

Long story short, I think that my ISP may have performed the Firmware Update, and that according to the new firmware version, the router was suddenly not willing to provide this service anymore. And so what I felt I had to do next, was change these settings back to

   wins support = no

dns proxy = no

Now that I have done so, each computer can ‘see’ my whole Workgroup again – which was apparently not feasible according to earlier experiences.

Further, for laypeople I might want to emphasize, that it is not just a frivolous exercise of mine, to give each computer a name. If they did not have names, then according to the screen-shot below, I would also not be able to tell them apart, since they all have the same icon anyway:

Now I suppose that an inquiring mind might ask, “Since Linux can imitate Windows, why does Dirk not just set ‘wins support = yes‘ as well?” My answer to this hypothetical question would be, that

• According to common sense, this option will just make the current machine available, as a potential WINS Server, but
• In my practical experience, the LAN will interpret this as more of an imperative gesture, of a kind that will actually cause a feud to break out between the machines.

In my experience, if I even set one of my Linux machines to do this, all the other Linux machines will refer to its repository of (4) LAN names, the others becoming clients, but the Windows 7 machine named ‘Mithral’ will refuse to have it. In this case, Mithral will insist that it must be the WINS Server, and not some Linux box. And then, further logic-testing of which machines can see which, will reveal that in practice, I must leave this option switched off, if there is also to be any Windows machine to share the LAN with.

Dirk