Chapter 7. Name Resolution and Browsing

Name resolution is critical to Samba's operation because names are used to find the servers that share files or printers. Browsing takes the task of finding servers to a new level of sophistication by allowing a user to delve down into a hierarchy of networks, domains, hosts, and services offered by each server.

While name resolution and browsing are not difficult to configure, some complexity is introduced by the variety of available name-resolution systems. Historically, Unix and other TCP/IP users have moved from a flat hosts file to the Domain Name System, with the Network Information System being another popular choice. Meanwhile, Microsoft has moved from a broadcasting system to a simple, LAN-only name server called WINS and ultimately to DNS.

The reason for going over that history is that all previous systems of name resolution are still in use today! Finding a host is so crucial to networking that sites want robust (if limited) name-resolution systems to fall back on in case the main system fails. Browsing is also complicated by the frequent need to show hosts in other subnets. This chapter shows you how to configure your network to handle name resolution and browsing any way you want.

Some of the differences between Unix and Microsoft networking implementations are the result of fundamental design goals. Unix networking was originally designed largely to implement a relatively formal group of systems that were assumed to be small in number, well-maintained, and highly available, that have static IP addresses, and that wouldn't physically move around from place to place. Bringing a new server online was a labor-intensive task, but it did not have to be performed frequently. In contrast, Windows networking was originally developed as a peer-to-peer collection of small personal computers on a single subnet, having no centrally or hierarchically organized structure.

SMB networking is dynamic. Computers are allowed to leave the network at any time, sometimes without warning, and also to join or rejoin the network at any time. Furthermore, any user in a Windows network can add a new shared resource to the network or remove a resource that he had previously added. The change in the network's configuration is handled automatically by the rest of the network without requiring a system administrator to take any action.

Name Resolution

TCP/IP networks identify systems by IP addresses and always associate these addresses with more human-readable text names. In Microsoft's earliest networking implementations (for MS-DOS and Windows for Workgroups), the translation of names to network addresses was carried out in a manner that was very simple, yet very inefficient. When a system on the network needed an IP address corresponding to a name, it broadcasted the name to every other system on the network and waited for the system that owned the name to respond with its IP address.

The main problem with performing name resolution using broadcast packets is poor performance of the network as a whole, including CPU time consumed by each host on the network, which has to accept every broadcast packet and decide whether to respond to it. Also, broadcast packets usually aren't forwarded by routers, limiting name resolution to the local subnet. Microsoft's solution was to add WINS (Windows Internet Name Service) support to Windows NT so that the computers on the network can perform a direct query of the WINS server instead of using broadcast packets.

Modern Windows clients use a variety of methods for translating hostnames into IP addresses. The exact method varies depending on the version of Windows the client is running, how the client is configured (i.e., whether DNS server and/or WINS server IP addresses are provided), and whether the application software is accessing the network through Microsoft's Winsock or TCP/IP API. In general, Windows uses some combination of the following methods:

Looking up the name in its cache of recently resolved names
Querying DNS servers
Using the DNS Hosts file
Querying WINS servers
Using the WINS LMHOSTS file
Performing broadcast name resolution

The first method is pretty much self-explanatory. A hostname is checked against a cache of hostnames that have been recently resolved to IP addresses. This helps to save time and network bandwidth for resolving names that are used frequently.

When a Windows system is configured with the IP address of at least one DNS server, it can use DNS to resolve fully qualified domain names, such as those for sites on the Internet. The DNS servers can be either Windows NT/2000 or Unix systems. You can learn more about DNS and DNS server configuration in the O'Reilly book DNS and BIND.

In this chapter, we focus mainly on name resolution using WINS, which is supported by Samba with the nmbd daemon.

WINS Clients and Server Interaction

There are two types of interaction between a WINS client and a server: the client keeps its own NetBIOS name [1] registered with the server and queries the server to get the IP address corresponding to the NetBIOS name of another system.

When a WINS client joins the network, it registers its NetBIOS name with the WINS server, which stores it along with the client's IP address in the WINS database. This entry is marked active. The client is then expected to renew the registration of its name periodically (typically, every four days) to inform the server that it is still using the name. This period is called the time to live, or TTL. When the client leaves the network by being shut down gracefully, it informs the server, and the server marks the client's entry in its database as released.

When a client leaves the network without telling the WINS server to release its name, the server waits until after it fails to receive the expected registration renewal from the client and then marks the entry as released.

In either case, the released name is available for use by other clients joining the network. It might persist in the released state in the WINS database, and if it is not reregistered, the entry will eventually be deleted.

More information on WINS can be found in the Microsoft white paper Windows Internet Naming Service (WINS) Architecture and Capacity Planning. It can be downloaded from the Microsoft web site at http://www.microsoft.com.

The lmhosts File

In Chapter 3 we showed you how to configure Windows systems to use the LMHOSTS file as an alternative to the WINS server for name resolution. Samba also can use an LMHOSTS file, which by default is /usr/local/samba/lib/lmhosts. Samba's lmhosts is the same format as the Windows version. A simple lmhosts file might look like this:

