Why can I see my samba shares from CentOS 7 but not Fedora 30?

Question

I'm experiencing problems configuring samba on my Fedora machines. Everything has always worked great on CentOS but identical configurations are having problems with Fedora.

I have three computers on the same network, lets call them: A, M, and L. All computers have identical [global] entries in their smb.conf.

'A' is running CentOS 7, has no problems, and can see all hosts and shares for A, M, and L according to smbtree.

Both 'M' and 'L' are running Fedora 30 but cannot resolve any NETBIOS names (I can't ping the other machines by hostname), and see nothing on smbtree, not even its own shares.

Interestingly, there is also a Windows machine on the network. Lets call this machine 'W'. All of the Linux systems can resolve this machine by its hostname and ping it. The problem is with the Linux machines talking with each other.

smb.conf (all machines):

[global]
    workgroup = WORKGROUP
    security = user

    passdb backend = tdbsam

    printing = cups
    printcap name = cups
    load printers = yes
    cups options = raw

    hosts allow = 127. 10.0.1.
    ntlm auth = yes

Firewall open services (all machines):

samba ntp dhcpv6-client ssh samba-client

Note that the Fedora machines also allow the mdns through the firewall.

That's it. It should be simple but it's not working. What's going on?

Answer 1

I've finally managed to nail this down but I don't yet understand exactly why some of these changes need to be made.

CentOS 7 always "just works" as a result of its older code base. All of the problems are result of changes which have been made since the original packages available to CentOS. This further leads credibility to the notion that these server-class OSs and their adherence to older and known-stable packages.

---

NetBIOS Name Resolution

The problem with NetBIOS name resolution failing is a result of a feature of firewalld called "automatic helpers". A 2017-02-26 patch in kernel 4.9.13 changed the default behavior of the firewall service. While the result of firewall-cmd --get-automatic-helpers has always been system, the actual value is defined in the kernel and this is what changed.

To force the old behavior, this feature must be enabled explicitly:

firewall-cmd --set-automatic-helpers=yes

Restart smb and NetBIOS names should now work with ping, nmblookup, etc. Note that this is a security vulnerability. See the section on security to read more about this. Note the default setting for your system before changing this with firewall-cmd --get-automatic-helpers.

Alternatively, you can try disabling the firewall service temporarily to see if it has any bearing at all.

---

Share Visibility

Great! Now shares work, right? Well, maybe.

Try and view your shares:

smbtree -b -N

If shares are visible then you're done. If not, this has to do with samba failing to bind with all of the available interfaces. You can view all of the interfaces with the following command:

ifconfig | grep -Po '^\w+'

Add these interfaces to /etc/samba/smb.conf; in my case:

interfaces = lo virbr0 wlo1
bind interfaces only = yes

I had initially setup Samba to only allow connections through IP prefixes 127. and 10.0.1. But when viewing the smb log I noticed this message:

Denied connection from 192.168.122.1 (192.168.122.1)

This was a blocked connection from a local virtual machine that was assigned a 192.168. address via NAT (virbr0). After adding this prefix to my configuration, I could now see shares for this machine but not my 10.0.1 network. I then guessed that maybe Samba wasn't binding to this interface (wlo1). I added it to my smb.conf and suddenly everything worked. I could browse shares and access network devices.

The wlo1 interface is the wireless card and I don't know why it isn't being bound. I had the same NetBIOS problem on another machine on the network which is connected over ethernet and I didn't have to specify any interfaces. This is why I said that your shares might already be visible without having to make this change.

---

Notes on Security

According to the Linux Kernel Mailing list, the issue of NetBIOS resolution failing is a direct result of the change with regards to the firewalld's "automatic helper" feature:

Commit 3bb398d925 ("netfilter: nf_ct_helper: disable automatic helper assignment") is causing behavior regressions in firewalls, as traffic handled by conntrack helpers is now by default not passed through even though it was before due to missing CT targets (which were not necessary before this commit).

The change was made due to security reasons:

The default had to be switched off due to security reasons and therefore should stay the way it is, but let's be friendly to firewall admins and issue a warning the first time we're in situation where packet would be likely passed through with the old default but we're likely going to drop it on the floor now.

See:

• https://cansecwest.com/csw12/conntrack-attack.pdf
• https://home.regit.org/netfilter-en/secure-use-of-helpers/

The Arch Linux documentation also provides a good summary:

And you are using a firewall (iptables) because you do not trust your local (school, university, hotel) network. This may be due to the following: When the smbclient is browsing the local network it sends out a broadcast request on udp port 137. The servers on the network then reply to your client but as the source address of this reply is different from the destination address iptables saw when sending the request for the listing out, iptables will not recognize the reply as being "ESTABLISHED" or "RELATED", and hence the packet is dropped.

And cites a possible solution by adding an explicit helper through iptables instead of the overly broad automatic helpers:

iptables -t raw -A OUTPUT -p udp -m udp --dport 137 -j CT --helper netbios-ns

---

Additional reading:

https://bugzilla.redhat.com/show_bug.cgi?id=1297235