9.7 Technical Overview of Browsing

SMB networking provides a mechanism by which clients can access a list of machines in a network, a so-called browse list . This list contains machines that are ready to offer file and/or print services to other machines within the network. Thus it does not include machines that aren't currently able to do server tasks . The browse list is heavily used by all SMB clients. Configuration of SMB browsing has been problematic for some Samba users, hence this document.

MS Windows 2000 and later versions, as with Samba-3 and later versions, can be configured to not use NetBIOS over TCP/IP. When configured this way, it is imperative that name resolution (using DNS/LDAP/ADS) be correctly configured and operative . Browsing will not work if name resolution from SMB machine names to IP addresses does not function correctly.

Where NetBIOS over TCP/IP is enabled, use of a WINS server is highly recommended to aid the resolution of NetBIOS (SMB) names to IP addresses. WINS allows remote segment clients to obtain NetBIOS name_type information that cannot be provided by any other means of name resolution.

9.7.1 Browsing Support in Samba

Samba facilitates browsing. The browsing is supported by nmbd and is also controlled by options in the smb.conf file. Samba can act as a local browse master for a workgroup and the ability to support domain logons and scripts is now available.

Samba can also act as a Domain Master Browser for a workgroup. This means that it will collate lists from Local Master Browsers into a wide area network server list. In order for browse clients to resolve the names they may find in this list, it is recommended that both Samba and your clients use a WINS server.

Do not set Samba to be the Domain Master for a workgroup that has the same name as an NT Domain. On each wide area network, you must only ever have one Domain Master Browser per workgroup, regardless of whether it is NT, Samba or any other type of domain master that is providing this service.

N OTE

nmbd can be configured as a WINS server, but it is not necessary to specifically use Samba as your WINS server. MS Windows NT4, Server or Advanced Server 200x can be configured as your WINS server. In a mixed NT/200x server and Samba environment on a Wide Area Network, it is recommended that you use the Microsoft WINS server capabilities. In a Samba-only environment, it is recommended that you use one and only one Samba server as the WINS server.

To get browsing to work you need to run nmbd as usual, but will need to use the workgroup option in smb.conf to control what workgroup Samba becomes a part of.

Samba also has a useful option for a Samba server to offer itself for browsing on another subnet. It is recommended that this option is only used for " unusual " purposes: announcements over the Internet, for example. See remote announce in the smb.conf man page.

9.7.2 Problem Resolution

If something does not work, the log.nmbd file will help to track down the problem. Try a log level of 2 or 3 for finding problems. Also note that the current browse list usually gets stored in text form in a file called browse.dat .

If it does not work, you should still be able to type the server name as \\SERVER in filemanager , then press enter and filemanager should display the list of available shares.

Some people find browsing fails because they do not have the global guest account set to a valid account. Remember that the IPC$ connection that lists the shares is done as guest and, thus, you must have a valid guest account.

MS Windows 2000 and later (as with Samba) can be configured to disallow anonymous (i.e., guest account) access to the IPC$ share. In that case, the MS Windows 2000/XP/2003 machine acting as an SMB/CIFS client will use the name of the currently logged-in user to query the IPC$ share. MS Windows 9x/Me clients are not able to do this and thus will not be able to browse server resources.

The other big problem people have is that their broadcast address, netmask or IP address is wrong (specified with the interfaces option in smb.conf )

9.7.3 Cross-Subnet Browsing

Since the release of Samba 1.9.17 (alpha1), Samba has supported the replication of browse lists across subnet boundaries. This section describes how to set this feature up in different settings.

To see browse lists that span TCP/IP subnets (i.e., networks separated by routers that do not pass broadcast traffic), you must set up at least one WINS server. The WINS server acts as a DNS for NetBIOS names. This will allow NetBIOS name-to-IP address translation to be completed by a direct query of the WINS server. This is done via a directed UDP packet on port 137 to the WINS server machine. The WINS server avoids the necessity of default NetBIOS name-to-IP address translation, which is done using UDP broadcasts from the querying machine. This means that machines on one subnet will not be able to resolve the names of machines on another subnet without using a WINS server.

Remember, for browsing across subnets to work correctly, all machines, be they Windows 95, Windows NT or Samba servers, must have the IP address of a WINS server given to them by a DHCP server, or by manual configuration (for Windows 9x/Me and Windows NT/200x/XP, this is in the TCP/IP Properties, under Network settings); for Samba, this is in the smb.conf file.

9.7.3.1 Behavior of Cross-Subnet Browsing

Cross-subnet Browsing is a complicated dance , containing multiple moving parts . It has taken Microsoft several years to get the code that achieves this correct, and Samba lags behind in some areas. Samba is capable of cross-subnet browsing when configured correctly.

Consider a network set up as Figure 9.1.

Figure 9.1. Cross-Subnet Browsing Example.