172.16.1.1    toltec
172.16.1.6    maya

The names on the right side of the entries are NetBIOS names, so you can assign resource types to them and add additional entries for computers:

172.16.1.1    toltec#20
172.16.1.1    metran#1b
172.16.1.6    maya#20

Here, we've made toltec the primary domain controller of the METRAN domain on the second line. This line starts with toltec's IP address, followed by the name metran and the resource type <1B>. The other lines are entries for toltec and maya as standard workstations.

If you wish to place an lmhosts file somewhere other than the default location, you will need to notify the nmbd process upon startup using the -H option, followed by the name of your lmhosts file, as follows:

# nmbd -H /etc/samba/lmhosts -D

Configuring Name Resolution for the Samba Suite

Various daemons and tools in the Samba suite need to perform name resolution. You can define the order in which the programs try each name-resolution method through the name resolve order parameter, like this:

[global]
    name resolve order = wins lmhosts hosts bcast

The string used to define the parameter can take up to four values:

lmhosts: Uses the Samba server's local lmhosts file
hosts: Uses the standard Unix name-resolution methods, which can be /etc/hosts, DNS, NIS, or a combination, depending on how the local system is configured
wins: Uses the WINS server
bcast: Uses the broadcast method

The order in which they are specified is the order in which name resolution will be attempted. In our example, Samba will attempt to use its WINS server first for name resolution, followed by the lmhosts file on the local system. Next, the hosts value tells it to use Unix name-resolution methods. The word hosts can be misleading; it covers not only the /etc/hosts file, but also the use of DNS or NIS (as configured on the Unix host). Finally, if those three do not work, it will perform a broadcast name resolution.

Setting Up Samba as a WINS Server

You can set up Samba as a WINS server by setting the wins support parameter in the configuration file, like this:

[global]
    wins support = yes

Believe it or not, that's all you need to do! The wins support option turns Samba into a WINS server. For most installations, Samba's default configuration is sufficient.

WARNING

Remember, Samba cannot communicate with Windows WINS servers. If you are using Samba as your WINS server, you must make sure not to allow any Windows systems or other Samba servers on your network to be configured as WINS servers. If you do, their WINS databases will not synchronize, resulting in inconsistent name resolution.

Configuring a DNS proxy

A Samba WINS server can check with the system's DNS server if a requested host cannot be found in its WINS database. With a typical Linux system, for example, you can find the IP address of the DNS server by searching the /etc/resolv.conf file. In it, you might see an entry such as the following:

nameserver 127.0.0.1
nameserver 172.16.1.192

This tells us that the Linux system is configured to use a DNS server located at 172.16.1.192. (The 127.0.0.1 is the localhost address and is never a valid DNS server address.)

Now it is a simple matter of using the dns proxy option to tell Samba to use the DNS server:

[global]
    dns proxy = yes

TIP

Although this allows Windows clients to resolve fully qualified Internet domain names through the Samba WINS server, it will work only for domain names that fit within the 15-character limitation of NetBIOS names. For this reason, we recommend you use dns proxy only to act as a supplement to your WINS server, rather than as a replacement for a DNS server.

Setting Up Samba to Use Another WINS Server

You can configure Samba to use a WINS server somewhere else on the network by simply providing it with the IP address of the WINS server. This is done with the global wins server configuration option, as shown here:

[global]
    wins server = 172.16.1.1

With this option enabled, Samba will direct all WINS requests to the server located at 172.16.1.1. Note that because the request is directed at a single machine, we don't have to worry about any of the problems inherent in broadcasting. However, Samba will not necessarily use the WINS server before other forms of name resolution. The order in which Samba attempts various name-resolution techniques is given with the name resolve order configuration option, which we discussed earlier.

The wins support and the wins server parameters are mutually exclusive; you cannot simultaneously offer Samba as the WINS server and use another system as the server! Typically, one Samba server is set up as the WINS server using wins support, and all other Samba servers are configured with the wins server parameter pointing to the Samba WINS server.

Configuring a WINS proxy

If you have a Samba server on a subnet that doesn't have a WINS server, and the Samba server has been configured with a WINS server on another subnet, you can tell the Samba server to forward any name-resolution requests with the wins proxy option:

[global]
    wins server = 172.16.200.12
    wins proxy = yes

Use this only in situations where the WINS server resides on another subnet. Otherwise, the broadcast will reach the WINS server regardless of any proxying.

Name-Resolution Configuration Options

Samba's name-resolution options are shown in Table 7-1.

Table 7-1. Name-resolution options

