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

(As Of 03/24/2018 : )



I tested this feature and find it works well. From the sharing computer, the user sees this:





And from a different computer on the same LAN, another user gets to see this:




(Correction 03/25/2018 : )

There is one slight security-disadvantage however, to doing it this way. If the user who shares out a folder does not set ‘allow guests’, this means that the user who is browsing, must authenticate first. The disadvantage here is in the fact that the Samba password to use, is the same, as the log-in password of the user who is sharing out the folder.

What I have seen through simple experimentation, is that at least under Debian, the sysadmin must still use the ‘smbpasswd’ command, with the ‘-a’ option, to create a Samba-password for a specific user, before that user can create usershares which require authentication. After that, the user in question can use the ‘smbpasswd’ command himself, without any options, to change his Samba password.

I see this as a big bonus, because it means that the Samba password for any user can be different from their log-in password. This would mean that even if the Samba password was ever compromised, the actual log-in password of the same user, would not have been compromised.

Of course, enabling this feature will require the following setting in the ‘smb.conf’ configuration file:


   unix password sync = no


There’s another observation to add, this time having to do with encrypted transport. Our passwords are already encrypted by default. But the setting, to encrypt the data as well, is generally not compatible with ‘guest ok’. The reason for this is the fact that in order for encryption to work, a piece of information needs to be visible to both the server and client, which even a potential eavesdropper cannot derive from the full negotiation. And that piece of information is actually, the password.

This would mean that, If the sysadmin was to set:

smb encrypt = desired

Globally, Then, the server would respond to any capability the client announces, of using encryption, and would then enforce that all the remaining data of the session be encrypted. But in the case of ‘guest ok’, there would be no valid password to give, and the session would presumably fail.

And so the highest global setting on the server, If ‘guest ok’ was permitted for the usershares, would be:

smb encrypt = enabled

This way, encryption is not enforced globally, by the server, so that unencrypted access to anonymous shares can succeed. But it also means that encryption will not be applied, unless either:

  • The client requests it explicitly, or
  • A specific share has been set up in the ‘smb.conf’ file on the server, which upgrades its own requirements to, say, ‘smb encrypt = desired’.

(Updated 03/25/2018, 17h10 : )

And yet-another observation to add, has to do with the standard Homes share, that Debian flavors of Samba have set up. This share becomes visible to browsers, whose user-names and passwords match a Samba user-name and password. The concern might come to some users, that if their Samba-password was in fact compromised, then this would also have led to an attacker being able to browse this Homes share. Where then, the security of not having this password the same as the log-in password?

And one possible answer to that question would be, that by default, the Homes share is read-only, as well it should be. This means that if an attacker had obtained a user’s Samba-password, he would have been able to browse and read-from his Homes share as well, but not to write to the Homes share. The attacker would only have been able to write to folders, which the user specifically enabled as usershares.

Yet, If the sysadmin fears that:

  • A potential attacker is a sophisticated attacker, who can exploit read-only access to users’ folders, and/or
  • The actual users’ passwords might be weak,

Then a further measure to strengthen security would be to set the following:




;   valid users = %S
   valid users = nobody


This should effectively disable the feature.

However, I suspect that a practical usage-consideration would be, that the user appreciates being able to read data from their home-folders, and is confident in his or her ability to keep their password secret. In that case, their only needs for a usershare would be:

  • To create a sub-folder which they themselves can write to remotely, or
  • To make data from a specific folder available anonymously, i.e. ‘for file-sharing’.

In that case, to keep the Homes feature activated, will reduce the number of usershares that actually need to be created (and which are not encrypted by default).

(Edit 03/26/2018, 01h30 : )

After tinkering with them for several days, I have a conclusion about Usershares:

They may make the task easier for non-experts, or more specifically, for non-Linux experts, to set up file-sharing. But they have two major drawbacks for power-users who are already adept at Linux.

  1. There is no way to ensure from the server, that encryption will take place. With statically-defined shares, I’m confident that I can do this.
  2. They’re incompatible with the concept of ‘Samba-mounts’, which are also referred to as ‘CIFS-mounts’, or ‘network-mounts’. Those will require that a major system of folders on the server, have read / write -access. And as I already mentioned, by default, Homes shares only have read-access, while Usershares will be scattered about in the user’s home-folder-tree. For example it would be simpler, just to set the Homes shares to ‘read only = no’, and then again, to achieve zero-setup-per-user.


(Update 03/27/2018 : )

I have a few more observations, about the subject of how secure or insecure these types of SMB-sessions are:

  • Even if encryption is enabled, This does not mean that an SMB-share should ever be exposed directly to the Internet, or the WAN.
  • SMB3-encryption offers AES-128 as its actual encryption-algorithm. However, it’s ultimately only as secure, as the password, since a symmetric key needs to be negotiated, and no form of Public-Key Infrastructure is used by default.
  • If there is no encryption, then the password-security defaults to some form of challenge-response negotiation. That methodology may be secure, or may not, depending on how it’s implemented. I know of challenge-response protocols that should be regarded as secure, and of others that should not. Just because the Linux community has strongly subscribed to the ‘NT1′ SMB-Protocol in the past, I’d guess it’s reasonably secure.
  • If data-encryption has been activated, either as part of ‘NT1′, or as part of the ‘SMB3′ protocols, then password-authentication does not take place separately. In those cases, the mere fact that the client is able to establish an encrypted session, is proof enough, that the client also knows the password. And in those cases, the password-security is also greater, than it would be entirely due to challenge-response authentication.

(Update 03/28/2018 : )

