Samba simplified

Agenda

This post aims to cover Samba

• for a linux user
• who is looking to set up network file shares for personal use
• in the 2020s (and not the 2000s)

What do I mean by those delimitations?

Well, first, if you’re primarily a Windows user, looking for a DIY NAS box, you will likely not care deeply about how the files appear to the box OS, only about what their properties are on Windows and possibly other clients. A linux user, on the other hand, might have an interest in ownership and permissions on the system. A Windows user may also consider whether or not shares and services are accessible on legacy Windows versions, like Vista or Windows 7. This is of less importance to most linux users.

As for personal use, well, Samba can do a lot more than just serve network shares. Think managing the authentication and access rights and permissions of hundreds of office PCs on a large network with multiple routers. This guide is only about making files available over a single, local subnet. In other words, I do not need to worry about accessing shares on other subnets.

Finally, Samba carries with it a lot of old crud that we can happily jettison nowadays (2022, as of writing), so it is a lot simpler to set up and wrap you head around than it used to be.

With configuration of shares I’m going to start simple and build on it in two following stages:

• First, I create a basic read-only share
• Then I allow one or more users write access
• And finally I manage permissions and ownership of files created by users with write access

I am going to cover the server settings required but also touch on how various clients interact with the setup and what they require of settings. I have found that a Samba filesharing setup can be really hard to troubleshoot because it’s often infuriatingly diffcult to tell if there is a genuine problem with you server config – or if it’s just a client that’s weird or picky about configuration parameters.

Name resolution in 2022

When I mentioned “old crud” earlier it’s because there are a few Windows native services and protocols that used to go along with a Samba setup and that I will not attempt to implement here. However, I will briefly try to explain what they are and why they no longer matter.

Samba is a free software implementation of the SMB protocol. To serve SMB requests, Samba runs smbd (the Samba daemon). So far so simple.

For years, it has been a regular feature of a Samba setup to have a service running next to smbd called nmbd (netbios… mb… daemon? I have found neither acronym nor backronym explanations for the name). Also, guides will talk of NetBios, WINS, etc.

NetBios is/was an API, an agreed upon convention for network communication adopted by early Windows. SMB used to work on top of NetBios foundations but hasn’t since version 2. However, part of the NetBios convention was the NetBios way of resolving network addresses for named hosts and that bit stuck around for a fair bit longer. Name resolution for SMB was needed for the same reasons as anywhere else on networks: IP addresses change (in a DHCP setting), names stay the same. A NetBios client prefers asking a central authority, a WINS server, to resolve names for it, but it will fall back on broadcasting across the subnet if no WINS server responds. So WINS was optional/unnecessary for a home network.

So why don’t I need NetBios? Well, for one thing, even Microsoft is abandoning it in favour of mDNS, a linux native protocol that works well. I have written more on mDNS in another post. Said post also goes into more detail about LLMNR, a Microsoft mDNS alternative that has also been used in conjunction with SMB, and why it’s also not worth setting up or supporting. Enabling mDNS resolution on all hosts is a much better base for Samba in 2022 than trying to emulate a Windows network from the turn of the century.

The short version is that I will not enable or start nmbd, only smbd.

Missing out

Despite my dismissive attitude towards nmbd, I think it’s worth noting explicitly what I’m losing by removing nmbd and NetBios support. Samba and SMB both are so old technologies and wrapped in strange acronyms that it can often feel like penetrating a jungle. Understanding what does what is not an easy task.

First of all, it obviously means that I will not be able to use NetBios name resolution. As I’ve pointed out I don’t think that’s much of a loss, assuming that I can depend on mDNS. If anybody has a very strong preference for single word, domain-less names (i.e. HOSTA, rather than HOSTA.local) that may be a sacrifice. Since names like that can be local hostnames as well as NetBios names, I think they just muddy waters that don’t need muddying.

WINS is also out. While the utility of names useable on the subnet can be replicated with mDNS, there is no direct WINS standin. In other words, I will not be able to access named shares on other subnets. In an enterprise setting with multiple subnets, this is obviously an important consideration. I only have the one subnet so I can live without it. By losing NetBios/WINS I also make it hard for old versions of Windows without support for mDNS to find my shares. Support can however be added with Apple’s Bonjour Print Services for Windows.

