Red Hat Bugzilla – Bug 38102
Samba nmblookup fails using default installation
Last modified: 2007-04-18 12:32:53 EDT
From Bugzilla Helper: User-Agent: Mozilla/4.73 [en] (WinNT; U) After performing an installation on a clean system, performing nmblookup on the current server name fails after starting nmb and smb services. This causes connection failures from remote systems attempting to access shares. I have used a working smb.conf file from Redhat 7.0 system on the Redhat 7.1 and the problem did not go away. Note: Samba is working, I can use the shares etc, but I cannot find the box using nmb. Reproducible: Always Steps to Reproduce: 1. Start Samba using default installation (verify with smbclient -L <hostname>) 2. Run 'nmblookup <hostname>' Actual Results: smbclient -L <hostname> ( on local box succeeds) smbclient -L <hostname> ( from remote box fails: SSL: Error error setting CA cert locations: error:00000000::lib(0) :func(0) :reason(0) trying default locations. added interface ip=172.16.6.0 bcast=172.16.7.255 nmask=255.255.248.0 error connecting to 172.16.5.97:139 (Connection refused) Connection to bpedre-lnx failed Expected Results: Should have connected and listed shares normally on smbclient call. Should have shown the IP address when nmblookup broadcast is used. This is a testing system. I have a ghost image of the system that can be restored on /dev/hda2 at need to reproduce the machine state exactly. Unusual circumstances: Machine was changed from static to dhcp IP address. Ethernet boot options were altered to allow 100Mb connectivity.
Do you have a firewall configured?
If the firewall is installed by default on the Redhat7.1 system, then yes. Otherwise no. The machines in question are on the same network segment.
There is firewall configuration in the installer, yes... What does 'ipchains -L input' say?
Here is the output.. I don't seen anything set to reject the samba ports though. Chain input (policy ACCEPT): target prot opt source destination ports ACCEPT udp ------ ausdhcp.aus.pervasive.com anywhere domain -> any ACCEPT all ------ anywhere anywhere n/a REJECT tcp -y---- anywhere anywhere any -> 0:1023 REJECT tcp -y---- anywhere anywhere any -> nfs REJECT udp ------ anywhere anywhere any -> 0:1023 REJECT udp ------ anywhere anywhere any -> nfs REJECT tcp -y---- anywhere anywhere any -> x11:6009 REJECT tcp -y---- anywhere anywhere any -> xfs
It's rejecting TCP connections on ports < 1023 (and UDP also); that certainly will do it.
Sorry, my brain was nonfunctional during the previous reply. Yes, it's obvious that tcp and udp where blocked on the ports I needed. I'm still not sure where during the installation I was prompted to include the default firewall setup. It might be neccessary to add code to the samba start script to check for access to the required ports and inform the user when this will be a problem. To solve my problem I simply edited /etc/sysconfig/ipchains manually to remove the reject rules. A better solution would have denied access outside the local network, but I was just trying for quick confirmation. Thank you for the help. Does the need for samba script check count as a separate bug that will need to be opened? Otherwise this one should now be closed.
I don't know that we can change the init script in that manner, as it's non-trivial to deduce from the firewall rules whether or not it's blocked intentionally; for example, that output doesn't say anything about the interfaces things are or aren't blocked on.
A good point. The problem is when the firewall rules are included, a user needs to poke holes in the firewall for SMB to work. This is not evidenced in any of the configuration tools or the smb.conf file. At a minimum this conflict will need better documentation for poor ignorant souls like myself. :) Options I can see: 1. Warn during samba install if the default firewall rules were installed. Problem: could be ignored. 2. Have the samba install add ACCEPT rules for the SMB ports to the ipchains file. Problem: dangerous to secure environments 3. Add definitions of wild, NMZ, and safe network zones. Use these to determine firewall rules in the first place.
Determining "I'd like to firewall this, but not this, and of course this interface is safe" is an administrative task, not a bug.