Option	Parameters	Function	Default	Scope
`wins support`	boolean	If set to `yes`, allows Samba to act as a WINS server	`no`	Global
`wins server`	string (IP address or DNS name)	Identifies a WINS server for Samba to use for name registration and resolution	None	Global
`wins proxy`	boolean	Allows Samba to act as a proxy to a WINS server on another subnet	`no`	Global
`wins hook`	string	Command to run when the WINS database changes	None	Global
`dns proxy`	boolean	If set to `yes`, allows a Samba WINS server to search DNS if it cannot find a name in WINS	`no`	Global
`name resolve` `order`	string	The order of methods used to resolve NetBIOS names	`lmhosts` `hosts wins bcast`	Global
`max ttl`	numeric	Maximum TTL in seconds for a requested NetBIOS name	`259200` ( 3 days)	Global
`max wins ttl`	numeric	Maximum TTL in seconds for NetBIOS names given out by Samba as a WINS server	`518400` (6 days)	Global
`min wins ttl`	numeric	Minimum TTL in seconds for NetBIOS names given out by Samba as a WINS server	`21600` (6 hours)	Global

wins support

Samba will provide WINS name service to all machines in the network if you set the following in the [global] section of the smb.conf file:

[global]
    wins support = yes

The default value is no, which is typically used to allow a Windows NT/2000 server or another Samba server to be the WINS server. If you enable this option, remember that a Samba WINS server currently cannot exchange data with other WINS servers, so do not allow any other WINS servers on the network. When set to yes, this option is mutually exclusive with the wins server parameter.

wins server

Samba will use an existing WINS server on the network if you specify the wins server global option in your configuration file. The value of this option is either the IP address or DNS name (not NetBIOS name) of the WINS server. For example:

[global]
    wins server = 172.16.220.110

or:

[global]
    wins server = wins.metran.cx

For this option to work, the wins support option must be set to no (the default). Otherwise, Samba will report an error. You can specify only one WINS server using this option.

wins proxy

This option allows Samba to act as a proxy to another WINS server, and thus relay name registration and resolution requests from itself to the real WINS server, often outside the current subnet. The WINS server can be indicated through the wins server option. The proxy will then return the WINS response back to the client. You can enable this option by specifying the following in the [global] section:

[global]
    wins proxy = yes

wins hook

This option allows you to run a script or other program whenever the WINS database is modified. One application might be to set up another Samba server to act as a backup for another Samba WINS server. This is done by having the wins hook script call rsync to synchronize the WINS databases (/usr/local/samba/var/locks/wins.dat) on the two systems whenever an entry is added or deleted. The script would be specified in the Samba configuration file like this:

[global]
    wins hook = /usr/local/bin/sync_wins

dns proxy

If you want the DNS to be used if a NetBIOS name isn't found in WINS, you can set the following option:

[global]
    dns proxy = yes

This will permit nmbd to query the server's standard DNS. You might wish to deactivate this option if you do not have a permanent connection to your DNS server. This option should not be used in place of a DNS server on your network; it is intended for resolving NetBIOS names rather than fully qualified Internet domain names.

name resolve order

The global name resolve order option specifies the order of services that Samba will use in performing name resolution. The default order is to use the lmhosts file, followed by standard Unix name-resolution methods (some combination of /etc/hosts, DNS, and NIS), then to query a WINS server, and finally to use broadcasting to determine the address of a NetBIOS name. You can override this option by specifying something like the following:

[global]
    name resolve order = lmhosts wins hosts bcast

This causes resolution to use the lmhosts file first, followed by a query to a WINS server, the /etc/hosts file, and finally broadcasting. You need not use all four options. This option is covered in more detail in Section 7.1.4, earlier in this chapter.

max ttl

This option is used when Samba is not acting as a WINS server but is using another system on the network for its WINS server. It sets the maximum T T L for NetBIOS names registered by the Samba server with the WINS server. You should never need to alter this value.

max wins ttl

This option is used when Samba is providing WINS name service, and it sets the maximum T T L for NetBIOS names registered with Samba. You should never need to change this value from its default.

min wins ttl

This option is used when Samba is providing WINS name service, and it sets the minimum T T L for NetBIOS names registered with Samba. You should never need to alter this value from its default.

Browsing

Browsing was developed by Microsoft to help users find shared resources on the network. In a networked computing environment where users can add or remove shares at any time, it is important to have some automatic means of keeping track of the shared resources and allowing users to "browse" through them to find the ones they wish to use.

Before browsing was added to SMB networking, when anyone added a new share, the people with whom they wished to share the data or printer would have to be informed of the share's UNC, using some relatively low-tech method such as speaking to them in person or over the phone, or sending email. Already, this was very inconvenient in large organizations. To further complicate matters, the users working on client computers had to type in the share's UNC to connect to it. The only way to get around typing in the share's UNC every time it was used was to map a network drive to it, and with a large number of shares on the network, this could easily get out of hand.

Browsing in a Windows Network

To keep things simple, we will first describe network browsing in a network that contains only Windows systems and then show you how to add a Samba server.