I’ve observed that if, I created a Usershare with the Access Control Lists (ACLs) set to give “Full Control” to a specific authenticated user, then, using the Dolphin GUI-based client from another machine, I can navigate to the share in question, and directly in the root folder of that share, my Dolphin client-program will have the options grayed-out, either to Paste a file, or to Create a New Object. However, if there is then a sub-folder of that share, I can right-click directly on the sub-folder, and the context-menu commands are available, to Paste, or to Create a New Object, which will all come into being, inside the folder I right-clicked on. When browsing my shares in this way, Dolphin shows their contents as a List View.

AFAICT, All this is really just a quirk in how Dolphin works under Debian / Stretch, and does not reflect what the per-share permissions are, that the Samba-server set. Whether those options are grayed out or not, further has no meaning, to indicate whether the server would allow me to write to the share. I.e., with the Access Control Lists set to Read-Only, the options will still become active in the GUI, to Paste a File, but If I attempt to do so, I’ll next get an ‘Access Denied’ message.

I guess I’ll just have to accept that this is the maximum degree, to which the Dolphin File-Browsing GUI will work, with Usershares.



Print Friendly, PDF & Email

8 thoughts on “File-Sharing under Linux, using Usershares – the Modernistic Way.”

  1. Dirk, I happened on your blog while looking for the syntax for a file share to the Bell modem 3000. I run a Daphile Linux headless audio setup and I m trying to set up the harddrive which is inserted in the USB port of the 3000. The Daphile Linux setup allows
    …try as I might I can’t get Daphile to read the harddrive name. The drive is listed as a device at …any chance you could give me a hint?

    1. All I can offer is a pure guess. You got the IP address of the modem right. I’d say, that when we see a USB Port on an appliance, we jump to conclusions, about what it’s there for. This is partially, due to the fact that USB ports are used for so many things. That USB port may never have had as function, to act as a file server. Some technician might use it to flash the firmware instead. So, Unless you have it in writing, there may be no way to do what you’re trying to do… (?)


      1. Thanks Dirk. Much appreciated. You may be right. The 3000 modem does serve the files in the 1TB drive as upnp and also dnla and I may just have to be content. The problem is that the Daphile rig does not seem to receive those two protocols; my Android phone does with Neutron music player. Probably I need a different Linux file player, not Daphile. –thanks again.

        1. Okay. I must admit, that I misinterpreted your question to mean, that you wanted your Bell 3000 Router to act as an SMB or maybe some other File Server. What you really wanted it to do, was act as a media streamer?

          There is a Linux client which will play UPnP, which is an up-to-date version of VLC. This Web-link explains how to use it. To paraphrase what was written, one clicks on:

          ‘View’ -> ‘Playlist’ -> ‘Local Network’ -> ‘Universal Plug n Play’.

          Just to make sure that I am not giving you any false info, I just tested it. After quite a few seconds of scanning, my VLC player displayed my Bell 3000 Router, but no available media, because I do not have any storage device plugged in to the router’s USB Ports.


  2. Excellent and very explanatory guide, a newbie corner like me appreciates it. By the way, I cannot find the configuration so that network users have permissions (rwx) but only on the network files that they create, while with the rest of the information present only (r-x). On Windows I did it with the CREATOR OWNER group, on GNU/Linux I don’t know how to do it yet, could you please guide me? Thanks again 👽

    1. Hello,

      It’s interesting that I had written a past posting about the same subject, which my most recent posting also wrote about. I had forgotten about the earlier posting. As my more recent posting indicates, I ran into the same problem in giving Authenticated, Non-Owners (rwx) permission, that you just noted. What I ended up doing was, to create a system user, that happens to belong to the group of the actual user, one of whose folders I wanted to share out (rwx) permission to. I’m convinced that I’m pulling a trick on the SAMBA server that way.

      It’s important to disable any password log-ins for this system user.

      To make it work, from the SMBA server itself, I made sure that the folders I wanted to grant (rwx) permission to, had permission bits (rwxrwxr-x). But, it would be just as easy for me to set some other permission for specific sub-folders, such as, (rwxr-xr-x). Doing the latter would have as result that, for those sub-folders, the remote SAMBA client has no write permission.

      Hence, I had to make sure that all my parent folders had permissions (rwxr-xr-x), just so that the targeted folder could inherit permissions (—rwx—).

      Now, when I next experimented with ‘uploading’ a JPEG image this way, I found that the file that ended up on my SAMBA server had owner ‘userm’ – in other words, that file was created as belonging to the system user who I had invented – but also ended up belonging to the group ‘dirk’, which is the group of my personal username.

      What this really tells me is that, in the case of sub-folders, you’re going to have to make sure from the SAMBA server itself, that those belong ‘to the real user’ and have been given permissions (rwxrwxr-x), if that’s what you want. I can’t quite read how you want to manage your individual folders. As far as I can see, there is no way to manage their permissions or ownership from the SAMBA client, then.

      Hence, you may create sub-folders from the SAMBA server, with whichever ownership and/or permission bits you want, but cannot manage this to become automatic from the SAMBA client, keeping in mind that authenticated users will appear on the server as that invented, system user.

      I hope that helps.


    2. Just to give a simpler answer, on my present arrangement, if I wanted to allow ALL Authenticated SAMBA Users to add files to a given folder, but not users actually sitting in front of my SAMBA server, then I’d create a sub-folder (from in front of my server), and, using root, change the ownership of that sub-folder to ‘userm’ (the invented system user), while keeping its group ‘dirk’ (my user). Then, I could set the permissions of that sub-folder to (rwxr-xr-x)…

      Does that correspond to what you wanted?


Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>