SuSE 10.3 and NAS - solved

As a non-guru it was not obvious to me that the reason that I couldn’t see the samba shares on my synology NAS was that they were blocked by the firewall, rather than that samba wasn’t running on my SuSE 10.3.
Though the GUI did suggest that when I clicked on the icon in Network folders…doh!
Lots of deep info here from people like Swerdna on how to really make your network rock, but I didn’t want to change anything out in the network and didn’t want to install samba server or enable xinetd. This site N.E.R.D.: Getting Samba to work properly with SuSE’s Firewall…
gives the settings needed to punch the necessary holes in the firewall. There is also a site at tweakhound.com/linux/samba/page_1.htm which gives more things to do if you want to make your network work with Windows.
So what I did was to go YaST->System->/etc/sysconfig editor
scrolled down to
FW_SERVICES_EXT_TCP and enter microsoft-ds netbios-dgm netbios-ns netbios-ssn
Then to FW_SERVICES_EXT_UDP and enter netbios-ns
Then in the box for FW_ALLOW_INCOMING_HIGHPORTS_TCP microsoft-ds netbios-ns was entered
and the same entries made for FW_ALLOW_INCOMING_HIGHPORTS_UDP
Finally the entries netbios-ns netbios-dgm were put in at FW_ALLOW_FW_BROADCAST_EXT
Click on Finish

I see that the firewall entries for SuSE 11.0 are slightly different.
Any comments regarding whether this is an elegant or bad solution welcomed

It is a solution but not an elegant one. What makes it non-elegant is that more than the requisite ports are opened. What makes it correct is that the slew of opened ports contains the requisite ports.
The correct ports for 10.3 are:
FW_SERVICES_EXT_TCP: 135, 139 and 445
(or use the confusing synonyms: microsoft-ds is a synonym for 445 and netbios-ssn is a synonym for 139)
FW_SERVICES_EXT_UDP: 137, 138
(or use the confusing synonyms: netbios-dgm is a synonym for 138 and netbios-ns is a synonym for 137)
FW_ALLOW_FW_BROADCAST_EXT: 137, 138 (or the synonyms as above)
FW_TRUSTED_NETS: Often it helps to define a trusted network formed from your IP range from the LAN, in the style of e.g. 192.168.5.0/24 and make an entry like this:
FW_TRUSTED_NETS=“192.168.5.0/24”

Regarding 11.0: there’s a new line in the config file for SuSEfirewall2 that shuts off replies to broadcasts. The default is:
FW_SERVICES_ACCEPT_RELATED_EXT=“”
The correct entry for Samba is like this:
FW_SERVICES_ACCEPT_RELATED_EXT=“192.168.3.0/24,udp,137”
You must of course adapt “192.168.3.0” to your LAN’s IP range.
You set it in Yast –> Security and users –> Firewall –> Broadcast –> Accept the broadcast reply –> Add:
1: leave zone=external
2: leave service=Samba Browsing
3: change Network=0/0 to your trusted network (e.g. like 192.168.3.0/24)

What you did works for you and I’m glad. But I mention all the above simply to steer other users away from the link you gave, in an attempt to prevent the info in it from becoming more widely used.

Thanks Swerdna, I did it right now and it works fine. I did think that the “highports” bit was a typical security compromise and the trusted nets bit sounds like a good idea too.

Hi
I use an ADS Tech NAS, and have never had to open any firewall ports to
access the samba features. SLED, 10.3, 11.0 and others.


Cheers Malcolm °¿° (Linux Counter #276890)
openSUSE 11.0 x86 Kernel 2.6.25.11-0.1-default
up 2 days 6:24, 3 users, load average: 0.23, 0.16, 0.14
GPU GeForce 6600 TE/6200 TE - Driver Version: 173.14.12

quote
<<have never had to open any firewall ports to
access the samba features. SLED, 10.3, 11.0 and others.>>

Well I do not understand that, but then I don’t really understand most of this… perhaps SAMBA used a smaller range of ports before CIFS (presumably your NAS runs an oler version)? When I couldn’t mount the share I searched the forum here and only found this posting:-
Mount Ftp ‘share’ - openSUSE Forums

So I knew I was not alone, but had no answers (made do with ftp from the cli to start). But maybe this is not a common problem after all?

The Samba ports don’t change over time. They’re dictated by Samba devs, not by the Suse devs.
Chapter 18. Securing Samba