The basic way browsing works is that one computer in the network takes on the role of the master browser (also called local master browser, browse master, or browse server) and keeps a list of all the computers on the local subnet that are acting as SMB servers. The list of computers is called the browse list and includes all Samba servers, Windows NT/2000/XP systems, and any Windows 95/98/Me systems that have the "File and printer sharing for Microsoft Networks" networking component installed. The browse list also contains the names of all workgroups and domains. At this level, browsing is limited to the local subnet because the browsing protocol depends on broadcast packets, which are typically not forwarded to other subnets by routers.

A user at any Windows system can view the browse list by opening up the Network Neighborhood (or My Network Places), as we showed you in Chapter 1. Or, the net view command can be used from a Windows command prompt:

C:\>net view
Server Name            Remark
-------------------------------------------------------------------------------
\\MAYA                 Windows 98
\\MIXTEC               Samba 2.2.5
\\OLMEC                Windows XP Pro on Pentium/ASUS
\\TOLTEC               Samba 2.2.5
\\YAQUI                Windows 95 on mixtec/VMware
\\ZAPOTEC
The command completed successfully.

Then, net view can be used with a computer name as an argument to contact a server directly and list the resources it is sharing:

C:\>net view \\maya
Shared resources at \\maya
Windows 98
Share name   Type         Used as  Comment
-------------------------------------------------------------------------------
D            Disk
E            Disk
HP           Print
The command completed successfully.

The computers on the network involved in browsing are more than just the master browser and its clients. There are also backup browsers, which maintain copies of the browse list and respond to client requests for it. Backup browsers are therefore able to take over the role of master browser seamlessly in case it fails. The master browser usually doesn't serve the browse list directly to clients. Instead, its job is mainly to keep the master copy of the browse list up-to-date, and also periodically update the backup browsers. Clients are expected to get their copies of the browse list from backup browsers, selecting among them randomly to help to distribute the load on the backup browsers more evenly. Ideally, the interaction between any client and the master browser is limited to the client announcing when it joins or leaves the network (if it is a server) and requesting a list of backup browsers.

There can be more than one backup browser. A workgroup will have a backup browser if two or more computers are running Windows 95/98/Me or Windows NT Workstation (or another nonserver version of Windows NT/2000/XP) on the subnet. For every 32 additional computers, another backup browser is added.

In a Windows NT domain, the primary domain controller is always the local master browser, and if it fails, another Windows NT/2000 server (if one exists) will take over the role of local master browser. Other versions of Windows can function as backup browsers, but will never become a master browser if a Windows NT/2000 server is available.

In addition to acting as the local master browser, the primary domain controller also acts as the domain master browser, which ties subnets together and allows browse lists to be shared between master and backup browsers on separate subnets. This is how browsing is extended to function beyond the local subnet. Each subnet functions as a separate browsing entity, and the domain master browser synchronizes the master browsers of each subnet. In a Windows-only network, browsing cannot function across subnets unless a Windows NT/2000 PDC exists on the network. Samba can act as a domain master browser and can perform that task even in a workgroup network, which means that the Windows PDC is not required for this task. (It is also possible to use the remote browse sync parameter to configure a Samba server to synchronize its browse list with a Samba server on another subnet. In this case, each server must be acting as the local master browser of its subnet.)

Unless it is configured never to act as a browser, each computer on the subnet is considered a potential browser and can be ordered by the browse master to become a backup browser, or it can identify itself as a backup browser and accept the role on its own.

Browser Elections

When no master browser is running on the subnet, potential browsers choose a new master browser among themselves in a process called an election. An election is started by a computer in the subnet when it discovers that no master browser is currently running. If a master browser is shut down gracefully, it will broadcast an election request datagram, initiating an election by the remaining computers. If the master browser fails, the election can be started by a client computer that requests a list of backup browsers from the master browser or by a backup browser that requests to have its browse list updated from the master browser. In each case, the system fails to receive a reply from the master browser and initiates the election.

Browser elections are decided in multiple rounds of self-elimination. During each round, potential browsers broadcast election request datagrams containing their qualifications to notify other potential browsers that an election is happening and that if the recipient is more qualified, it should also broadcast a bid. When a potential browser receives an election request datagram from a more qualified opponent, it drops out, disqualifying itself from becoming the master browser. Otherwise, it responds with its own election request datagram. After a few rounds, only one potential browser is left in the election. After an additional four rounds of sending out an election request datagram and receiving no response, it becomes the master browser and sends a broadcast datagram announcing itself as the local master browser for the subnet. It then assigns runners-up in the election as backup browsers, as needed.

A potential browser's qualifications include the following:

Whether it has recently lost an election
The version of the election protocol it is running
Its election criteria
The amount of time the system has been up
The computer's NetBIOS name

If the potential browser has lost an election recently, it immediately disqualifies itself. The version of the election protocol it is running is checked, but so far, all Windows systems (and Samba) use the same election protocol, so the check is not very meaningful. The election criteria are usually what determine which computer becomes the local master browser. There are two parts to the election criteria, shown in Tables Table 7-2 and Table 7-3.

Table 7-2. Operating-system values in an election

Operating system	Value
Windows NT/2000 Server, running as PDC	32
Windows NT/2000/XP, if not the PDC	16
Windows 95/98/Me	1
Windows for Workgroups	1