Finally, browsing, elections and master browsers are also going out the window. Even if these words mean nothing to you, you will probably have tried exploring the Network section in Nautilus or the Network Neighbourhood in Windows and locating what you’re looking for. This ability to browse and click, rather than manually enter addresses, is not part of the setup.

The technical reason is that nmbd is responsible for Samba’s participation in the SMB solution of providing an authoritative list of available ressources as well as for name resolution (whereas on Windows these two roles are separated, I believe). In a later post I will explore DNS-SD as an alternative way to advertise services on top of mDNS.

For now, I will do without and “discover” services by knowing that they are where they are, because I set them up to be there. In the Clients section I will go over how to mount a share without browsing (spoiler: It’s just entering smb://HOSTNAME.local/SHARE_NAME in your file manager of choice)

Server roles and security modes

Sambas configuration is contained in the smb.conf file located in /etc/samba. It has a [global] section for (duh) global settings. All other sections define shares, be they printers or drives.

Two global settings are central to the kind of Samba installation I will have and despite their simplicity, they are surprisingly easy to get wrong. I blame Windows networking and Samba config option naming in equal measure. These settings are:

• server role
• security

The two do constrain each other, as not all security settings are compatible with all server roles, as will become apparent.

To explain server role let’s start with a binary: Either it’s standalone or it’s domain-something-or-other. Given the interest I layed out at the top of the post, I most definitely want the standalone option but it will be clearer once I explain what standalone isn’t. I.e. domain-something-or-other.

The latter option would mean that my Samba server would take on one of several roles (basically, either a commanding or rank-and-file member) in either a Windows NT style domain or an Active Directory setup. Regardless of the particulars, any of these options involve accounts that are not local to a single host. Machines in these contexts either authenticate users for other machines or ask other machines to authenticate users for them.

In contrast, an account on a standalone server is specific to a single samba instance. The account is created on that instance and when a client calls, the account is authenticated on that instance.

If I have three shares on three different machines on my network, would it be neat if I could access them using a single account? Yes. Is it worth the hassle of setting up a Windows domain on my network? No. Domains make sense when many people need to share – as in work on, write to – files across multiple hosts. Having to recreate the same account for myself or a group containing myself on three hosts is, as I said, barely an inconvenience. Having to do it for twenty users is a bit annoying. Hundreds of users? A nightmare. However, as outlined in the beginning, this is not that scenario.

server role = standalone server

Choosing a standalone server limits my options somewhat for the security setting. First, though, I need to pay careful attention to a subtle distinction in naming, namely between security level and security mode. You can sort of think of it as a two-tier hierarchy with mode being subservient to level.

Security level is either share or user. User level security is authentication, then authorization. We figure out if you are who you say, you are. Once we know that we will either allow or deny what you try to do on various shares depending on what you – as a registered user – is authorized to do. One user may have write access to share_a, read access to share_b; another’s only authorized to read either one. Since permissions are derived from user identity, authentication as a specific user is central.

Share level security dispenses with authentication. We simplify matters to “access, no access” on a share-by-share basis. Think of a guard at night asking for the watchword, so as to distinguish friend from foe. It’s pretty basic. I can set different passwords for different shares (or different watchwords for different camps) but I cannot make distinctions between different users’ access. Once you’re inside the camp, you can do the same everyone else can.

The need for distinguishing security modes comes from the fact that there are multiple ways to authenticate users. As I said, share level security dispenses with authentication, so it has only the one single security mode, just called share:

Under the user security level, you have four security modes: user, domain, ADS, and server. As you can probably guess, domain and ADS relate to Windows NT domain and Active Directory setups, respectively. Since a standalone server is part of neither of these, they are not options here. server is a deprecated, terribly named option that’s closely related to the domain setting. In other words: Not relevant either.

That leaves us with user. This setting simply means that the Samba server is itself responsible for authentication, using a – usually local – password database to check whether you are who you say you are. It’s also the default.

The share security setting can be useful for simple, usually read-only setups. With share level security you don’t need to specify users or groups, or set user passwords. I will, however, go with the user setting:

security = user

The usual reason to decry the share security level is everyone shares the same password! In a small home environment that is not a concern. I have two different reasons fornot going with share security, though.

First, I do need write access to some shares. Despite the absence of an authenticated user in share, Samba does need a user, any user, to do file operations on the underlying linux filesystem. It’s simpler to have a clear indication of who that user is by explicitly authenticating as that user.

Secondly, I also want more granular control. For instance, I have a music folder on a share. I want members of the media group to only have read access, so a rogue music player does not accidentally delete my entire collection. My primary user on the other hand needs read and write access so I can add new albums (legitimately acquired from bandcamp, thankyouverymuch).

Other global settings

Server role and security are by far the most important bits as most other settings can safely be left to defaults. However, it is worth going over both those that can and should be ignored and those that are good to know.

First among the first class: workgroup. If I’m not using NetBios, workgroup shouldn’t really be important. Workgroups help organize browsing by grouping shares. Think accountancy shares for the accounts, sales shares for the salespeople, etc. I have disabled nmbd, so there will be no browsing and so, organising it is not a concern. Note that there is a difference between browsing something and having access to it. Workgroups help organise the former, but what you have access to depends on who you are as a user. So just to be clear, workgroups is not a security setting.

However some clients may insist on a workgroup setting, so to keep them happy I use the same WOKRGROUP on all my Samba instances. Note that the workgroup setting sets the domain with server role settings that use domains. So if a client asks for – and insists on – a “domain”, this should also be what it’s fed.

workgroup = WORKGROUP

Server string is just an identifier but a handy one.

server string = HOSTA Samba

What about security? I’m not overly concerned with security in this setup mostly because no files on my shares are particularly sensitive. For personal files, I prefer local copies, synced up by Syncthing. Also I have a somewhat misplaced faith in my network just because I haven’t given my wifi password to the robot vacuum cleaner, despite repeated pleadings. Nevertheless, it’s worth going over the main settings. Note that I’m only considering one aspect of security here: The risk of having data or cleartext credentials intercepted in transit.

The main variable here is the version of the SMB protocol being used. Older ones are more likely to be vulnerable. There are options to set the minimum and maximum version (i.e. oldest and most recent, respectively) that can be negotiated between server and client, however, I am not going to use them. Server and client work out the best protocol version by themselves.

Recent versions (fall 2019 and onwards) of Samba use defaults for minimum protocol that rule out the oldest and least safe versions, anyway:

SMB1 is disabled by default
———————————–

The defaults of ‘client min protocol’ and ‘server min protocol’ have been changed to SMB2_02.

This means clients without support for SMB2 or SMB3 are no longer able to connect to smbd (by default).

https://www.samba.org/samba/history/samba-4.11.0.html

I can test this by asking Samba to print out all settings for the currently running Samba daemon and cut out all but the relevant settings. This is the result with no explicit protocol settings:

[ ~ ] testparm -sv 2> /dev/null | grep -E "server (min|max) protocol"
        server max protocol = SMB3
        server min protocol = SMB2_02

Note that SMB3 in recent versions of Samba defaults to subprotocol SMB3_11 which is also used by Windows 10.

Basically, my approach here is “the developers know best” and “less is more”.

What about encryption of the connection between server and client? I have said this before but it’s kind of important when talking about encryption to be clear about what is being encrypted. Sadly, the Samba documentation isn’t. I have an option to set how much the server should suggest/insist on encrypting the connection but … what if I don’t use encryption? Does the setting only apply to data transfer while authentication – the bit where the client sends username and password – is still encrypted? Or is it just sent in cleartext over an unencrypted connection? The man page isn’t clear on that. So I’m going to err on the side of caution in the following.

The setting in question is server smb encrypt. The setting has some caveats for SMB1 but the defaults for modern Samba version is to disallow SMB1 (see above) so that is not relevant. Basically, I can choose between leaving it to the default or setting encryption to desired or required. Again, the man page leaves a lot to be desired:

Leaving it as default, explicitly setting default, or setting it to if_required globally will enable negotiation of encryption but will not turn on data encryption globally or per share.

Setting it to desired globally will enable negotiation and will turn on data encryption on sessions and share connections for those clients that support it.

Setting it to required globally will enable negotiation and turn on data encryption on sessions and share connections. Clients that do not support encryption will be denied access to the server.

https://www.samba.org/samba/docs/current/man-html/smb.conf.5.html#SERVERSMBENCRYPT

The required setting is clear enough but what exactly is the difference between default and desired? My best guess is that it’s a question of whether or not the client explicitly asks for encyption? Which it would need to with default whereas with desired it would be inferred from… the negotiated protocol version? Or some other characteristic of the client/negotiation?

To cut through the uncertainty, I am going to start with required and drop down to desired if there is any sign of trouble. If I don’t come across trouble automatically, I will to seek it out by testing with some old, outdated clients.

Shares

As I said at the top, all sections of smb.conf that are not [global] designate shares. The name of the share is designated inside the square brackets. It’s common (and probably wise) to stick to ASCII names but in the name of science, I checked and yes, Samba does allow unicode characters in share names.

Don’t expect Windows XP to cooperate, though.

A read-only, semi-public share

For a shared, semi-public, not-very-secret read-only share, a common suggestion is to use share level security (see above) and set it to not ask for passwords. Here’s my alternative suggestion for the same use case.

[music]
   comment = music folder on HOSTA
   path = /mnt/music/
   valid users = @media

path and comment should need no explanation. valid users designates the users that are allowed to access the share (whatever it’s access parameters, writeable, read-only, etc.) Here it is set to @media which means members of the media group.

A word on Samba users. Within the standalone server role, user management is really quite simple. A samba user account has to match a linux user account on the host with the same name. But a linux account on the host does not automatically gain a Samba user account. One has to be created by root running

smbpasswd -a existing_username_on_host_machine

and then given a password that may or may no be the same as the user’s password on the host. By default, samba maintains it’s own password database separate from the system. The arch wiki has more details.

Fortunately, groups on the system do not have to be recreated in Samba. All Samba needs is a way to link it’s own user account to an account on the system – then it can figure out for itself if any given user is, say, a member of the system’s media group.

There are two important defaults here that I rely on:

guest ok = no
read only = yes

guest ok is a synonym of public. read only is an inverted synonym of writeable (i.e. read only = yes ⇔ writeable = no)

Guest is not okay. In other words, you do need to authenticate as a user in order to gain any access. The share is read only in order to prevent accidental writes or deletions. If an application (running as a system user that’s a member of the media group), say Kodi, wants to add metadata to my music it can do it in a separate location, apart from the media files themselves. As I said, these are the default share settings but it doesn’t hurt to make them explicitit, if it makes it easier to read the share definition.

Also, browseable is by default set to yes by default. Does it make any difference if I have not enabled nmbd and so disabled “browsing” in the general sense? Well, yes. Here is the result when I ask the host to list shares with browseable = yes:

[ ~ ] smbclient -U media -L cdg.local
Password for [WORKGROUP\media]:

        Sharename       Type      Comment
        ---------       ----      -------
        MUSIC           Disk      music on cdg
        IPC$            IPC       IPC Service (CDG Samba Server)
SMB1 disabled -- no workgroup available

(-U specifies the user to authenticate as and -L asks for a list of shares/services) Here’s what it says when I explicitly set music’s share to browseable = no:

[ ~ ] smbclient -U media -L cdg.local
Password for [WORKGROUP\media]:

        Sharename       Type      Comment
        ---------       ----      -------
        IPC$            IPC       IPC Service (CDG Samba Server)
SMB1 disabled -- no workgroup available

As can be seen, you don’t need nmbd in order for a Samba instance – when directly asked – to tell you what shares it has. Since I’m not relying on browsing in general, I might as well turn this off. I will address the IPC$ share later on.

So why is this approach better than the share level model, I contrasted with at the start of this section? Two reasons. First, I think the main reason the share model is suggested is because people who are unfamiliar with linux user management think it’s less of a hassle than creating Samba accounts and matching them up with linux user accounts. I don’t have that problem. On the contrary, the problems of matching an anonymous user to a linux user account (in case of writeable shares) would be a much greater headache to me.

Secondly, because share level access wouldn’t allow me to do the following.

… but with write access for primary user

The share above is read only, yes? What happens if I add the following setting to the share:

write list = my_user

Here’s what the man page says:

If the connecting user is in this list then they will be given write access, no matter what the read only option is set to.

https://www.samba.org/samba/docs/current/man-html/smb.conf.5.html#WRITELIST

That then accomplishes what I said I needed in order to add new albums to my music collection. Read access for applications running as system users, like Navidrome or Kodi, write access for me. If my_user is also a member of the media group, write list takes precedence.

How does it translate to linux ownership and permissions?

So, now I have write access. Great. But when I drop an album into my share who does it belong to? Will kodi even be able to read from it?

I need to take a step back first before answering those questions. In the first, basic share definition, I said that members of the media group had read access because the share had a valid users line. That’s true but Samba works on top of system settings. Any permissions in Samba is constrained and circumscribed by the reality of what users can do on the system. If the folder /mnt/music/ is not accessible for any given user, it doesn’t matter if they’re members of media group or what Samba says. The access will just fail. For the setup I have so far, it would be best if the folder and it’s contents are owned by my_user:media and have permissions of, say, 755 (drwxr-xr-x) or 750 (drwxr-x—). That would give both my_user and members of the media group the permissions they need on the directory, for the permissions they have on the Samba share to work.

That applies to existing files and directories. The questions, however, are about files created using Samba. I’ll mostly answer it by addressing two faulty assumptions I had about this issue. This blog is nothing if not a continued exposure of my faulty assumptions to the extent that it really ought to be on the masthead.

Born to be read

The first is that I thought that whatever I told Samba about how to create files would be circumscribed by the user’s umask. That is to say, if I told Samba to create files with typical permissions for user (all), group and others (read, execute) (755), it would get cut down by the user’s restrictive umask setting. In this scenario a umask of say 027 would overrule Samba’s leniency and deny “others” any rights, resulting in new files created with 750 permissions. In other words, this was based on the idea that both umask and Samba would need to give assent for a permission bit to be set (aka. bitwise AND).

That is not the case. Samba either relies entirely on it’s own file creation settings (default) or derives new files’ permission sets from the parent directory (when using the inherit permissions setting). In either case, umask does not play a role.

I like the simplicity of inherit permissions. Just use chmod on the share directory once and Samba follows your lead. However there is just as good a case to be made for explicitly instructing Samba on what permissions a file is to be birthed with. That second approach requires two settings, create mask and directory mask:

create mask = 660
directory mask = 770

There are logical reasons for why these really are masks but in practice they are just the permission sets that files and directories are created with, respectively. Or in the words of the man file:

Any bit not set here will be removed from the modes set on a file when it is created.

https://www.samba.org/samba/docs/current/man-html/smb.conf.5.html#CREATEMASK

create / directory mask sets permissions on new files. the samba user creating or copying a file into the share is translated one for one into a local user on the host and that user becomes the owner of the file. All that is missing is determining the group it is assigned to. By default, file creation follows the same rules as normal: The file is shared with the file owner’s primary group.

If inherit permissions is in force, however, the primary group can be overruled by using setgid on the directory, just like normal. If it is not, the group a file is assigned to can be forced by the force group setting.

force group = media

I think whether the “inherit permissions” approach or the “Samba settings” approach is better depends on the extent to which the share is purely accessed by Samba. If there are other applications or non-Samba users contributing files I would need to set things like umask and setgid anyway. That would make inherit permissions look very tempting. On the other hand, if all file operations on the share go through Samba, the simplicity of create mask, directory mask, and force group win out, I think.

What even is a Windows ‘archive’ attribute?

The second of my misapprehensions is that I had read at some point that, on Samba shares, linux filesystem permissions were mostly set and used to reflect unrelated Windows file properties. Windows and linux have very different file properties/permissions/metadata – and ways of registering those properties. The very short version is that the Samba developers in the olden days hatched a scheme to set linux file permissions not according to their meaning on linux but merely as a way to record and reflect completely unrelated Windows file properties (like read-only, archive, etc.) This would make sense if I’m never going to interact with the files on linux. Then the file permissions are of no interest or consequence and might as well serve some other purpose.

I’m sort-of happy to say that this at least is not a misconception; this one is actually grounded in fact. However, it is not really a concern because a) there are settings that govern this and most of them are turned off by default and b) the whole horrid thing is turned off if Samba is using extended attributes instead. The there’s no need to appropriate file permissions. Extended attributes is a file metadata scheme that relies on file system support.

