Browsing Across Subnets in Samba

This information was taken partly from the BROWSING.txt file and partly from actual experience. It is only possible for Windows clients to browse across subnets if you set up a WINS server. This will be where all the little Windows computers, trapped in the cycle of rebooting and samsara, go to seek parameter enlightenment and name resolution. If Windows users experience long (> 30 sec) initial delays, it often means the name resolution is not working properly. NT machines seem to have particular difficulty dealing with the absence of a WINS server.

As an aside, make sure your computer never runs Samba in a network on which you are not the administrator. Running Samba is a good way to screw up someone else's NT-based network.

1. Before starting, run 'smbstatus' and 'testparm' on each Samba server to make sure there are no obvious problems with the configuration such as an incorrect IP address.

2. Designate one Samba server on the network as the WINS server. There must only be one WINS server.

3. Ensure that each of the subnets contains a local master browser for the workgroup. Do not do this for more than one Samba server on each subnet, or they will fight over which is the local master browser. Set encrypted passwords unless you have Windows 3.11 clients around. Keep the OS level above 32 to prevent users' NT machines from taking over. Here are the relevant sections of the magic /etc/smb.conf files with the appropriate incantations:

Subnet 1 - WINS server and local master (IP address = 111.111.111.3). 
   netbios name = BUDDHA
   security = share
   encrypt passwords = yes
   domain logons = no
   domain master = yes
   preferred master = yes 
   local master = yes
   wins support = yes
   wins proxy = yes
   ; Don't set wins server if wins support is activated
   ; wins server is commented out, because it is this machine.
   ; Make its OS level the highest
   os level = 51
Subnet 1 - all others 
   netbios name = DISCIPLE
   security = share
   encrypt passwords = yes
   domain logons = yes
   domain master = no
   preferred master = no
   local master = no
   wins support = no
   wins proxy = no
   ; Don't set wins server if wins support is activated
   ; Wins server is buddha
   wins server = 111.111.111.3   
   os level = 22
Subnet 2 - local master 
   netbios name = BODHISATTVA
   security = share
   encrypt passwords = yes
   domain logons = no
   domain master = no
   preferred master = yes
   local master = yes
   wins support =no
   wins proxy = no
   ; wins server is buddha
   wins server = 111.111.111.3
   os level = 33
Subnet 2 - all others 
   netbios name = GRASSHOPPER
   security = share
   encrypt passwords = yes
   domain logons = yes
   domain master = no
   preferred master = no
   local master = no
   wins support =no
   wins proxy = no
   ; wins server is buddha
   wins server = 111.111.111.3
   os level = 22

3. Make sure the 'interface' and 'remote announce' settings are correct.
Suppose we have the following subnets: 
   Subnet mask       
     255.255.255.0
   Subnet 1
     111.111.111.3    = WINS server and local master
     111.111.111.255  = broadcast address
   Subnet 2
     222.222.222.4    = local master
     222.222.222.255  = broadcast address
We would have on the WINS server (IP address = 111.111.111.3): 
   interfaces = 222.222.222.255/255.255.255.0  111.111.111.255/255.255.255.0\
        111.111.111.3/255.255.255.0    
   remote announce = 222.222.222.255/WORKGROUP  111.111.111.255/WORKGROUP\
        111.111.111.3/WORKGROUP 
   remote browse sync = 111.111.111.255  222.222.222.255
Note that you might as well name your workgroup "Workgroup" because you will end up with one with that name eventually anyway as users reinstall Windows.

4. Set the DHCP server's dhcpd.conf to point to the WINS server. This will give all DHCP clients the address of the WINS server. Otherwise, somebody would have to go to every Windows machine and set the WINS server in their control panel. One guess as to who that somebody might be. Stop and restart the DHCP server so the WINS server setting takes effect. 
option netbios-name-servers 111.111.111.3;

5. Also, it is sometimes tricky to get the server to show up in the browse list. We use the following: 
   public = yes
   browseable = yes
   lm announce = yes
   browse list = yes
   auto services = yes

If server is not visible in Network Neighborhood browsing