Table 7-3. Computer-role settings in an election

Role	Value
Domain master browser	128
WINS client	32
Preferred master	8
Running master	4
Recent backup browser	2
Backup browser	1

The operating-system type is compared first, and the system with the highest value wins. The values have been chosen to cause the primary domain controller, if there is one, to become the local master browser. Otherwise, a Windows NT/2000/XP system will win over a Windows for Workgroups or Windows 95/98/Me system.

When an operating-system type comparison results in a tie, the role of the computer is compared. A computer can have more than one of the values in Table 7-3, in which case the values are added.

A domain master browser has a role value of 128 to weight the election so heavily in its favor that it will also become the local master browser on its own subnet. Although the primary domain controller (which is always the domain master browser) will win the election based solely on its operating system value, sometimes there is no primary domain controller on the network, and the domain master browser would not otherwise be distinguished from other potential browsers.

Systems that are using a WINS server for name resolution are weighted heavily over ones that use broadcast name resolution with a role value of 32.

A preferred master is a computer that has been selected and configured manually by a system administrator to be favored as the choice master browser. When a preferred master starts up, it forces a browser election, even if an existing master browser is still active. A preferred master has a role value of 8, and the existing master browser gets a value of 4.

A backup browser that has recently been a master browser and still has an up-to-date browse list is given a role value of 2, and a potential browser that has been running as a backup browser gets a value of 1.

If comparing the operating-system type and role results in a tie, the computer that has been running the longest wins. In the unlikely event that the two have been up for the same amount of time, the computer that wins is the one with the NetBIOS name that sorts first alphabetically.

You can tell if a machine is a local master browser by using the Windows nbtstat command. Place the NetBIOS name of the machine you wish to check after the -a option:

C:\>nbtstat -a toltec
Local Area Connection:
Node IpAddress: [172.16.1.4] Scope Id: []
           NetBIOS Remote Machine Name Table
       Name               Type         Status
    ---------------------------------------------
    TOLTEC         <00>  UNIQUE      Registered
    TOLTEC         <03>  UNIQUE      Registered
    TOLTEC         <20>  UNIQUE      Registered
    ..__MSBROWSE__.<01>  GROUP       Registered
    METRAN         <00>  GROUP       Registered
    METRAN         <1B>  UNIQUE      Registered
    METRAN         <1C>  GROUP       Registered
    METRAN         <1D>  UNIQUE      Registered
    METRAN         <1E>  GROUP       Registered
    MAC Address = 00-00-00-00-00-00

The resource entry that you're looking for is .._ _MSBROWSE_ _.<01>. This indicates that the server is currently acting as the local master browser for the current subnet. If the machine is a Samba server, you can check the Samba nmbd log file for an entry such as:

nmbd/nmbd_become_lmb.c:become_local_master_stage2(406)
*****
Samba name server TOLTEC is now a local master browser for
workgroup METRAN on subnet 172.16.1.0

Or, you can use the nmblookup command with the -M option and the workgroup or domain name on any Samba server to find the IP address of the local master:

$ nmblookup -M metran
querying metran on 172.16.1.255
172.16.1.1 metran<1d>

Server Announcements

After the master browser election is decided, each server on the network announces itself to the network to allow the master and backup browsers to build their browse lists. At first, the server announcements happen every minute, but the interval is gradually stretched out to every 12 minutes. When a server is shut down gracefully, it sends an announcement that it is going offline to allow the master and backup browsers to remove it from the browse list. However, when a server goes offline by crashing or by some other failure, the master browser notices its disappearance only because it stops receiving server announcements. The master browser waits for three of the server's announcement periods before deciding that it is offline, which can take up to 36 minutes. Because backup browsers have their browse lists updated from the master browser once every 15 minutes, it can take up to 51 minutes for clients to be informed of a failed server.

For more detailed information on Microsoft's browsing protocols, consult the Microsoft documents Browsing and Windows 95 Networking and CIFS/E Browser Protocol. You can find these by searching for the titles on the Microsoft web site at http://www.microsoft.com.

More information on configuring Samba for browsing can be found in BROWSING.txt and BROWSING-Config.txt in the Samba distribution's docs/textdocs directory.

Configuring Samba for Browsing

Samba has full support for browsing and can participate as a master browser, a backup browser, a domain master browser, a potential browser, or just a server that doesn't participate in browsing elections. If you want to make sure your Samba server never becomes a master or backup browser, simply set:

[global]
    local master = no

Usually, you will want Samba to be available as a local master or at least a backup browser. In the simplest case, you don't need to do anything because Samba's default is to participate in browsing elections with its operating system value set to 20, which will beat any Windows system less than a Windows NT/2000 primary domain controller (see Table 7-2). The operating-system value Samba reports for itself in browser elections can be set using the os level parameter:

[global]
    os level = 33