There are a ton of nerdy details I could get in to here, but I’ll restrain myself and simply say that the only important thing is we need to test to see if store dos attributes (the setting that toggles using extended attributes) is turned on…

[ ~ ] testparm -sv 2> /dev/null | grep "store dos attributes"
        store dos attributes = Yes

… and whether my filesystem carrying the shares supports and is mounted with support for extended attributes…

[ ~ ] grep xattr /proc/fs/ext4/sdb1/options
user_xattr

Both of these are pretty much given since store dos attributes = Yes is the default and pretty much any file system you can think of supports extended attributes and has only options to explicitly disable it, not enable it (because defaults). However, better to be sure?

If for whatever reason Windows file properties are not (cannot be) stored as extended attributes, Samba will fall back on mapping them to linux file permissions. If you care more about linux file permissions than Windows file properties, I suggest turning off map (archive|hidden|system|read-only) though only map archive is on by default.

The IPC$ ‘share’

When using smbclient to list shares, it included a strange “IPC$” share. What is that and do I need it?

These are suprisingly difficult questions to answer, as documentation is sparse. IPC is an “inter-process communication share” which translates to a service you can talk to on Windows. Why is it implemented in Samba, then? Because some (Windows) clients want to talk to it… about shares… I think. Some people mention is as a concern that you can alledgedly talk to it anonymously, i.e. without authenticating, but I did not find that to be true. All attempts at connecting to it with smbclient required me to authenticate as a user.