This consists of 3 subnets (1, 2, 3) connected by two routers (R1, R2) which do not pass broadcasts. Subnet 1 has five machines on it, subnet 2 has four machines, subnet 3 has four machines. Assume for the moment that all machines are configured to be in the same workgroup (for simplicity's sake). Machine N1_C on subnet 1 is configured as Domain Master Browser (i.e., it will collate the browse lists for the workgroup). Machine N2_D is configured as WINS server and all the other machines are configured to register their NetBIOS names with it.

As these machines are booted up, elections for master browsers will take place on each of the three subnets. Assume that machine N1_C wins on subnet 1, N2_B wins on subnet 2, and N3_D wins on subnet 3. These machines are known as Local Master Browsers for their particular subnet. N1_C has an advantage in winning as the Local Master Browser on subnet 1 as it is set up as Domain Master Browser.

On each of the three networks, machines that are configured to offer sharing services will broadcast that they are offering these services. The Local Master Browser on each subnet will receive these broadcasts and keep a record of the fact that the machine is offering a service. This list of records is the basis of the browse list. For this case, assume that all the machines are configured to offer services, so all machines will be on the browse list.

For each network, the Local Master Browser on that network is considered " authoritative " for all the names it receives via local broadcast. This is because a machine seen by the Local Master Browser via a local broadcast must be on the same network as the Local Master Browser and thus is a " trusted " and " verifiable " resource. Machines on other networks that the Local Master Browsers learn about when collating their browse lists have not been directly seen. These records are called " non-authoritative ."

At this point the browse lists appear as shown in Table 9.1 (these are the machines you would see in your network neighborhood if you looked in it on a particular network right now).

Table 9.1. Browse Subnet Example 1

Subnet	Browse Master	List
Subnet1	N1_C	N1_A, N1_B, N1_C, N1_D, N1_E
Subnet2	N2_B	N2_A, N2_B, N2_C, N2_D
Subnet3	N3_D	N3_A, N3_B, N3_C, N3_D

At this point all the subnets are separate, and no machine is seen across any of the subnets.

Now examine subnet 2. As soon as N2_B has become the Local Master Browser it looks for a Domain Master Browser with which to synchronize its browse list. It does this by querying the WINS server (N2_D) for the IP address associated with the NetBIOS name WORKGROUP<1B>. This name was registered by the Domain Master Browser (N1_C) with the WINS server as soon as it was started.

Once N2_B knows the address of the Domain Master Browser, it tells it that is the Local Master Browser for subnet 2 by sending a MasterAnnouncement packet as a UDP port 138 packet. It then synchronizes with it by doing a NetServerEnum2 call. This tells the Domain Master Browser to send it all the server names it knows about. Once the Domain Master Browser receives the MasterAnnouncement packet, it schedules a synchronization request to the sender of that packet. After both synchronizations are complete the browse lists look as shown in Table 9.2:

Table 9.2. Browse Subnet Example 2

Subnet	Browse Master	List
Subnet1	N1_C	N1_A, N1_B, N1_C, N1_D, N1_E, N2_A(*), N2_B(*), N2_C(*), N2_D(*)
Subnet2	N2_B	N2_A, N2_B, N2_C, N2_D, N1_A(*), N1_B(*), N1_C(*), N1_D(*), N1_E(*)
Subnet3	N3_D	N3_A, N3_B, N3_C, N3_D

Servers with an (*) after them are non-authoritative names.

At this point users looking in their network neighborhood on subnets 1 or 2 will see all the servers on both, users on subnet 3 will still only see the servers on their own subnet.

The same sequence of events that occurred for N2_B now occurs for the Local Master Browser on subnet 3 (N3_D). When it synchronizes browse lists with the Domain Master Browser (N1_A) it gets both the server entries on subnet 1, and those on subnet 2. After N3_D has synchronized with N1_C and vica versa, the browse lists will appear as shown in Table 9.3.

Servers with an (*) after them are non-authoritative names.

At this point, users looking in their network neighborhood on subnets 1 or 3 will see all the servers on all subnets, while users on subnet 2 will still only see the servers on subnets 1 and 2, but not 3.

Finally, the Local Master Browser for subnet 2 (N2_B) will sync again with the Domain Master Browser (N1_C) and will receive the missing server entries. Finally, as when a steady state (if no machines are removed or shut off) has been achieved, the browse lists will appear as shown in Table 9.4.

Table 9.3. Browse Subnet Example 3

Subnet	Browse Master	List
Subnet1	N1_C	N1_A, N1_B, N1_C, N1_D, N1_E, N2_A(*), N2_B(*), N2_C(*), N2_D(*), N3_A(*), N3_B(*), N3_C(*), N3_D(*)
Subnet2	N2_B	N2_A, N2_B, N2_C, N2_D, N1_A(*), N1_B(*), N1_C(*), N1_D(*), N1_E(*)
Subnet3	N3_D	N3_A, N3_B, N3_C, N3_D, N1_A(*), N1_B(*), N1_C(*), N1_D(*), N1_E(*), N2_A(*), N2_B(*), N2_C(*), N2_D(*)

Table 9.4. Browse Subnet Example 4

Subnet	Browse Master	List
Subnet1	N1_C	N1_A, N1_B, N1_C, N1_D, N1_E, N2_A(*), N2_B(*), N2_C(*), N2_D(*), N3_A(*), N3_B(*), N3_C(*), N3_D(*)
Subnet2	N2_B	N2_A, N2_B, N2_C, N2_D, N1_A(*), N1_B(*), N1_C(*), N1_D(*), N1_E(*), N3_A(*), N3_B(*), N3_C(*), N3_D(*)
Subnet3	N3_D	N3_A, N3_B, N3_C, N3_D, N1_A(*), N1_B(*), N1_C(*), N1_D(*), N1_E(*), N2_A(*), N2_B(*), N2_C(*), N2_D(*)

Servers with an (*) after them are non-authoritative names.

Synchronizations between the Domain Master Browser and Local Master Browsers will continue to occur, but this should remain a steady state operation.

If either router R1 or R2 fails, the following will occur:

1. Names of computers on each side of the inaccessible network fragments will be maintained for as long as 36 minutes in the network neighborhood lists.

2. Attempts to connect to these inaccessible computers will fail, but the names will not be removed from the network neighborhood lists.

3. If one of the fragments is cut off from the WINS server, it will only be able to access servers on its local subnet using subnet-isolated broadcast NetBIOS name resolution. The effects are similar to that of losing access to a DNS server.