The preceding value will allow Samba to beat even a Windows 2000 Advanced Server acting as a primary domain controller. As we show in the following section, though, forcing Samba to win this way is not recommended.

If you want to allow a Windows XP Professional system to be the master browser, you would need to set Samba lower:

[global]
    os level = 8

The maximum value for os level is 255 because it is handled as an 8-bit unsigned integer. Supposing we wanted to make absolutely sure our Samba server will be the local master browser at all times, we might say:

[global]
    local master = yes
    os level = 255
    preferred master = yes

The addition of the preferred master parameter causes Samba to start a browser election as soon as it starts up, and the os level of 255 allows it to beat any other system on the network. This includes other Samba servers, assuming they are configured properly! If another server is using a similar configuration file (with os level = 255 and preferred master = yes), the two will fight each other for the master browser role, winning elections based on minor criteria, such as uptime or their current role. To avoid this, other Samba servers should be set with a lower os level and not configured to be the preferred master.

Samba as the Domain Master Browser

Previously we mentioned that for a Windows workgroup or domain to extend into multiple subnets, one system would have to take the role of the domain master browser. The domain master browser propagates browse lists across each subnet in the workgroup. This works because each local master browser periodically synchronizes its browse list with the domain master browser. During this synchronization, the local master browser passes on the name of any server that the domain master browser does not have in its browse list, and vice versa. Each local master browser eventually holds the browse list for the entire domain.

There is no election to determine which machine assumes the role of the domain master browser. Instead, the administrator has to set it manually. By Microsoft design, however, the domain master browser and the PDC both register a resource type of <1B>, so the roles—and the machines—are inseparable.

If you have a Windows NT server on the network acting as a PDC, we recommend that you do not try to use Samba to become the domain master browser. The reverse is true as well: if Samba is taking on the responsibilities of a PDC, we recommend making it the domain master browser as well. Although it is possible to split the roles with Samba, this is not a good idea. Using two different machines to serve as the PDC and the domain master browser can cause random errors to occur in a Windows workgroup.

Samba can assume the role of a domain master browser for all subnets in the workgroup with the following options:

[global]
    domain master = yes
    preferred master = yes
    local master = yes
    os level = 255

The final three parameters ensure that the server is also the local master browser, which is vital for it to work properly as the domain master browser. You can verify that a Samba machine is in fact the domain master browser by checking the nmbd log file:

nmbd/nmbd_become_dmb.c:become_domain_master_stage2(118)
*****
Samba name server TOLTEC is now a domain master browser for
workgroup METRAN on subnet 172.16.1.0

Or you can use the nmblookup command that comes with the Samba distribution to query for a unique <1B> resource type in the workgroup:

# nmblookup METRAN#1B
Sending queries to 172.16.1.255
172.16.1.1 METRAN<1b>

Multiple subnets

You must remember three rules when creating a workgroup/domain that spans more than one subnet:

You must have either a Windows NT/2000 or Samba server acting as a local master browser on each subnet in the workgroup/domain.
You must have a Windows NT/2000 Server edition or a Samba server acting as a domain master browser somewhere in the workgroup/domain.
A WINS server should be on the network, with each system on the network configured to use it for name resolution.

Samba has some additional features you can use if you don't have or want a domain master browser on your network and still need to have cross-subnet browsing. Consider the subnets shown in Figure 7-1.

Figure 7-1. Multiple subnets with Samba servers

First, a Samba server that is a local master browser can use the remote announce configuration option to make sure that computers in different subnets are sent broadcast announcements about the server. This has the effect of ensuring that the Samba server appears in the browse lists of foreign subnets. To achieve this, however, the directed broadcasts must reach the local master browser on the other subnet. Be aware that many routers do not allow directed broadcasts by default; you might have to change this setting on the router for the directed broadcasts to get through to its subnet.

With the remote announce option, list the subnets and the workgroup that should receive the broadcast. For example, to ensure that machines in the 172.16.2 and 172.16.3 subnets and the METRAN workgroup are sent broadcast information from our Samba server, we could specify the following:

[global]
    remote announce = 172.16.2.255/METRAN \
        172.16.3.255/METRAN

Instead of supplying a broadcast address of the remote subnet, you are allowed to specify the exact address where broadcasts should be sent if the local master browser on the foreign subnet is guaranteed to always have the same IP address.

A Samba local master browser can synchronize its browse list directly with one or more Samba servers, each acting as a local master browser on a different subnet. This is another way to implement browsing across subnets. For example, let's assume that Samba is configured as a local master browser, and Samba local master browsers exist at 172.16.2.130 and 172.16.3.120. We can use the remote browse sync option to sync directly with the Samba servers, as follows:

[global]
    remote browse sync = 172.16.2.130 172.16.3.120

For this to work, the other Samba machines must also be local master browsers. You can also use directed broadcasts with this option if you do not know specific IP addresses of local master browsers.

Making a Share Invisible

You can keep a share from being in the browse list by using the browsable option. This Boolean option prevents a share from being seen in the Network Neighborhood or My Network Places. For example, to prevent the [data] share from being visible, we could write:

