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… )
(As of 3/28/2021, 7h10…)
As an example of how it might be difficult for a user to set up sharing his folder with other authenticated SAMBA users only, that user could set the mode bits of that one folder to ‘
0777‘, and give permission in the Access Control List (ACL) of the Usershare. However, the other username would still not be able to stat that folder, unless the user who is sharing it out, also sets the mode bits of all the parent folders to ‘ 0755‘. However, setting the parent folders’ mode bits like that could have the side effect that Locally, all the other users will be able to browse a multitude of the sharing user’s folders, not just the one folder he or she really wanted to share out…
Now, a better-managed way exists to do this, but which also requires root to set up. Using root, a special system-user can be created, that has a disabled log-in password, and that belongs to the group of the user whose folder is to be shared out. In my case, the system user ‘userm’ belongs to the group ‘dirk’, where my personal username and its associated group are ‘dirk’. But, using the ‘smbpasswd’ command, I was able to give the system user ‘userm’ a SAMBA password. Then, I was able to set the mode bits of the folder I wanted to share out via SAMBA to ‘0770‘, while also setting the mode-bits of all the parent folders to ‘0750‘.
One result this finally gave was that if, from another computer on my LAN, I used the (authenticated) username ‘userm’ to browse, I could obtain full control over the folder I have shared out. But, another effect this had was that, because I had made ‘userm’ a system-user and not a regular user, the Dolphin GUI on the SAMBA server would also not display it, as a potential user who I might want to share access to the folder with. Therefore, once I had become user again, I still needed to use the CLI actually to create the usershare.
I suppose that another question which my reader might want an answer to could be, what means exist, to reset usershares which were messed up in some way, so that he or she could try to set them up again. And the answer to that one is, that they can trivially be deleted from the folder ‘/var/lib/samba/usershares’.
(Update 3/28/2021, 12h25: )
Hypothetically, some other user – possibly my reader – could want to enable the feature, that individual users should be able to use the check-box within Dolphin, to allow (unauthenticated) Guest Access to certain usershares. And that reader could have root.
If this were the case, then, where the configuration above stated:
map to guest = bad user guest account = nobody (...)
It could be changed to:
usershare allow guests = yes usershare max shares = 10 usershare owner only = false usershare path = /var/lib/samba/usershares (...) map to guest = bad user guest account = system_account (...)
The account-name ‘system_account’ is hypothetical here. I’ve heard of cases, where certain privileged users were able to grant SAMBA access to user ‘nobody’. But if this is set up properly, then the sysadmin would also make sure that the user ‘system_account’ (as shown above) belongs to all the groups, that have the same names as actual, regular users who can log in. And again, this ‘system_account’ would need to have a disabled password login, itself.
Really, user ‘nobody’ is not supposed to have any privileges at all.
In that case, individual users could set the parent folders’ permissions to ’0750‘ as before, and the arrangement should take hold.
I, personally, would need to be wary of the fact, that I have already set one folder to have permission-bits ‘
0770‘, which means that in my case, anybody surfing my LAN, even if they are not authenticated, could also gain write-permission to that folder. I’d need to change that, If I wanted to enable unauthenticated, Guest Access.
(Update 3/28/2021, 16h15: )
In my opinion, Regular PCs should never have Guest Access to their SAMBA Servers enabled in such a way, due to the obvious security risks. After all, any invalid user would get mapped to a system-user, that belongs to every sensitive group, If the mechanism that receives usershares in general, decides to do so for any one folder (i.e., If the ACLs do allow it). However, I could imagine that specialized computers might be set up on some network, the sole purpose of which would be, to allow authenticated users to publish content, which literally everybody will be able to download. And in the case of such a dedicated box, SAMBA Guest Access might make sense.
Yet, even in such a scenario, there exist alternatives, such as the ‘vsftpd’, the Very Secure FTP Daemon… It can be used to publish HTML in such a way that any Web-browser can view it.
(Update 3/29/2021, 15h10: )
IF The intention is, that “Everybody” should be granted Read-only access, and that the shared folder’s owner grant himself “Full Control”, THEN:
The sharing user may belong to the group ‘users’ (which I did not on the server in question), and ‘Usershares’ will work as they should, with the ACLs deciding to grant Read access, just so that the sharing user doesn’t have to compromise his security, in finding other ways to share out folders.
However, it was my original intention to grant Full Control over One folder, to a user not its owner, by way of SAMBA.