Do I need it? Ask again later. I don’t think so. The most common suggestion involves disabling the automatic creation of the share by creating it manually, thus overriding the default behaviour. This suggestion comes with a handy share configuration. Basically it restricts access to IPC$ to the localhost so you can access it should it be relevant. Sadly, something has changed since that suggestion and Samba now very clearly says that the share is faulty. Following the suggestion, then, does not so much restrict access as sabotage it. Which doesn’t seem right.

Casually perusing testparm -v output, however, led me to nt pipe support:

This boolean parameter controls whether smbd(8) will allow Windows NT clients to connect to the NT SMB specific IPC$ pipes. This is a developer debugging option and can be left alone.

https://www.samba.org/samba/docs/current/man-html/smb.conf.5.html#NTPIPESUPPORT

Which can be set as follows:

nt pipe support = no

The description on the man page led me to believe that it was merely a setting that discriminated against Windows clients so that the share would still be accessible from linux clients, at least using the official smbclient. However:

[ ~ ] smbclient -U media -L cdg.local
Password for [WORKGROUP\media]:

        Sharename       Type      Comment
        ---------       ----      -------
SMB1 disabled -- no workgroup available

I figured this would surely break the mount on Windows but so far my Windows 10 work laptop has continued to mount the share after a couple of restarts.

