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

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

I’ve just received my 13.3″ Onyx BOOX Max2 e-Reader.

And so far I’m happy with it.

There exists an underlying issue with Android-based e-Readers, where these e-Readers are 4 years in the making, and where the issue is something I’m just learning about in recent weeks. As a security precaution, Google has toughened the requirements on the Google Play Store app, and on the Google Services app, which made numerous e-Readers, that were once proud to offer a working Google Play app, unable to connect to Google Play in the short term. This measure became effective as of March in 2018. However, certain manufacturers of such devices have been struggling to make their devices compliant with the new Google Store, and as far as I know, the BOOX Max2 which I just received, may be able to connect to the Google Play store fully.

(This posting has been revised, as of 4/14/2019, 10h15 : )

(The posting has been revised again, as of 10/24/2020, 12h45… )

(And, the posting has received another update, as of 10/29/2020, 8h10… )

Out-of-the-box, the Max2 had a firmware version from April in 2018. But the latest Firmware update is from December in 2018 (July in 2020).

  • I am glad to say that I found out how to set a PIN Code for this device because if there had truly been no way, then the cloud resources that I’m logged in to would be just as vulnerable, as an unlocked tablet. With the latest firmware, I found this setting under ‘Settings -> (Arrow to the Right) -> Screen Lock PIN Code’.
  • Apparently, the way to activate Google Play on this device, is now to go into “Settings -> Application” and to check “Activate Google Play”.

Instead of activating the Google Play Store, I have been focusing on using the Onyx app store for the time being. In days gone by, their in-house app store had a reputation of only offering apps in Chinese. But what the users of the Max2 can now do, is download e-Ink optimized apps in English. Those apps include the Amazon Kindle Android app.

This is a huge find for me because it also implies less of a security compromise, than what I’d have, if I was just to log the Max2 into Google Play.

I can side-load Free APK-Files to install software, and can install some additional proprietary, non-free apps from Onyx. APKs include the ‘OverDrive’ app, which allows me to check out books from my public library, in e-Book format. And what installs from the Onyx app store includes the ‘Kindle’ Android app, optimized for e-Ink. (:2)

I’ve tested both apps, and they seem to work fine.

But then again, speaking of side-loading… This can imply that files need to be transferred via USB-cable from a PC, to the device, and the device uses MTP as its protocol. There are some reports of issues in getting this to work from the Linux GUI, and I just ran in to such an issue…

(Updated 6/21/2019, 7h35 … )

Continue reading I’ve just received my 13.3″ Onyx BOOX Max2 e-Reader.