Right out of the box, an Ubuntu 18.04 machine will not see any Microsoft Windows machines on the network, and Windows machines will not see it. Unfortunately, there is an incredible amount of work necessary to get it to work properly. So, here are my notes on setting up an Ubuntu 18.04 Linux workstation to act both as a Samba server and as a Samba client in a Windows Workgroup.
Server
Here is my setup script, which works, but be sure to keep reading, because the script alone is not enough.
sudo apt-get install samba winbind libnss-winbind
sudo ufw allow Samba
if [[ ! -f /etc/samba/smb.conf.original ]]; then
sudo mv /etc/samba/smb.conf /etc/samba/smb.conf.original
sudo write /etc/samba/smb.conf <<EOF
# See /etc/samba/smb.conf.original
[global]
map to guest = bad user
server role = standalone server
server services = smb
unix extensions = no
wide links = yes
client max protocol = NT1
dns proxy = yes
wins support = yes
# This is necessary here so that user-specific clones of "[homes]" will be browseable.
browseable = yes
[homes]
read only = no
comment = %U's Home Directory
# browseable = no is necessary here, or else "homes" will appear in the browse list.
browseable = no
valid users = %U
EOF
fi
The above script will install samba and configure it. (If it has not been installed already.)
The old configuration file is saved as
/etc/samba/smb.conf.original so that it can
be consulted in the future.
After this, windows machines will successfully list my Ubuntu machine among other machines under "Network", and if I click on it I will be prompted for credentials. When entering credentials I must remember the incredible, ages long "Domain" gotcha: do not just enter the username, enter
MACHINE\username instead. Then, Windows will correctly list the shares.
The
[homes] section in the above script defines a share which will magically have the same name as the authenticated user, and will magically map to the user's home folder. That's all I need.
A minor annoyance is that
testparm will always report the following error:
rlimit_max: increasing rlimit_max (1024) to minimum Windows limit (16384)
After much searching around on the interwebz I found that:
- It is allegedly a warning, not an error, so it allegedly does not matter, and
- There simply seems to be absolutely no way to make it go away, so you better get used to it.
Client
Things turn out to be considerably more difficult in making the Ubuntu machine successfully act as a client. In the beginning nothing worked.
Under Nautilus (the Gnome file manager) going to "Other Locations" and trying to open "Windows Network" would fail. Trying to "Connect to Server" with
smb://servername would also fail.
The
smbtree command would initially list only the local host, and if you let things stand for a while, it would eventually also show other machines, but not their shares.
The
smbclient command would fail with a very informative error message saying "Error NT_STATUS_UNSUCCESSFUL".
The
nmblookup command would fail with a very informative message saying "name_query failed to find name".
The interwebz abound with discussions about the connectivity issues between Ubuntu 18.04 and Windows, but none of the solutions offered seemed to work for me. Some of the discussions even arrive at the conclusion that it is impossible to get it to work.
So, I started troubleshooting with
smbtree and
--debuglevel=3. (Because
debuglevel=10 is like trying to drink water from a fire hydrant.)
The first thing I noticed was that samba was complaining about it being supposed to use a WINS server, but having no address configured for it. I suppose that if there is no mention of WINS in
smb.conf, then by default samba will neither try to act as a WINS server, nor will it know who the WINS server is. Which kind of makes sense, but what does not make sense is that samba does not complain in any way about this erroneous situation during startup, and instead we need to look at debug information in order to discover it happening.
I have no WINS server on my network, because this is apparently an advanced feature that is only found on Windows Server products, so I added "
wins support = yes" to my
smb.conf, to tell samba to act as a WINS server for me, because Linux gives these things for free, that's how it rolls.
By doing that, the error about WINS went away. Unfortunately, everything else remained as broken as before.
Then it dawned upon me to look at what is going on with the firewall. I had enabled the firewall and I had added the necessary rules to allow samba, but you never know.
Again, because trying to read the logs is like trying to drink water from a fire hydrant, I had to write the following little script:
ufwwatch
#!/bin/bash
function process
{
local -a array=( ${1// / } )
local time="${array[2]}"
local action="${array[7]%\]}"
if [[ "$action" != "BLOCK" ]]; then return; fi
local -a remainder=("${array[@]:8}")
local -A map=()
for part in "${remainder[@]}"; do
local -a subparts=( ${part//=/ } )
local left=${subparts[0]}
local right=${subparts[1]}
map[$left]="$right"
done
echo $time $action ${map[PROTO]} in=${map[IN]} out=${map[OUT]} src=${map[SRC]}:${map[SPT]} dst=${map[DST]}:${map[DPT]}
}
echo Displaying blocked packets as they happen:
tail -f /var/log/ufw.log | while read line; do process "$line"; done
By running this script I discovered to my astonishment and horror that some packets were in fact being blocked each time I tried running
smbtree. The packets were UDP packets arriving from my Windows machines to my Ubuntu machine. The port on the originating machine's side was 137, but the ports on which they were arriving on my Ubuntu machine were random. This is typical behavior when communicating via UDP, but the problem is that
the standard ufw rules for "Samba" do not account for this! (WTF?)
Here is what happens.
Let us begin without any rules:
michael@pegasus:~$ sudo ufw status numbered
Status: active
Now, let us add the standard rules for "Samba":
michael@pegasus:~$ sudo ufw allow Samba
Rule added
Rule added (v6)
michael@pegasus:~$ sudo ufw status verbose
Status: active
Logging: on (full)
Default: deny (incoming), allow (outgoing), disabled (routed)
New profiles: skip
To Action From
-- ------ ----
137,138/udp (Samba) ALLOW IN Anywhere
139,445/tcp (Samba) ALLOW IN Anywhere
137,138/udp (Samba (v6)) ALLOW IN Anywhere (v6)
139,445/tcp (Samba (v6)) ALLOW IN Anywhere (v6)
The problem is that with these rules, incoming packets from remote port 137 to random local ports get filtered. So, although the Samba server works, the Samba client does not work. Here is what I had to do in order to fix this:
michael@pegasus:~$ sudo ufw allow in proto udp from any port 137,138 to any
Rule added
Rule added (v6)
michael@pegasus:~$ sudo ufw status verbose
Status: active
Logging: on (full)
Default: deny (incoming), allow (outgoing), disabled (routed)
New profiles: skip
To Action From
-- ------ ----
137,138/udp (Samba) ALLOW IN Anywhere
139,445/tcp (Samba) ALLOW IN Anywhere
Anywhere ALLOW IN 137,138/udp
137,138/udp (Samba (v6)) ALLOW IN Anywhere (v6)
139,445/tcp (Samba (v6)) ALLOW IN Anywhere (v6)
Anywhere (v6) ALLOW IN 137,138/udp (v6)
After this, the
smbtree command started listing Windows workstations.
The final piece of the puzzle was to get a proper listing of the shares of each Windows workstation.
Unfortunately I had to do an awful lot of tweaking around in order to get this to work, and I do not remember anymore every step of the process, but I am documenting what I remember, and I will refine this when I get the chance.
The final steps that worked were the following:
- Go to Control Panel -> Network and Sharing Center -> Change Advanced Sharing Settings -> All Networks -> Password protected sharing and:
- Select "Turn off password protected sharing"
- In the Group Policy Editor (gpedit.msc) Go to Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> Security Options and modify the following:
- Enable "Network access: Let Everone permissions apply to anonymous users"
- And of course make sure the firewall allows samba packets to go through.
Of course the above were probably not the only things required to make it work. While troubleshooting, I also did several other things which, although they did not have any immediately visible result, may have contributed to the success of the configuration as a whole. Those included the following:
In an elevated command prompt, execute:
- net user guest /active:yes to enable the guest account.
- net user guest "" to make sure that the guest account has a blank password.
Go to Windows Explorer -> This PC ("My Computer") -> Uninstall or Change a program -> Turn Windows features on or off
- Make sure "SMB 1.0/CIFS File Sharing Support" is checked.
Here is a relevant discussion for reference:
https://unix.stackexchange.com/q/453944/141190