Is there any reason to do this? After all, the documentation says to leave it alone. Well, unsurprisingly, this feature has had at least one remote code execution vulnerability with a score of 9.8. Yes, it’s fixed in recent versions but that doesn’t mean there are not or will not be others. It’s definitely not essential to do this but I do like paring down as long as it doesn’t break stuff.

Access controls

Before moving on to the client side, I think it’s appropriate to touch on the question of access controls, simply because they’re important to keep in mind as a source of issues when setting up a share.

Access control is anything that restricts users’ access to the system’s ressources, including files. It’s important to understand that the restrictions associated with the traditional user:group permissions are but one such measure on many linux distros these days. Software with this role includes SELinux and Apparmor among others.

Obviously such restrictions can dramatically impact Samba sharing: You are 100% sure that both your your linux and your samba user have every right to a share, yet something else still says no. While there are (usually) good reasons for implementing additional access controls, they make debugging applications like Samba much more difficult as you now also have to contend with “outside forces” obstructing your shares. I can definitely understand Daniel Aleksandersen of ctrl.blog fame when he advocates for just turning it off.

Detailing access controls would make for a separate blog post so I’m just going to quickly showcase an error I recently got on a Manjaro host to illustrate my point. After what looked like a successful authentication (the user was found, the password accepted, etc.), the attempt to access a share devolved in to this:

