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>
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.
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 of Using Samba, 2nd Edition 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