I've managed to figure out how to make what I requested work and will post the instructions.

1. First, you need to figure out what the username you need to add is. The easiest way to do this is to first add log level = 2 to smb.conf. Then start and enable the Samba service. Then connect to the Samba server using File Explorer on the Windows PC while logged into the relevant account (you don't have to open any shared directories). Then open the log file found at /var/log/samba/log.<ip address of Windows PC> and the required username will be noted there. You can now set log level to 0 if you want.
2. Create a Linux account for the Samba user using the useradd command (or use an existing one if you prefer). You don't need to worry about passwords with this account but if you create a new account, you may want to block login on it. This account's username doesn't have to be the same as the name noted above but it would be easier if it was. This account's purpose is for the purpose of file permissions and for Linux to determine what files and directories the Windows user is allowed to access.
3. Create a Samba user with the same name as the Linux account in step 2 using the smbpasswd command. Make sure the password assigned to this account is the same as the one used for the Windows account.
4. If the Samba and Windows accounts don't share the same username, you will have to either add !<Samba user> = <Windows user> to smb.conf or add <Samba user> = <Windows user> to smbusers and username map = /etc/samba/smbusers to smb.conf.
5. And that should be it. Be sure to set the valid users = option on any shares you want accessible only by your Windows account.

OK, I have found an answer myself.

As this is absolutely not obvious from the docs and HOWTOs and whatever, the reason this thing asks for password is because it cannot map guest user to the owner of the directory being shared.

I have NTFS partitions which I need to mount RW so I used the following setup in my /etc/fstab:

/dev/sdb1  /media/disk1  ntfs defaults,noexec,noatime,relatime,utf8,uid=1000,gid=1000 0       2
/dev/sdb2  /media/disk2  ntfs defaults,noexec,noatime,relatime,utf8,uid=1000,gid=1000 0       2

The most important pieces of config are uid and gid (maybe only uid, don't know). They are set to the UID and GID of the user jonnie set up on the server (obviously not root). So, when ntfs-3g will mount these disks, everything will be owned by him.

After that, I have added this user to the Samba registry (or maybe created new identical one, don't care):

# smbpasswd -a jonnie

It asked for password, I have entered the same as for the main system.

After that, I have added the force user and force group settings to the smb.conf:

[global]
  workgroup = WORKGROUP
  netbios name = HOMESERV
  security = user
  map to guest = Bad User

[disk1]
  comment = Disk 1 on 400GB HDD
  path = /media/disk1
  browsable = yes
  guest ok = yes
  read only = no
  create mask = 666
  directory mask = 777
  force user = jonnie
  force group = jonnie

[disk2]
  comment = Disk 2 on 400GB HDD
  path = /media/disk2
  browsable = yes
  guest ok = yes
  read only = no
  create mask = 666
  directory mask = 777
  force user = jonnie
  force group = jonnie

So, most important piece of config relevant to me was force user.

Courtesy of the Samba HOWTO

I finally found the solution:

[global]
workgroup = WORKGROUP
netbios name = NAS
log file = /var/log/samba/log.%m
max log size = 1000
logging = file
panic action = /usr/share/samba/panic-action %d
server role = standalone server
obey pam restrictions = yes
unix password sync = yes
passwd program = /usr/bin/passwd %u
passwd chat = *Enter\snew\s*\spassword:* %n\n *Retype\snew\s*\spassword:* %n\n *password\supdated\ssuccessfully* .
pam password change = yes
map to guest = bad user
usershare allow guests = yes
[public]
path = /home/share
public = yes
guest only = yes
writable = yes
force create mode = 0666
force directory mode = 0777
browseable = yes

creates a share without any user/password login.

You can access it in Windows with \\NAS\public.

I had configured the share to not use a password

Samba does not actually support per-share passwords. This security model was used in the Windows 98 era, but was completely removed from Samba in 2012. (Meanwhile Windows NT/2000/XP series never had per-share passwords in the first place, they were account-based the whole time.)

All SMB security is now account-based (just like in SSH and other protocols) – you provide a username and password to log in to the SMB server, and then access to shares is granted depending on your user account.

so I believe that it wanted a password to connect to the Linux machine

That's almost right.

By default, Samba indeed uses the same system accounts as Linux itself does. The only difference is that the passwords are stored separately – Samba needs to store a NTLM-compatible password hash, as it cannot use the standard Linux hashed passwords.

This means that you must set a "Samba password" for your Linux user account before you can connect – use smbpasswd to do this on the Linux server:

sudo smbpasswd -a jonathan

(The Samba username always needs to match your Linux username in order for file permissions to work correctly, but the passwords can be different.)

I have set the necessary port access in UFW namely 137/udp, 138/udp, 139/tcp, and 445/tcp.

SMB runs over 445/tcp alone. (Unless your client is running Windows 95/98, which needs 139/tcp.)

Port 137/udp is used for LAN hostname resolution (NBNS) and port 138/udp is used for nearby computer discovery ('Computer Browser' service) – both are completely optional for SMB, and in fact both are NetBIOS-based services which most Windows 10 clients have disabled along with disabling SMBv1.

So you have likely run into an issue with Windows 10 Pro and more recent versions, explictly protecting against the exact thing you are trying to do.

Windows by default does not allow accessing SMB services via what it views as insecure guest access. There are two ways to change this.

First, is a way to do this if you have already installed/enabled gpedit, which is tricky in Windows 10 Pro and not covered here:

Run: gpedit.msc
Go to: Local Computer Policy -> Computer Configuration -> Windows Settings -> Administrative Templates -> Network -> Lanman Workstation
Enable: "Enable insecure guest logons"

The other option is in the registry editor:

Run: regedit
Go to: HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\LanmanWorkstation
Click: Edit -> New -> DWORD (32-bit) Value
Name it: AllowInsecureGuestAuth
Set value to: 1
Exit Registry Editor
Reboot

At this point, with either method, you should be able to see secured shares without a username and password. HOWEVER, please note there is no "guest" option when authenticating by default. So, it MAY still ask you for a username/password. If it does, enter in anything. It doesn't matter. When it fails, the server will use the 'map to guest' setting and fall back to the guest user and allow visibility.

Good luck and let me know if this works!

This was the key option to set to resolve this issue:

[global]
    map to guest = bad user

From:

$ man smb.conf | grep -m1 -B8 -A16 'Bad User'

Bad User - Means user logins with an invalid password are rejected, unless the username does not exist, in which case it is treated as a guest login and mapped into the guest account.

You have two possible approaches:

• You can access the files as guest.
• You can configure accounts that have to authenticate.

A guest account is fine if all the users should have access anyway, but it's not what you desire, so you must configure one ore more accounts. Samba allows different kinds of accounts, they are configured with the passdb backend option:

• smbpasswd - The old plaintext passdb backend. Some Samba features will not work if this passdb backend is used. Takes a path to the smbpasswd file as an optional argument.

• tdbsam - The TDB based password storage backend. Takes a path to the TDB as an optional argument (defaults to passdb.tdb in the private dir directory.

• ldapsam - The LDAP based passdb backend. Takes an LDAP URL as an optional argument (defaults to ldap://localhost)

The smbpasswd is the oldest and most simple, it's just a plain file similar to /etc/passwd. The tdbsam uses a binary tdb file and can store more information about user accounts. LDAP is more interesting if you want to manage many accounts and/or already have an LDAP server.

See also smbpasswd for adding accounts and changing password.

Basically, what I think I want but don't know how to do is to have Samba map any user that connects to a specific user on the server (I think it can be done with a user map file), and then additionally, which I haven't found out how to do, have it accept any password as valid (we have PCs with the same user account names and different passwords).

Both can be done using the same map to guest = bad user option in Samba, but unfortunately, "emulating" Guest access in this way is exactly what "Guest" access is in SMB.

One problem is that SMB servers do not receive passwords at all; they use NTLM when outside an AD domain and Kerberos within a domain. NTLM is a challenge/response protocol that additionally produces a session key to both peers, which SMB then uses to authenticate each packet (as well as the entire handshake in SMBv3 – this provides a form of MITM protection when negotiating the encryption key for SMBv3).

However, for challenge/response protocols like NTLM or CHAP to work properly, the server must already know the user's password (shared secret) – without it, the server cannot derive the NTLM session key from just the client's response alone (being able to do so would defeat the point of the protocol), and therefore cannot correctly 'sign' the SMB messages.

So the way "Guest" access in SMB works is that the server must indicate to the client, "Your credentials didn't work but I accepted you as guest anyway", so that the client would know to not require SMB message signing. If the server accepted arbitrary NTLM responses but didn't send the "Guest access" indication (if I'm reading the protocol docs right), this would result in the client failing to connect anyway.

In short, you cannot really emulate guest access without implementing actual guest access. Selecting map to guest = bad user means Samba has to indicate that this is a guest session.

(Although according to docs, only the Enterprise or Education editions of Windows 10 disables this by default, while Home/Pro does not – and if you do not have an AD domain, I think it's unlikely that you'll be using Enterprise...)

What you could do instead is the opposite: Windows does not require the logged-in user to be used for SMB – on failure it will prompt you for credentials (and will even let you save them), so you could use normal SMB authentication but create a single account with a password that everyone knows (write it next to your office Wi-Fi password). You can have a batch script to pre-save the password using cmdkey.

(This also works when accessing a domain-joined file server via Kerberos.)

As for this specific error message:

Multiple connections to a server or shared resource by the same user, using more than one user name, are not allowed. Disconnect all previous connections to the server or shared resource and try again.

The problem here is that when a user on Windows first makes contact with a server it automatically passes that users' local login username. If you have a public share it remembers that it took that username successfully. When you try to connect to a private share and don't pass the exact same username and password, it thinks you are trying to access with another name.

Some workarounds:

1) Map the Windows user to the local Linux user - this is useful for Win10 users who log into their systems with a Microsoft account.

• Create a file at /etc/samba/smbusers

• Map the local Linux user to the Windows user by adding the conversion to the file. For example:

luci = [email protected]
john = "John Smith"

• Then add a reference to the map in /etc/samba/smb.conf in the [global] section:

username map = /etc/samba/smbusers

• Finally restart smbd: sudo service smbd restart

2) Make another connection to the Linux server

Windows can address a Linux server in two (three in Win10) different ways. By hostname, by ip address, or by mDNS name (Win10 only):

\\ubuntu\Protected
\\192.168.0.100\Protected
\\ubuntu.local\Protected

Even though all of these point to the same machine, Windows sees them a three separate hosts.

3) Map the "network drive"

When mapping a drive, select the "connect using different credentials" option.