On a linux machine with the following interfaces configured:
dev address netmask broadcast
eth0 18.104.22.168 255.255.0.0 22.214.171.124
eth0:0 10.36.70.103 255.255.255.0 10.36.70.255
eth0:1 10.36.70.10 255.255.255.0 10.36.70.255
eth0:2 10.36.70.20 255.255.255.0 10.36.70.255
eth0:3 10.36.70.30 255.255.255.0 10.36.70.255
And with an smb.conf of:
workgroup = SENS
server string = File Server
netbios name = files-0
# hosts allow = 10.36.70.
encrypt passwords = yes
security = user
socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192
interfaces = 10.36.70.30/24 127.0.0.1
bind interfaces only = yes
wins support = yes
name resolve order = wins
path = /tmp
read only = no
guest ok = yes
One would expect that 10.36.70.30 would be reported for address
of files-0. In fact, "nmblookup -R -U 10.36.70.30 files-0" yeilds:
added interface ip=10.36.70.30 bcast=10.36.70.255 nmask=255.255.255.0
added interface ip=127.0.0.1 bcast=127.255.255.255 nmask=255.0.0.0
querying files-0 on 10.36.70.30
Got a positive name query response from 10.36.70.30 ( 10.36.70.30 10.36.70.20
10.36.70.10 10.36.70.103 126.96.36.199 )
Although, 10.36.70.30 is listed first, it (almost?) never gets chosen. When
one of the other addresses is used, no connection can be made because
smbd (?) is listening only on 10.36.70.30. This makes it effectively
impossible to use the Samba WINS server functionality restricted to only
one network address.
Umm, deleting /var/cache/samba/wins.dat fixed the problem. I guess
this a cache that was stale. Perhaps a mention in the documentation
Add Cc to track this bug.
I can reproduce a similar problem. If the interfaces parameter has loopback
interface (interface name (e.g. "lo" on Linux), 127.0.0.1 or 127.0.0.1/8)
and another interface, nmbd registers a strange IP address.
interfaces = 127.0.0.1/8 192.168.200.1/24
$ nmblookup -U 127.0.0.1 '*'
querying * on 127.0.0.1
originally against 3.0.0rc4
Here's why deleting the wins.dat file works in some instances:
The original smb.conf did NOT have the correct interfaces/bind interfaces only directives. SAMBA created the wins.dat file, including the entries for this server, its workgroup, etc. The directives were added but, upon restart, SAMBA did not do any sanity checks to make sure that its own entries in wins.dat were indeed correct.
This bug can be reproducable with Samba 3.0.24 on Debian unstable (Linux kernel 188.8.131.52), but not on Solaris 10.
I think this bug was fixed by:
I've confirmed with Samba 3.0.24 + the above changes.
If it seems that it has been fixed then mark it as "FIXED".