[2022/08/21 12:59:54.025123,  5] ../../source3/passdb/pdb_interface.c:1436(pdb_default_uid_to_sid)
  pdb_default_uid_to_sid: Did not find user mads (1000)
[2022/08/21 12:59:54.026127,  5] ../../source3/passdb/pdb_tdb.c:602(tdbsam_getsampwnam)
  pdb_getsampwnam (TDB): error fetching database.
   Key: USER_mads
[2022/08/21 12:59:54.026167,  5] ../../source3/passdb/pdb_interface.c:1436(pdb_default_uid_to_sid)
  pdb_default_uid_to_sid: Did not find user mads (1000)
[2022/08/21 12:59:54.035396,  5] ../../source3/passdb/pdb_tdb.c:602(tdbsam_getsampwnam)
  pdb_getsampwnam (TDB): error fetching database.
   Key: USER_mads
[2022/08/21 12:59:54.035445,  5] ../../source3/passdb/pdb_interface.c:1436(pdb_default_uid_to_sid)
  pdb_default_uid_to_sid: Did not find user mads (1000)
[2022/08/21 12:59:54.036386,  3] ../../source3/smbd/smb2_server.c:3954(smbd_smb2_request_error_ex)
  smbd_smb2_request_error_ex: smbd_smb2_request_error_ex: idx[1] status[NT_STATUS_ACCESS_DENIED] || at ../../source3/smbd/smb2_create.c:338

