Samba works correctly if firewalld is disabled. If firewalld is enabled and active, incoming samba connections work, but outgoing ones do not.
Leap 15’s firewall configuration is a bit different from what is described in the HOWTO. In YaST===>Security and Users===>Firewall (Configure a firewall), I set the network Device to External. I checked services samba and samba-client to be allowed. Service Netbios server seems to not exist.
The smb.conf file is
# smb.conf is the main Samba configuration file. You find a full commented
# version at /usr/share/doc/packages/samba/examples/smb.conf.SUSE if the
# samba-doc package is installed.
[global]
netbios name = T61-oS15KDE
workgroup = CANDH
server string = ""
name resolve order = bcast host lmhosts wins
local master = yes
preferred master = auto
os level = 65
passdb backend = tdbsam
printing = cups
printcap name = cups
printcap cache time = 750
cups options = raw
map to guest = Bad User
include = /etc/samba/dhcp.conf
# logon path = \\%L\profiles\.msprofile
# logon home = \\%L\%U\.9xprofile
# logon drive = P:
usershare allow guests = No
ldap admin dn =
wins server =
wins support = No
[homes]
comment = Home Directories
valid users = %S, %D%w%S
browseable = No
read only = No
inherit acls = Yes
[profiles]
comment = Network Profiles Service
path = %H
read only = No
store dos attributes = Yes
create mask = 0600
directory mask = 0700
[users]
comment = All users
path = /home
read only = No
inherit acls = Yes
veto files = /aquota.user/groups/shares/
[groups]
comment = All groups
path = /home/groups
read only = No
inherit acls = Yes
[printers]
comment = All Printers
path = /var/tmp
printable = Yes
create mask = 0600
browseable = No
[print$]
comment = Printer Drivers
path = /var/lib/samba/drivers
write list = @ntadmin root
force group = ntadmin
create mask = 0664
directory mask = 0775
What do I need to set to get samba out through the firewall?
Do you mean that you’re using this machine as a samba server and that remote hosts cannot reach it?
Please show us explicitly how your firewall is configured.
sudo firewall-cmd --zone=public --list-all
Service Netbios server seems to not exist.
Do you mean that your machine is not discoverable as you’d assumed? You should know that NetBIOS network discovery relied on the use of the NT1 (SMB1) protocol. It has well-known security implications so now disabled by default. (However, it can still be enabled if desired.) None of this should stop samba connectivity from working though, assuming client and server can work with SMB2 and SMB3 protocols.
There are several Linux and Win10 machines on the home network. None are set as a samba server that I know of.
Another Linux machine can reach this one with the firewall on, but the reverse connection fails unless the firewall is off. With the firewall on, in Dolphin Network===>Samba Shares returns
Unable to find any workgroups in your local network. This might be caused by an enabled firewall.
howard@linux-unj6:~> sudo firewall-cmd --zone=public --list-all
[sudo] password for root:
public (active)
target: default
icmp-block-inversion: no
interfaces: tun0
sources:
services: dhcpv6-client samba samba-client
ports:
protocols:
masquerade: no
forward-ports:
source-ports:
icmp-blocks:
rich rules:
howard@linux-unj6:~>
This is when using wired ethernet and VPN.
I mentioned NetBIOS only because it was mentioned in the HOWTO.
Ok, that is as expected. It is the NetBIOS discovery that has been inhibited as I mentioned before, but that shouldn’t stop you reaching the shares using something like ‘smb://<netbios_name>’ , and of course you can always save the share(s) to ‘Places’ in Dolphin.
You can still use the CLI utility as a discovery tool though…
Just noticed this comment. Can you explain a bit more about your network setup? Can you ping your other samba hosts successfully when the VPN is active?
I haven’t tested or encountered your problem,
But IMO there is a fair chance that if you configured your interface in the home, internal or trusted zones you shouldn’t have any problems.
The External (and public) zones are when you are facing a an unprotected network with threats, and I assume your samba is safely within your LAN protected by a firewall running elsewhere.
Incoming ADSL line to modem to router with wired and wireless connections. Connections are wired to Win10 only machine, wired to dual-boot Win10 and Linux Mint 18.2 KDE, several usually wireless laptops dual-boot Win10 and at the moment Mint, and this laptop dual-boot Win10 and openSUSE Leap 15 KDE, now wired because wi-fi is working on only with Win10 (there will be another thread on that). All normally run VPN.
With VPN active on all, I can successfully ping both the wired Win10 machine and the wired Mint 18.2 machine.
Yes, machines are within LAN. Switching the interface device on this to home zone in the firewall made no difference. Turning off the firewall is the only way for samba to go out.
Howard
Yes, that won’t make a difference if you’ve allowed the requisite services (as your previous output showed). I can’t replicate your issue even with the firewall active (zone public or otherwise). I have no problem resolving netbios names.
Hi Howard. I stand corrected. After thinking this through further, I realised my router’s DNS server function was helping with the name resolution. When I killed DNS on my openSUSE host (by removing /etc/resolv.conf), I then rely only on NetBIOS name resolution, I could no longer ping by name.
I can confirm the same behaviour as you get reflected by attempted lookups…
“Browsing” network fails with “Failed to retrieve share list from server” 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. A possible solution is to add:
iptables -t raw -A OUTPUT -p udp -m udp --dport 137 -j CT --helper netbios-ns
The issue described in this thread was also the subject of this Red Hat bug report. Comment #c26](https://bugzilla.redhat.com/show_bug.cgi?id=1297235#c26) onwards discusses the idea of opening source port 137, but discouraged in favour of connection tracking helpers (as the suggested iptables rule does)…
To allow the source port for samba is a work around that opens a big hole in the firewall.
Because of a kernel change it is needed since kernel 4.7 to use the netfilter conntrack helpers in a different way than before. This also applies to the netbios-ns helper that is used for samba. The support for the now required handling of conntrack helpers has been introduced with firewalld version 0.4.4, but there has been an issue with SELinux as firewalld needs to be able to search for kernel modules and to analyse them.
Ok, I’ve found some useful info in ‘man firewall-cmd’
Automatic Helpers Options
--get-automatic-helpers
Print the automatic helpers setting.
--set-automatic-helpers=value
For the secure use of iptables and connection tracking helpers it is recommended to turn AutomaticHelpers off. But this might have side effects on other
services using the netfilter helpers as the sysctl setting in /proc/sys/net/netfilter/nf_conntrack_helper will be changed. With the system setting, the
default value set in the kernel or with sysctl will be used. Possible values are: yes, no and system. The default value is system.
This is a runtime and permanent change and will also reload the firewall to be able to make the helpers usable.
Are you sure you followed all steps required when modifying firewalld?
And, for such a drastic change as changing zones, I’d even suspect that a reboot would be recommended if not required.
I’d also recommend trying the other 2 zones I suggested as well although I’d be surprised that the “home” zone wasn’t sufficient.
Outstanding. I had just found the Archwiki reference you mention above, but you went much further.
I made the change with the ‘firewalld-config’ utility, and Dolphin now navigates around the network correctly. I put the device back in the external zone since this laptop roams and connects to networks other than my home one. No reboot needed.
Thanks for all the research and guidance on this. Very helpful. Problem solved.