[data]
    path = /export/samba/userdata
    browsable = no

Although you typically don't want to do this to an ordinary disk share, the browsable option is useful in the event that you need to create a share with contents that you do not want others to see, such as a [netlogon] share for storing logon scripts for Windows domain control (see Chapter 4 for more information on logon scripts).

Another example is the [homes] share. This share is often marked nonbrowsable so that a share named [homes] won't appear when its machine's resources are browsed. However, if a user alice logs on and looks at the machine's shares, an [alice] share will appear under the machine.

What if we wanted to make sure alice's share appeared to everyone before she logs on? This could be done with the global auto services option. This option preloads shares into the browse list to ensure that they are always visible:

[global]
    auto services = alice

Browsing Options

Table 7-4 shows options that define how Samba handles browsing tasks.

Table 7-4. Browsing configuration options

Option	Parameters	Function	Default	Scope
`announce as`	string	Operating system that Samba will announce itself as.	`N T Server`	Global
`announce` `version`	numeric	Version of the operating system that Samba will announce itself as.	`4.5`	Global
`browsable` `(browseable)`	Boolean	Allows share to be displayed in list of machine resources.	`yes`	Share
`browse list`	Boolean	If `yes`, allows Samba to provide a browse list on this server.	`yes`	Global
`auto services` `(preload)`	string (share list)	List of shares that will always appear in the browse list.	None	Global
`default` `service (default)`	string (share name)	Name of a share (service) that will be provided if the client requests a share not listed in smb.conf.	None	Global
`local master`	Boolean	If `yes`, allows Samba to participate in browsing elections.	`yes`	Global
`lm announce`	`yes`, `no`, or `auto`	Enables or disables LAN Manager-style host announcements.	`auto`	Global
`lm interval`	numeric	Frequency in seconds that LAN Manager announcements will be made if activated.	`60`	Global
`preferred` `master (prefered master)`	Boolean	If `yes`, allows Samba to use the preferred master browser bit to attempt to become the local master browser.	`no`	Global
`domain master`	Boolean	If `yes`, allows Samba to become the domain browser master for the workgroup or domain.	`no`	Global
`os level`	numeric	Operating system level of Samba in an election for local master browser.	`0`	Global
`remote browse` `sync`	string (list of IP addresses)	Samba servers to synchronize browse lists with.	None	Global
`remote` `announce`	string (IP address/workgroup pairs)	Subnets and workgroups to send directed broadcast packets to, allowing Samba to appear in their browse lists.	None	Global

announce as

This global configuration option specifies the type of operating system that Samba announces to other machines on the network. The default value for this option is N T Server, which causes Samba to masquerade as a Windows NT Server operating system. Other possible values are NT, NT Workstation, Win95, and W f W for a Windows for Workgroup operating system. You can override the default value with the following:

[global]
    announce as = Win95

We recommend against changing the default value of this configuration option.

announce version

This global option is frequently used with the announce as configuration option; it specifies the version of the operating system that Samba announces to other machines on the network. The default value of this option is 4.5, which places Samba above Windows NT Version 4.0, but below Windows 2000. You can specify a new value with a global entry such as the following:

[global]
    announce version = 4.3

We recommend against changing the default value of this configuration option.

browsable

The browsable option (also spelled browseable) indicates whether the share referenced should appear in the list of available resources for the system on which it resides. This option is always set to yes by default. If you wish to prevent the share from being seen in a client's browser, you can reset this option to no.

Note that this does not prevent someone from accessing the share using other means, such as specifying a UNC location (e.g., \\server\accounting) in Windows Explorer. It only prevents the share from being listed under the system's resources when being browsed.

browse list

You should never need to change this parameter from its default value of yes. If your Samba server is acting as a local master browser (i.e., it has won the browsing election), you can use the global browse list option to instruct Samba to provide or withhold its browse list to all clients. By default, Samba always provides a browse list. You can withhold this information by specifying the following:

[global]
    browse list = no

If you disable the browse list, clients cannot browse the names of other machines, their services, and other domains currently available on the network. Note that this won't make any particular machine inaccessible; if someone knows a valid machine name/address and a share on that machine, he can still connect to it explicitly using the Windows net use command or by mapping a drive letter to it using Windows Explorer. It simply prevents information in the browse list from being retrieved by any client that requests it.

auto services

The global auto services option, which is also called preload , ensures that the specified shares are always visible in the browse list. One common use for this option is to advertise specific user or printer shares that are created by the [homes] or [printers] shares, but are not otherwise browsable.

This option works best with disk shares. If you wish to force each of your system printers (i.e., those listed in the printer capabilities file) to appear in the browse list, we recommend using the load printers option instead.

Shares listed with the auto services option will not be displayed if the browse list option is set to no.

default service

The global default service option (sometimes called default) names a "last-ditch" share. The value is set to an existing share name without the enclosing brackets. When a client requests a nonexistent disk or printer share, Samba will attempt to connect the user to the share specified by this option instead. The option is specified as follows:

[global]
    default service = helpshare

When Samba redirects the requested, nonexistent service to the service specified by default service, the %S option takes on the value of the requested service, with any underscores ( _ ) in the requested service replaced by forward slashes (/).

local master

This global option specifies whether Samba will attempt to become the local master browser for the subnet when it starts up. If this option is set to yes, Samba will participate in elections. However, setting this option by itself does not guarantee victory. (Other parameters, such as preferred master and os level, help Samba win browsing elections.) If this option is set to no, Samba will lose all browsing elections, regardless of which values are specified by the other configuration options. The default value is yes.

lm announce

The global lm announce option tells Samba's nmbd whether to send LAN Manager host announcements on behalf of the server. These host announcements might be required by older clients, such as IBM's OS/2 operating system. This announcement allows the server to be added to the browse lists of the client. If activated, Samba will announce itself repetitively at the number of seconds specified by the lm interval option.

You can specify the option as follows:

[global]
    lm announce = yes

This configuration option takes the standard Boolean values, yes and no, which enable or disable LAN Manager announcements, respectively. In addition, a third option, auto, causes nmbd to listen passively for LAN Manager announcements, but not to send any of its own initially. If LAN Manager announcements are detected for another machine on the network, nmbd will start sending its own LAN Manager announcements to ensure that it is visible. The default value is auto. You probably won't need to change this value from its default.

lm interval

This option, which is used in conjunction with lm announce, indicates the number of seconds nmbd will wait before repeatedly broadcasting LAN Manager-style announcements. LAN Manager announcements must be enabled for this option to work. The default value is 60 seconds. If you set this value to 0, Samba will not send any LAN Manager host announcements, regardless of the value of the lm announce option. You can reset the value of this option as follows:

[global]
    lm interval = 90

preferred master

The preferred master option requests that Samba set the preferred master bit when participating in an election. This gives the server a higher preferred status in the workgroup than other machines at the same operating-system level. If you are configuring your Samba machine to become the local master browser, it is wise to set the following value:

[global]
    preferred master = yes

Otherwise, you should leave it set to its default, no. If Samba is configured as a preferred master browser, it will force an election when it first comes online.

domain master

If Samba is the primary domain controller for your workgroup or NT domain, it should also be made the domain master browser. The domain master browser is a special machine that has the NetBIOS resource type <1B> and is used to propagate browse lists to and from each local master browser in individual subnets across the domain. To force Samba to become the domain master browser, set the following in the [global] section of the smb.conf:

[global]
    domain master = yes

If you have a Windows NT server on the network acting as a primary domain controller (PDC), we recommend that you do not use Samba to become the domain master browser. The reverse is true as well: if Samba is taking on the responsibilities of a PDC, we recommend making it the domain master browser. Splitting the PDC and the domain master browser will cause unpredictable errors to occur on the network.

os level

The global os level option defines the operating-system value with which Samba will masquerade during a browser election. If you wish to have Samba win an election and become the master browser, set the os level higher than that of any other system on the subnet. The values are shown in Table 7-2. The default level is 20, which means that Samba will win elections against all versions of Windows, except Windows NT/2000 if it is operating as the PDC. If you wish Samba to win all elections, you can set its operating system value as follows:

[global]
    os level = 255

remote browse sync

The global remote browse sync option specifies that Samba should synchronize its browse lists with local master browsers in other subnets. However, the synchronization can occur only with other Samba servers and not with Windows computers. For example, if your Samba server were a master browser on the subnet 172.16.235, and Samba local master browsers existed on other subnets located at 172.16.234.92 and 172.16.236.2, you would specify the following:

[global]
    remote browse sync = 172.16.234.92 172.16.236.2

The Samba server would then directly contact the other machines on the address list and synchronize browse lists. You can also say:

[global]
    remote browse sync = 172.16.234.255 172.16.236.255

This forces Samba to broadcast queries to determine the IP addresses of the local master browser on each subnet, with which it will then synchronize browse lists. This works, however, only if your router doesn't block directed broadcast requests ending in 255.

remote announce

Samba servers are capable of providing browse lists to foreign subnets with the remote announce option. This is typically sent to the local master browser of the foreign subnet in question. However, if you do not know the address of the local master browser, you can do the following:

[global]
    remote announce = 172.16.234.255/ACCOUNTING \       
                        172.16.236.255/ACCOUNTING

With this, Samba will broadcast host announcements to all machines on subnets 172.16.234 and 172.16.236, which will hopefully reach the local master browser of the subnet.

You can also specify exact IP addresses, if they are known, but this works only if the systems are guaranteed to maintain the role of master browser on their subnets. By appending a workgroup or domain name to the IP address, Samba announces that it is in that workgroup or domain. If this is left out, the workgroup set by the workgroup parameter is used.

Footnotes

[1] As we explained in Chapter 1, a system can register under more than one NetBIOS name. We use the singular here only to keep our explanation simple.