The logs, while plentiful, say nothing about access control, but instead throws me lots of red herrings. I investigated the password database (pdb), users, domains, etc. Only by continually searching random log notices did I find a manjaro forum post with an issue that looked like mine, and a suggestion to make an AppArmor exception for Samba. On a sidenote, this also explained why another host, running Arch Linux, did not exhibit the same problem, despite being on the exact same version of Samba! Manjaro comes with a bundle of software preinstalled, whereas on Arch you have to consciously add it yourself. Clearly I hadn’t opted in to AppArmor on the Arch host (for better or worse).

The short version: If your distro has SELinux or AppArmor or the like enabled, keep that in mind when debugging.

Mounting and clients

Because I have made some slightly unusual choices in my setup I figured I would try some at least semi-consistent testing across various platforms. Would they mount the shares and if not, what was the objection?

Are the shares really not showing up in “Network” sections?

I’m not running nmbd so they shouldn’t. However, you never know. Maybe somebody had hacked a port sniffing solution into Windows. Or something. So I checked in Windows File Explorer, Dolphin and Caja, the default file manager on the MATE desktop and a fork of Nautilus. None of them found anything by themselves.

For me this is neither bug nor feature. If advertising the shares is a requirement, the Arch Wiki has a suggestion.

Basic share mounting

So how do I mount a share that’s not showing up in “Network”? It’s pretty simple, just enter the necessary information manually.

Linux

Step 1. Open up most any linux file manager. I’m currently using Caja so the following is based on that.

Step 2. Hit Ctrl+L or click the location bar. In some file managers (Nautilus, maybe Dolphin?) it defaults to a nice looking “breadcrumb” view of the current location but when clicked will turn into a text input where I can enter a location manually.

Step 3. Clear the current location with DEL or BACKSPACE.

Step 4. Enter smb://hostname.local/share (where hostname is the name of the host running the samba server, and share is the name of the share being mounted).

Note that this assumes working mDNS on both server and client. If not, use the local IP address instead.

Step 5. Enter username and password of the Samba user account to use. If asked for port, leave it alone for the file manager to use the default port 445. If asked for domain, either enter the value of the workgroup setting or leave it empty. See section below on workgroup for details.

Step 6. Bookmark the location once a connection has been established.

Windows

Step 1. Open File Explorer

Step 2. In the left side Navigation pane, scroll down and locate the Network icon.

Step 3. Right-click on Network and choose Map Network Drive.

Step 4. Enter \\hostname.local\share (where hostname is the name of the host running the samba server, and share is the name of the share being mounted) in the Folder input. Reconnect at sign-in is optional, Connect using different credentials is not. Whatever the user I’m authenticating as on Windows, it will not be useful on the share.

Step 5. Ask for More choices and Use a different account if the username or “domain” (workgroup) suggested isn’t the right one.

Step 6. Enter username and password

Step 7. Bookmark the location once a connection has been established.

Be aware that Windows is not capable of imagining one user having multiple accounts on the same domain and host and will refuse to mount different shares on the same server with different users.

[ ~ ] smbclient -U media -W ABCDEF -L \\\\localhost
Password for [ABCDEF\media]:

        Sharename       Type      Comment
        ---------       ----      -------
        MUSIC           Disk      music on cdg
        IPC$            IPC       IPC Service (CDG Samba Server)
SMB1 disabled -- no workgroup available

log level = 3 passdb:5 auth:5

Jul 25 21:32:41 CDG smbd[789063]: [2022/07/25 21:32:41.859256,  1] ../../source3/smbd/smb2_sesssetup.c:283(smbd_smb2_auth_generic_return)
Jul 25 21:32:41 CDG smbd[789063]:   reject session with dialect[0x0311] as encryption is required

Samba drum © danielkirsch / 359 images, Pixabay License