One of the mysterious things that happens with samba is that servers sometimes disappear from the browse list for no apparent reason. Windows clients can still access the server by typing "\\111.222.333.44" or even "\\myservername" in the address box (proving that WINS is still working), but the little icon for the server in Network Neighborhood is missing. Another symptom is that nmblookup also doesn't work: 

nmblookup syphilis
querying syphilis on 63.127.146.255
name_query failed to find name syphilis

Here is a checklist of some things that may cause this.

  1. Make sure both smbd and nmbd are running on both the "invisible" server and the server acting as a master browser, and that both are using their correct smb.conf file. If they are, restart them. The master browse list may have somehow gotten corrupted. This can occur, for example, if a server's system load is too high to prevent it from responding fast enough when a polling occurs. Restarting nmbd and smbd on the master browser should fix the problem.
  2. Incorrect `interfaces' or 'workgroup' settings in smb.conf
  3. 'Remote announce' not correct in smb.conf. Put the server first, then each network. For example: 
    interfaces = 63.127.146.195/255.255.255.192 \
       65.198.102.127/255.255.255.192 \
       63.127.146.255/255.255.255.192
    These numbers are the host IP/netmask of the invisible server followed by the broadcast addresses/netmasks of the two networks that have Windows machines.
  4. Make sure the browse list and browsability options are set in smb.conf: 
    [global] 
   ... (other parameters) ...
   public = yes
   browseable = yes
   lm announce = yes
   browse list = yes
   auto services = yes
   remote browse sync = 63.127.146.255  65.198.102.127
[homes]
   comment = Home Directories
   writeable = yes
   browseable = yes
   guest ok = no
   public = no
   read only = no
   create mode = 0777
    For "remote browse sync", we put the broadcast addresses of the two networks that have Windows machines, separated by a space. Note that you may spell browsable either with or without the extra 'e'.
  5. For Windows XP, you also sometimes need the following in order to connect. 
    ; Extra stuff for XP
  mangle case = yes
  revalidate = yes
  force user = ftp
  use client driver = yes
  6. Try raising the OS level in the invisible server to some value higher than 32.
  7. Check the browse list on the master server (/var/lib/samba/browse.dat).
  8. Other tools:
    nmblookup WORKGROUP = prints a list of Netbios names.
    smbclient -L servername = lists the master browser and all shares on the specified server.

After fixing the smb.conf file, restart samba, then go to lunch. The changes will not appear instantly on Windows clients. Sometimes Clicking on "Computers near me" on the Windows client with the network cable unplugged induces it to recheck the network, and it will find the server when the cable is plugged in. Usually, however, all you can do is wait.

If users can't log into their home directory

  1. Make sure they log onto their Windows machine using the same login name as they use for their Unix account. The password need not be the same. Unfortunately, there is no easy way to specify a username when connecting to another computer in Windows 98, so if you have a shared computer (e.g., attached to a common-use scanner) the users will have to create shared folders on their personal computers in order to store their files. This may seem awkward to Unix users, but it does have a certain weird Redmondian logic, because it avoids the security risks of typing your password on a shared computer (although it adds other risks). Windows 2000 does allow users to specify a different username, but this feature seems not to always work.
  2. Check to make sure 
       writeable = yes
   browseable = yes
   guest ok = no
   public = no
   read only = no
    is present in the "[homes]" section in /etc/smb.conf. If "guest ok" access is permitted, Windows will preferentially connect as the user specified in the global "guest account" option (typically 'ftp'). This causes users to be blocked from accessing their home directories (unless, of course, your permissions are set incorrectly).

At this point, browser samadhi should be attainable for Windows users on all subnets. Be conservative about making /tmp available to Windows users. They will assume it is the place where they are supposed to put their backups and will happily fill it with nimda eml files, mp3s and other gems.

Note that "smbclient -L BUDDHA" will show BUDDHA as the master browser on subnet 1 while "smbclient -L BODHISATTVA" will show BODHISATTVA as the master browser on subnet 2. This is normal, and occurs because Windows browsing packets cannot actually cross subnets. The WINS server and "browse sync" commands bypass this limitation. Don't laugh - this is a good security feature. Imagine what would happen if anyone could browse any Windows Network Neighborhood anywhere in the world ....

Common Samba commands

This information has been moved here.

Samba authentication problems

This information has been moved here.

Back