--- /dev/null
+<html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>Chapter 9. Network Browsing</title><link rel="stylesheet" href="samba.css" type="text/css"><meta name="generator" content="DocBook XSL Stylesheets V1.68.1"><link rel="start" href="index.html" title="The Official Samba-3 HOWTO and Reference Guide"><link rel="up" href="optional.html" title="Part III. Advanced Configuration"><link rel="prev" href="optional.html" title="Part III. Advanced Configuration"><link rel="next" href="passdb.html" title="Chapter 10. Account Information Databases"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Chapter 9. Network Browsing</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="optional.html">Prev</a> </td><th width="60%" align="center">Part III. Advanced Configuration</th><td width="20%" align="right"> <a accesskey="n" href="passdb.html">Next</a></td></tr></table><hr></div><div class="chapter" lang="en"><div class="titlepage"><div><div><h2 class="title"><a name="NetworkBrowsing"></a>Chapter 9. Network Browsing</h2></div><div><div class="author"><h3 class="author"><span class="firstname">John</span> <span class="othername">H.</span> <span class="surname">Terpstra</span></h3><div class="affiliation"><span class="orgname">Samba Team<br></span><div class="address"><p><code class="email"><<a href="mailto:jht@samba.org">jht@samba.org</a>></code></p></div></div></div></div><div><div class="author"><h3 class="author"><span class="firstname">Jelmer</span> <span class="othername">R.</span> <span class="surname">Vernooij</span></h3><div class="affiliation"><span class="orgname">The Samba Team<br></span><div class="address"><p><code class="email"><<a href="mailto:jelmer@samba.org">jelmer@samba.org</a>></code></p></div></div></div></div><div><p class="pubdate">July 5, 1998</p></div><div><p class="pubdate">Updated: April 21, 2003</p></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="sect1"><a href="NetworkBrowsing.html#id2546319">Features and Benefits</a></span></dt><dt><span class="sect1"><a href="NetworkBrowsing.html#id2546502">What Is Browsing?</a></span></dt><dt><span class="sect1"><a href="NetworkBrowsing.html#netdiscuss">Discussion</a></span></dt><dd><dl><dt><span class="sect2"><a href="NetworkBrowsing.html#id2546885">NetBIOS over TCP/IP</a></span></dt><dt><span class="sect2"><a href="NetworkBrowsing.html#id2547489">TCP/IP without NetBIOS</a></span></dt><dt><span class="sect2"><a href="NetworkBrowsing.html#adsdnstech">DNS and Active Directory</a></span></dt></dl></dd><dt><span class="sect1"><a href="NetworkBrowsing.html#id2548048">How Browsing Functions</a></span></dt><dd><dl><dt><span class="sect2"><a href="NetworkBrowsing.html#DMB">Configuring Workgroup Browsing</a></span></dt><dt><span class="sect2"><a href="NetworkBrowsing.html#id2548972">Domain Browsing Configuration</a></span></dt><dt><span class="sect2"><a href="NetworkBrowsing.html#browse-force-master">Forcing Samba to Be the Master</a></span></dt><dt><span class="sect2"><a href="NetworkBrowsing.html#id2549538">Making Samba the Domain Master</a></span></dt><dt><span class="sect2"><a href="NetworkBrowsing.html#id2549766">Note about Broadcast Addresses</a></span></dt><dt><span class="sect2"><a href="NetworkBrowsing.html#id2549788">Multiple Interfaces</a></span></dt><dt><span class="sect2"><a href="NetworkBrowsing.html#id2549966">Use of the Remote Announce Parameter</a></span></dt><dt><span class="sect2"><a href="NetworkBrowsing.html#id2550101">Use of the Remote Browse Sync Parameter</a></span></dt></dl></dd><dt><span class="sect1"><a href="NetworkBrowsing.html#id2550191">WINS: The Windows Internetworking Name Server</a></span></dt><dd><dl><dt><span class="sect2"><a href="NetworkBrowsing.html#id2550448">WINS Server Configuration</a></span></dt><dt><span class="sect2"><a href="NetworkBrowsing.html#id2550754">WINS Replication</a></span></dt><dt><span class="sect2"><a href="NetworkBrowsing.html#id2550792">Static WINS Entries</a></span></dt></dl></dd><dt><span class="sect1"><a href="NetworkBrowsing.html#id2551023">Helpful Hints</a></span></dt><dd><dl><dt><span class="sect2"><a href="NetworkBrowsing.html#id2551034">Windows Networking Protocols</a></span></dt><dt><span class="sect2"><a href="NetworkBrowsing.html#id2551184">Name Resolution Order</a></span></dt></dl></dd><dt><span class="sect1"><a href="NetworkBrowsing.html#id2551391">Technical Overview of Browsing</a></span></dt><dd><dl><dt><span class="sect2"><a href="NetworkBrowsing.html#id2551473">Browsing Support in Samba</a></span></dt><dt><span class="sect2"><a href="NetworkBrowsing.html#id2551662">Problem Resolution</a></span></dt><dt><span class="sect2"><a href="NetworkBrowsing.html#id2551901">Cross-Subnet Browsing</a></span></dt></dl></dd><dt><span class="sect1"><a href="NetworkBrowsing.html#id2552915">Common Errors</a></span></dt><dd><dl><dt><span class="sect2"><a href="NetworkBrowsing.html#id2552942">Flushing the Samba NetBIOS Name Cache</a></span></dt><dt><span class="sect2"><a href="NetworkBrowsing.html#id2553015">Server Resources Cannot Be Listed</a></span></dt><dt><span class="sect2"><a href="NetworkBrowsing.html#id2553059">I Get an "<span class="errorname">Unable to browse the network</span>" Error</a></span></dt><dt><span class="sect2"><a href="NetworkBrowsing.html#id2553106">Browsing of Shares and Directories is Very Slow</a></span></dt></dl></dd></dl></div><p>
+<a class="indexterm" name="id2546253"></a>
+<a class="indexterm" name="id2546260"></a>
+<a class="indexterm" name="id2546267"></a>
+This chapter contains detailed information as well as a fast-track guide to
+implementing browsing across subnets and/or across workgroups (or domains).
+WINS is the best tool for resolution of NetBIOS names to IP addresses; however, WINS is
+not involved in browse list handling except by way of name-to-address resolution.
+</p><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>
+<a class="indexterm" name="id2546284"></a>
+<a class="indexterm" name="id2546291"></a>
+<a class="indexterm" name="id2546298"></a>
+<a class="indexterm" name="id2546304"></a>
+MS Windows 2000 and later versions can be configured to operate with no NetBIOS
+over TCP/IP. Samba-3 and later versions also support this mode of operation.
+When the use of NetBIOS over TCP/IP has been disabled, the primary
+means for resolution of MS Windows machine names is via DNS and Active Directory.
+The following information assumes that your site is running NetBIOS over TCP/IP.
+</p></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2546319"></a>Features and Benefits</h2></div></div></div><p>
+Charles Dickens once referred to the past in these words: “<span class="quote"><span class="emphasis"><em>It was the best of times,
+it was the worst of times.</em></span></span>” The more we look back, the more we long for what was and
+hope it never returns.
+</p><p>
+<a class="indexterm" name="id2546338"></a>
+<a class="indexterm" name="id2546345"></a>
+<a class="indexterm" name="id2546352"></a>
+For many MS Windows network administrators, that statement sums up their feelings about
+NetBIOS networking precisely. For those who mastered NetBIOS networking, its fickle
+nature was just par for the course. For those who never quite managed to tame its
+lusty features, NetBIOS is like Paterson's Curse.
+</p><p>
+For those not familiar with botanical problems in Australia, Paterson's Curse,
+<span class="emphasis"><em>Echium plantagineum</em></span>, was introduced to Australia from Europe during the mid-19th
+century. Since then it has spread rapidly. The high seed production, with densities of
+thousands of seeds per square meter, a seed longevity of more than 7 years, and an
+ability to germinate at any time of year, given the right conditions, are some of the
+features that make it such a persistent weed.
+</p><p>
+<a class="indexterm" name="id2546381"></a>
+<a class="indexterm" name="id2546391"></a>
+<a class="indexterm" name="id2546397"></a>
+<a class="indexterm" name="id2546404"></a>
+<a class="indexterm" name="id2546411"></a>
+In this chapter we explore vital aspects of Server Message Block (SMB) networking with
+a particular focus on SMB as implemented through running NetBIOS (Network Basic
+Input/Output System) over TCP/IP. Since Samba does not implement SMB or NetBIOS over
+any other protocols, we need to know how to configure our network environment and simply
+remember to use nothing but TCP/IP on all our MS Windows network clients.
+</p><p>
+<a class="indexterm" name="id2546428"></a>
+<a class="indexterm" name="id2546435"></a>
+Samba provides the ability to implement a WINS (Windows Internetworking Name Server)
+and implements extensions to Microsoft's implementation of WINS. These extensions
+help Samba to effect stable WINS operations beyond the normal scope of MS WINS.
+</p><p>
+<a class="indexterm" name="id2546449"></a>
+<a class="indexterm" name="id2546456"></a>
+<a class="indexterm" name="id2546463"></a>
+WINS is exclusively a service that applies only to those systems
+that run NetBIOS over TCP/IP. MS Windows 200x/XP have the capacity to operate with
+support for NetBIOS disabled, in which case WINS is of no relevance. Samba supports this also.
+</p><p>
+<a class="indexterm" name="id2546478"></a>
+<a class="indexterm" name="id2546484"></a>
+<a class="indexterm" name="id2546491"></a>
+For those networks on which NetBIOS has been disabled (i.e., WINS is not required),
+the use of DNS is necessary for hostname resolution.
+</p></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2546502"></a>What Is Browsing?</h2></div></div></div><p>
+<a class="indexterm" name="id2546510"></a>
+<a class="indexterm" name="id2546517"></a>
+<a class="indexterm" name="id2546524"></a>
+<a class="indexterm" name="id2546531"></a>
+To most people, browsing means they can see the MS Windows and Samba servers
+in the Network Neighborhood, and when the computer icon for a particular server is
+clicked, it opens up and shows the shares and printers available on the target server.
+</p><p>
+What seems so simple is in fact a complex interaction of different technologies.
+The technologies (or methods) employed in making all of this work include:
+</p><div class="itemizedlist"><ul type="disc"><li><p>MS Windows machines register their presence to the network.</p></li><li><p>Machines announce themselves to other machines on the network.</p></li><li><p>One or more machines on the network collate the local announcements.</p></li><li><p>The client machine finds the machine that has the collated list of machines.</p></li><li><p>The client machine is able to resolve the machine names to IP addresses.</p></li><li><p>The client machine is able to connect to a target machine.</p></li></ul></div><p>
+<a class="indexterm" name="id2546588"></a>
+<a class="indexterm" name="id2546595"></a>
+<a class="indexterm" name="id2546602"></a>
+The Samba application that controls browse list management and name resolution is
+called <code class="filename">nmbd</code>. The configuration parameters involved in nmbd's operation are:
+</p><p>
+Browsing options:
+</p><div class="itemizedlist"><ul type="disc"><li><a class="indexterm" name="id2546625"></a>os level</li><li><a class="indexterm" name="id2546634"></a>lm announce</li><li><a class="indexterm" name="id2546643"></a>lm interval</li><li><a class="indexterm" name="id2546652"></a>preferred master(*)</li><li><a class="indexterm" name="id2546662"></a>local master(*)</li><li><a class="indexterm" name="id2546671"></a>domain master(*)</li><li><a class="indexterm" name="id2546681"></a>browse list</li><li><a class="indexterm" name="id2546690"></a>enhanced browsing</li></ul></div><p>
+Name Resolution Method:
+</p><div class="itemizedlist"><ul type="disc"><li><a class="indexterm" name="id2546706"></a>name resolve order(*)</li></ul></div><p>
+WINS options:
+</p><div class="itemizedlist"><ul type="disc"><li><a class="indexterm" name="id2546723"></a>dns proxy</li><li><a class="indexterm" name="id2546732"></a>wins proxy</li><li><a class="indexterm" name="id2546741"></a>wins server(*)</li><li><a class="indexterm" name="id2546750"></a>wins support(*)</li><li><a class="indexterm" name="id2546760"></a>wins hook</li></ul></div><p>
+Those marked with an (*) are the only options that commonly may need to be modified. Even if none of these
+parameters is set, <code class="filename">nmbd</code> will still do its job.
+</p><p>
+<a class="indexterm" name="id2546783"></a>
+<a class="indexterm" name="id2546790"></a>
+<a class="indexterm" name="id2546797"></a>
+<a class="indexterm" name="id2546804"></a>
+<a class="indexterm" name="id2546810"></a>
+For Samba, the WINS Server and WINS Support are mutually exclusive options. When <span><strong class="command">nmbd</strong></span> is
+started it will fail to execute if both options are set in the <code class="filename">smb.conf</code> file. The <span><strong class="command">nmbd</strong></span>
+understands that when it spawns an instance of itself to run as a WINS server that it has to use its own WINS
+server also.
+</p></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="netdiscuss"></a>Discussion</h2></div></div></div><p>
+<a class="indexterm" name="id2546853"></a>
+<a class="indexterm" name="id2546860"></a>
+<a class="indexterm" name="id2546866"></a>
+<a class="indexterm" name="id2546873"></a>
+All MS Windows networking uses SMB-based messaging. SMB messaging may be implemented with or without NetBIOS.
+MS Windows 200x supports NetBIOS over TCP/IP for backwards compatibility. Microsoft appears intent on phasing
+out NetBIOS support.
+</p><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2546885"></a>NetBIOS over TCP/IP</h3></div></div></div><p>
+<a class="indexterm" name="id2546893"></a>
+<a class="indexterm" name="id2546900"></a>
+<a class="indexterm" name="id2546907"></a>
+<a class="indexterm" name="id2546914"></a>
+Samba implements NetBIOS, as does MS Windows NT/200x/XP, by encapsulating it over TCP/IP.
+NetBIOS-based networking uses broadcast messaging to effect browse list management. When running NetBIOS over
+TCP/IP, this uses UDP-based messaging. UDP messages can be broadcast or unicast.
+</p><p>
+<a class="indexterm" name="id2546928"></a>
+Normally, only unicast UDP messaging can be forwarded by routers. The
+<a class="indexterm" name="id2546936"></a>remote announce parameter to smb.conf helps to project browse announcements
+to remote network segments via unicast UDP. Similarly, the
+<a class="indexterm" name="id2546946"></a>remote browse sync parameter of <code class="filename">smb.conf</code>
+implements browse list collation using unicast UDP.
+</p><p>
+The methods used by MS Windows to perform name lookup requests (name resolution) is determined by a
+configuration parameter called the NetBIOS node-type. There are four basic NetBIOS node types:
+</p><a class="indexterm" name="id2546968"></a><a class="indexterm" name="id2546974"></a><a class="indexterm" name="id2546981"></a><a class="indexterm" name="id2546988"></a><a class="indexterm" name="id2546995"></a><a class="indexterm" name="id2547002"></a><a class="indexterm" name="id2547008"></a><a class="indexterm" name="id2547015"></a><div class="itemizedlist"><ul type="disc"><li><p><span class="emphasis"><em>b-node (type 0x01):</em></span> The Windows client will use only
+ NetBIOS broadcast requests using UDP broadcast.</p></li><li><p><span class="emphasis"><em>p-node (type 0x02):</em></span> The Windows client will use point-to-point
+ (NetBIOS unicast) requests using UDP unicast directed to a WINS server.</p></li><li><p><span class="emphasis"><em>m-node (type 0x04):</em></span> The Windows client will first use
+ NetBIOS broadcast requests using UDP broadcast, then it will use (NetBIOS unicast)
+ requests using UDP unicast directed to a WINS server.</p></li><li><p><span class="emphasis"><em>h-node (type 0x08):</em></span> The Windows client will use
+ (NetBIOS unicast) requests using UDP unicast directed to a WINS server, then it will use
+ NetBIOS broadcast requests using UDP broadcast.</p></li></ul></div><p>
+<a class="indexterm" name="id2547064"></a>
+<a class="indexterm" name="id2547071"></a>
+<a class="indexterm" name="id2547078"></a>
+<a class="indexterm" name="id2547085"></a>
+<a class="indexterm" name="id2547092"></a>
+<a class="indexterm" name="id2547099"></a>
+The default Windows network client (or server) network configuration enables NetBIOS over TCP/IP
+and b-node configuration. The use of WINS makes most sense with h-node (hybrid mode) operation so that
+in the event of a WINS breakdown or non-availability, the client can use broadcast-based name resolution.
+</p><p>
+<a class="indexterm" name="id2547114"></a>
+<a class="indexterm" name="id2547123"></a>
+<a class="indexterm" name="id2547130"></a>
+<a class="indexterm" name="id2547137"></a>
+<a class="indexterm" name="id2547144"></a>
+<a class="indexterm" name="id2547150"></a>
+<a class="indexterm" name="id2547157"></a>
+In those networks where Samba is the only SMB server technology, wherever possible <code class="filename">nmbd</code>
+should be configured on one machine as the WINS server. This makes it easy to manage the browsing environment.
+If each network segment is configured with its own Samba WINS server, then the only way to get cross-segment
+browsing to work is by using the <a class="indexterm" name="id2547176"></a>remote announce and the <a class="indexterm" name="id2547184"></a>remote browse sync parameters to your <code class="filename">smb.conf</code> file.
+</p><p>
+<a class="indexterm" name="id2547200"></a>
+If only one WINS server is used for an entire multisegment network, then
+the use of the <a class="indexterm" name="id2547209"></a>remote announce and the
+<a class="indexterm" name="id2547216"></a>remote browse sync parameters should not be necessary.
+</p><p>
+<a class="indexterm" name="id2547228"></a>
+As of Samba-3, WINS replication is being worked on. The bulk of the code has been committed, but it still
+needs maturation. This is not a supported feature of the Samba-3.0.20 release. Hopefully, this will become a
+supported feature of one of the Samba-3 release series. The delay is caused by the fact that this feature has
+not been of sufficient significance to inspire someone to pay a developer to complete it.
+</p><p>
+<a class="indexterm" name="id2547247"></a>
+<a class="indexterm" name="id2547254"></a>
+<a class="indexterm" name="id2547261"></a>
+<a class="indexterm" name="id2547268"></a>
+<a class="indexterm" name="id2547274"></a>
+<a class="indexterm" name="id2547281"></a>
+<a class="indexterm" name="id2547288"></a>
+<a class="indexterm" name="id2547295"></a>
+Right now Samba WINS does not support MS-WINS replication. This means that when setting up Samba as a WINS
+server, there must only be one <code class="filename">nmbd</code> configured as a WINS server on the network. Some
+sites have used multiple Samba WINS servers for redundancy (one server per subnet) and then used
+<a class="indexterm" name="id2547312"></a>remote browse sync and <a class="indexterm" name="id2547320"></a>remote announce to effect browse list
+collation across all segments. Note that this means clients will only resolve local names and must be
+configured to use DNS to resolve names on other subnets in order to resolve the IP addresses of the servers
+they can see on other subnets. This setup is not recommended but is mentioned as a practical consideration
+(i.e., an “<span class="quote">if all else fails</span>” scenario). NetBIOS over TCP/IP is an ugly and difficult to manage
+protocol. Its replacement, NetBIOSless SMB over TCP/IP is not without its own manageability concerns. NetBIOS
+based networking is a life of compromise and trade-offs. WINS stores information that cannot be stored in
+DNS; consequently, DNS is a poor substitute for WINS given that when NetBIOS over TCP/IP is used, Windows
+clients are designed to use WINS.
+</p><p>
+<a class="indexterm" name="id2547347"></a>
+<a class="indexterm" name="id2547354"></a>
+<a class="indexterm" name="id2547361"></a>
+Lastly, take note that browse lists are a collection of unreliable broadcast
+messages that are repeated at intervals of not more than 15 minutes. This means
+that it will take time to establish a browse list, and it can take up to 45
+minutes to stabilize, particularly across network segments.
+</p><p>
+<a class="indexterm" name="id2547376"></a>
+When an MS Windows 200x/XP system attempts to resolve a host name to an IP address, it follows a defined path:
+</p><div class="orderedlist"><ol type="1"><li><p>
+ Checks the <code class="filename">hosts</code> file. It is located in <code class="filename">%SystemRoot%\System32\Drivers\etc</code>.
+ </p></li><li><p>
+ Does a DNS lookup.
+ </p></li><li><p>
+ Checks the NetBIOS name cache.
+ </p></li><li><p>
+ Queries the WINS server.
+ </p></li><li><p>
+ Does a broadcast name lookup over UDP.
+ </p></li><li><p>
+ Looks up entries in LMHOSTS, located in <code class="filename">%SystemRoot%\System32\Drivers\etc</code>.
+ </p></li></ol></div><p>
+<a class="indexterm" name="id2547444"></a>
+<a class="indexterm" name="id2547451"></a>
+<a class="indexterm" name="id2547458"></a>
+<a class="indexterm" name="id2547465"></a>
+Given the nature of how the NetBIOS over TCP/IP protocol is implemented, only WINS is capable of resolving
+with any reliability name lookups for service-oriented names such as TEMPTATION<1C> a NetBIOS
+name query that seeks to find network logon servers. DNS has no concept of service-oriented names such as
+this. In fact, the Microsoft ADS implementation specifically manages a whole range of extended
+service-oriented DNS entries. This type of facility is not implemented and is not supported for the NetBIOS
+over TCP/IP protocol namespace.
+</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2547489"></a>TCP/IP without NetBIOS</h3></div></div></div><p>
+<a class="indexterm" name="id2547496"></a>
+<a class="indexterm" name="id2547503"></a>
+<a class="indexterm" name="id2547510"></a>
+All TCP/IP-enabled systems use various forms of hostname resolution. The primary
+methods for TCP/IP hostname resolution involve either a static file (<code class="filename">/etc/hosts</code>)
+or the Domain Name System (DNS). DNS is the technology that makes
+the Internet usable. DNS-based hostname resolution is supported by nearly all
+TCP/IP-enabled systems. Only a few embedded TCP/IP systems do not support DNS.
+</p><p>
+<a class="indexterm" name="id2547532"></a>
+<a class="indexterm" name="id2547539"></a>
+<a class="indexterm" name="id2547546"></a>
+<a class="indexterm" name="id2547552"></a>
+Windows 200x/XP can register its hostname with a Dynamic DNS server (DDNS). It is possible to force register with a
+dynamic DNS server in Windows 200x/XP using <span><strong class="command">ipconfig /registerdns</strong></span>.
+</p><p>
+<a class="indexterm" name="id2547574"></a>
+<a class="indexterm" name="id2547580"></a>
+<a class="indexterm" name="id2547587"></a>
+With Active Directory, a correctly functioning DNS server is absolutely essential. In the absence of a working
+DNS server that has been correctly configured, MS Windows clients and servers will be unable to locate each
+other, so network services consequently will be severely impaired.
+</p><p>
+<a class="indexterm" name="id2547602"></a>
+<a class="indexterm" name="id2547609"></a>
+<a class="indexterm" name="id2547616"></a>
+<a class="indexterm" name="id2547622"></a>
+<a class="indexterm" name="id2547629"></a>
+<a class="indexterm" name="id2547636"></a>
+Use of raw SMB over TCP/IP (No NetBIOS layer) can be done only with Active Directory domains. Samba is not an
+Active Directory domain controller: ergo, it is not possible to run Samba as a domain controller and at the same
+time <span class="emphasis"><em>not</em></span> use NetBIOS. Where Samba is used as an Active Directory domain member server
+(DMS) it is possible to configure Samba to not use NetBIOS over TCP/IP. A Samba DMS can integrate fully into
+an Active Directory domain, however, if NetBIOS over TCP/IP is disabled, it is necessary to manually create
+appropriate DNS entries for the Samba DMS because they will not be automatically generated either by Samba, or
+by the ADS environment.
+</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="adsdnstech"></a>DNS and Active Directory</h3></div></div></div><p>
+<a class="indexterm" name="id2547671"></a>
+<a class="indexterm" name="id2547680"></a>
+<a class="indexterm" name="id2547687"></a>
+<a class="indexterm" name="id2547693"></a>
+<a class="indexterm" name="id2547700"></a>
+Occasionally we hear from UNIX network administrators who want to use a UNIX-based DDNS server in place
+of the Microsoft DNS server. While this might be desirable to some, the MS Windows 200x DNS server is
+autoconfigured to work with Active Directory. It is possible to use BIND version 8 or 9, but it will almost
+certainly be necessary to create service records (SRV records) so MS Active Directory clients can resolve
+hostnames to locate essential network services. The following are some of the default service records that
+Active Directory requires:
+</p><p>
+<a class="indexterm" name="id2547722"></a>
+<a class="indexterm" name="id2547728"></a>
+<a class="indexterm" name="id2547735"></a>
+The use of DDNS is highly recommended with Active Directory, in which case the use of BIND9 is preferred for
+its ability to adequately support the SRV (service) records that are needed for Active Directory. Of course,
+when running ADS, it makes sense to use Microsoft's own DDNS server because of the natural affinity between ADS
+and MS DNS.
+</p><div class="variablelist"><dl><dt><span class="term">_ldap._tcp.pdc._msdcs.<span class="emphasis"><em>Domain</em></span></span></dt><dd><p>
+ This provides the address of the Windows NT PDC for the domain.
+ </p></dd><dt><span class="term">_ldap._tcp.pdc._msdcs.<span class="emphasis"><em>DomainTree</em></span></span></dt><dd><p>
+ Resolves the addresses of global catalog servers in the domain.
+ </p></dd><dt><span class="term">_ldap._tcp.<span class="emphasis"><em>site</em></span>.sites.writable._msdcs.<span class="emphasis"><em>Domain</em></span></span></dt><dd><p>
+ Provides list of domain controllers based on sites.
+ </p></dd><dt><span class="term">_ldap._tcp.writable._msdcs.<span class="emphasis"><em>Domain</em></span></span></dt><dd><p>
+ Enumerates list of domain controllers that have the writable copies of the Active Directory data store.
+ </p></dd><dt><span class="term">_ldap._tcp.<span class="emphasis"><em>GUID</em></span>.domains._msdcs.<span class="emphasis"><em>DomainTree</em></span></span></dt><dd><p>
+ Entry used by MS Windows clients to locate machines using the global unique identifier.
+ </p></dd><dt><span class="term">_ldap._tcp.<span class="emphasis"><em>Site</em></span>.gc._msdcs.<span class="emphasis"><em>DomainTree</em></span></span></dt><dd><p>
+ Used by Microsoft Windows clients to locate the site configuration-dependent global catalog server.
+ </p></dd></dl></div><p>
+ Specific entries used by Microsoft clients to locate essential services for an example domain
+ called <code class="constant">quenya.org</code> include:
+ </p><div class="itemizedlist"><ul type="disc"><li><p>
+ _kerberos._udp.quenya.org Used to contact the KDC server via UDP.
+ This entry must list port 88 for each KDC.
+ </p></li><li><p>
+ _kpasswd._udp.quenya.org Used to locate the <code class="constant">kpasswd</code> server
+ when a user password change must be processed. This record must list port 464 on the
+ master KDC.
+ </p></li><li><p>
+ _kerberos._tcp.quenya.org Used to locate the KDC server via TCP.
+ This entry must list port 88 for each KDC.
+ </p></li><li><p>
+ _ldap._tcp.quenya.org Used to locate the LDAP service on the PDC.
+ This record must list port 389 for the PDC.
+ </p></li><li><p>
+ _kpasswd._tcp.quenya.org Used to locate the <code class="constant">kpasswd</code> server
+ to permit user password changes to be processed. This must list port 464.
+ </p></li><li><p>
+ _gc._tcp.quenya.org Used to locate the global catalog server for the
+ top of the domain. This must list port 3268.
+ </p></li></ul></div><p>
+ The following records are also used by the Windows domain member client to locate vital
+ services on the Windows ADS domain controllers.
+ </p><div class="itemizedlist"><ul type="disc"><li><p>
+ _ldap._tcp.pdc._msdcs.quenya.org
+ </p></li><li><p>
+ _ldap.gc._msdcs.quenya.org
+ </p></li><li><p>
+ _ldap.default-first-site-name._sites.gc._msdcs.quenya.org
+ </p></li><li><p>
+ _ldap.{SecID}.domains._msdcs.quenya.org
+ </p></li><li><p>
+ _ldap._tcp.dc._msdcs.quenya.org
+ </p></li><li><p>
+ _kerberos._tcp.dc._msdcs.quenya.org
+ </p></li><li><p>
+ _ldap.default-first-site-name._sites.dc._msdcs.quenya.org
+ </p></li><li><p>
+ _kerberos.default-first-site-name._sites.dc._msdcs.queyna.org
+ </p></li><li><p>
+ SecID._msdcs.quenya.org
+ </p></li></ul></div><p>
+ Presence of the correct DNS entries can be validated by executing:
+</p><pre class="screen">
+<code class="prompt">root# </code> dig @frodo -t any _ldap._tcp.dc._msdcs.quenya.org
+
+; <lt;>> DiG 9.2.2 <lt;>> @frodo -t any _ldap._tcp.dc._msdcs.quenya.org
+;; global options: printcmd
+;; Got answer:
+;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3072
+;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 2
+
+
+;; QUESTION SECTION:
+;_ldap._tcp.dc._msdcs.quenya.org. IN ANY
+
+
+;; ANSWER SECTION:
+_ldap._tcp.dc._msdcs.quenya.org. 600 IN SRV 0 100 389 frodo.quenya.org.
+_ldap._tcp.dc._msdcs.quenya.org. 600 IN SRV 0 100 389 noldor.quenya.org.
+
+
+;; ADDITIONAL SECTION:
+frodo.quenya.org. 3600 IN A 10.1.1.16
+noldor.quenya.org. 1200 IN A 10.1.1.17
+
+
+;; Query time: 0 msec
+;; SERVER: frodo#53(10.1.1.16)
+;; WHEN: Wed Oct 7 14:39:31 2004
+;; MSG SIZE rcvd: 171
+</pre><p>
+ </p></div></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2548048"></a>How Browsing Functions</h2></div></div></div><p>
+<a class="indexterm" name="id2548056"></a>
+<a class="indexterm" name="id2548063"></a>
+<a class="indexterm" name="id2548070"></a>
+<a class="indexterm" name="id2548076"></a>
+<a class="indexterm" name="id2548083"></a>
+MS Windows machines register their NetBIOS names (i.e., the machine name for each service type in operation)
+on startup. The exact method by which this name registration takes place is determined by whether or not the
+MS Windows client/server has been given a WINS server address, whether or not LMHOSTS lookup is enabled,
+whether or not DNS for NetBIOS name resolution is enabled, and so on.
+</p><p>
+<a class="indexterm" name="id2548100"></a>
+<a class="indexterm" name="id2548107"></a>
+<a class="indexterm" name="id2548114"></a>
+In the case where there is no WINS server, all name registrations as well as name lookups are done by UDP
+broadcast. This isolates name resolution to the local subnet, unless LMHOSTS is used to list all names and IP
+addresses. In such situations, Samba provides a means by which the Samba server name may be forcibly injected
+into the browse list of a remote MS Windows network (using the <a class="indexterm" name="id2548127"></a>remote announce
+parameter).
+</p><p>
+<a class="indexterm" name="id2548138"></a>
+<a class="indexterm" name="id2548144"></a>
+<a class="indexterm" name="id2548151"></a>
+Where a WINS server is used, the MS Windows client will use UDP unicast to register with the WINS server. Such
+packets can be routed, and thus WINS allows name resolution to function across routed networks.
+</p><p>
+<a class="indexterm" name="id2548165"></a>
+<a class="indexterm" name="id2548172"></a>
+<a class="indexterm" name="id2548181"></a>
+<a class="indexterm" name="id2548188"></a>
+<a class="indexterm" name="id2548195"></a>
+<a class="indexterm" name="id2548201"></a>
+<a class="indexterm" name="id2548208"></a>
+<a class="indexterm" name="id2548215"></a>
+During the startup process, an election takes place to create a local master browser (LMB) if one does not
+already exist. On each NetBIOS network one machine will be elected to function as the domain master browser
+(DMB). This domain browsing has nothing to do with MS security Domain Control. Instead, the DMB serves the
+role of contacting each LMB (found by asking WINS or from LMHOSTS) and exchanging browse list contents. This
+way every master browser will eventually obtain a complete list of all machines that are on the network. Every
+11 to 15 minutes an election is held to determine which machine will be the master browser. By the nature of
+the election criteria used, the machine with the highest uptime, or the most senior protocol version or other
+criteria, will win the election as DMB.
+</p><p>
+<a class="indexterm" name="id2548238"></a>
+<a class="indexterm" name="id2548245"></a>
+<a class="indexterm" name="id2548252"></a>
+<a class="indexterm" name="id2548259"></a>
+<a class="indexterm" name="id2548266"></a>
+<a class="indexterm" name="id2548273"></a>
+<a class="indexterm" name="id2548279"></a>
+<a class="indexterm" name="id2548286"></a>
+Where a WINS server is used, the DMB registers its IP address with the WINS server using the name of the
+domain and the NetBIOS name type 1B (e.g., DOMAIN<1B>). All LMBs register their IP addresses with the WINS
+server, also with the name of the domain and the NetBIOS name type of 1D. The 1B name is unique to one
+server within the domain security context, and only one 1D name is registered for each network segment.
+Machines that have registered the 1D name will be authoritive browse list maintainers for the network segment
+they are on. The DMB is responsible for synchronizing the browse lists it obtains from the LMBs.
+</p><p>
+<a class="indexterm" name="id2548322"></a>
+Clients wishing to browse the network make use of this list but also depend on the availability of correct
+name resolution to the respective IP address or addresses.
+</p><p>
+<a class="indexterm" name="id2548335"></a>
+Any configuration that breaks name resolution and/or browsing intrinsics will annoy users because they will
+have to put up with protracted inability to use the network services.
+</p><p>
+<a class="indexterm" name="id2548349"></a>
+<a class="indexterm" name="id2548356"></a>
+<a class="indexterm" name="id2548362"></a>
+<a class="indexterm" name="id2548369"></a>
+<a class="indexterm" name="id2548376"></a>
+<a class="indexterm" name="id2548383"></a>
+Samba supports a feature that allows forced synchronization of browse lists across routed networks using the
+<a class="indexterm" name="id2548392"></a>remote browse sync parameter in the <code class="filename">smb.conf</code> file. This causes Samba to contact the
+LMB on a remote network and to request browse list synchronization. This effectively bridges two networks that
+are separated by routers. The two remote networks may use either broadcast-based name resolution or WINS-based
+name resolution, but it should be noted that the <a class="indexterm" name="id2548410"></a>remote browse sync parameter provides
+browse list synchronization and that is distinct from name-to-address resolution. In other words,
+for cross-subnet browsing to function correctly, it is essential that a name-to-address resolution mechanism
+be provided. This mechanism could be via DNS, <code class="filename">/etc/hosts</code>, and so on.
+</p><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="DMB"></a>Configuring Workgroup Browsing</h3></div></div></div><p>
+<a class="indexterm" name="id2548443"></a>
+<a class="indexterm" name="id2548450"></a>
+<a class="indexterm" name="id2548457"></a>
+<a class="indexterm" name="id2548463"></a>
+<a class="indexterm" name="id2548470"></a>
+<a class="indexterm" name="id2548477"></a>
+To configure cross-subnet browsing on a network containing machines in a workgroup, not an NT domain, you need
+to set up one Samba server to be the DMB (note that this is not the same as a Primary Domain Controller,
+although in an NT domain the same machine plays both roles). The role of a DMB is to collate the browse lists
+from LMB on all the subnets that have a machine participating in the workgroup. Without one machine configured
+as a DMB, each subnet would be an isolated workgroup unable to see any machines on another subnet. It is the
+presence of a DMB that makes cross-subnet browsing possible for a workgroup.
+</p><p>
+<a class="indexterm" name="id2548497"></a>
+In a workgroup environment the DMB must be a Samba server, and there must only be one DMB per workgroup name.
+To set up a Samba server as a DMB, set the following option in the <em class="parameter"><code>[global]</code></em> section
+of the <code class="filename">smb.conf</code> file:
+</p><p>
+</p><table class="simplelist" border="0" summary="Simple list"><tr><td><a class="indexterm" name="id2548528"></a><em class="parameter"><code>domain master = yes</code></em></td></tr></table><p>
+</p><p>
+<a class="indexterm" name="id2548544"></a>
+<a class="indexterm" name="id2548550"></a>
+The DMB should preferably be the LMB for its own subnet. In order to achieve this, set the following options
+in the <em class="parameter"><code>[global]</code></em> section of the <code class="filename">smb.conf</code> file as shown in <a href="NetworkBrowsing.html#dmbexample" title="Example 9.1. Domain Master Browser smb.conf">Domain Master Browser smb.conf</a>
+</p><div class="example"><a name="dmbexample"></a><p class="title"><b>Example 9.1. Domain Master Browser smb.conf</b></p><table class="simplelist" border="0" summary="Simple list"><tr><td> </td></tr><tr><td><em class="parameter"><code>[global]</code></em></td></tr><tr><td><a class="indexterm" name="id2548605"></a><em class="parameter"><code>domain master = yes</code></em></td></tr><tr><td><a class="indexterm" name="id2548617"></a><em class="parameter"><code>local master = yes</code></em></td></tr><tr><td><a class="indexterm" name="id2548630"></a><em class="parameter"><code>preferred master = yes</code></em></td></tr><tr><td><a class="indexterm" name="id2548643"></a><em class="parameter"><code>os level = 65</code></em></td></tr></table></div><p>
+<a class="indexterm" name="id2548659"></a>
+<a class="indexterm" name="id2548666"></a>
+The DMB may be the same machine as the WINS server, if necessary.
+</p><p>
+<a class="indexterm" name="id2548677"></a>
+<a class="indexterm" name="id2548684"></a>
+<a class="indexterm" name="id2548690"></a>
+Next, you should ensure that each of the subnets contains a machine that can act as an LMB for the workgroup.
+Any MS Windows NT/200x/XP machine should be able to do this, as will Windows 9x/Me machines (although these
+tend to get rebooted more often, so it is not such a good idea to use them). To make a Samba server an LMB,
+set the following options in the <em class="parameter"><code>[global]</code></em> section of the <code class="filename">smb.conf</code> file as shown in
+<a href="NetworkBrowsing.html#lmbexample" title="Example 9.2. Local master browser smb.conf">Local master browser smb.conf</a>
+</p><div class="example"><a name="lmbexample"></a><p class="title"><b>Example 9.2. Local master browser smb.conf</b></p><table class="simplelist" border="0" summary="Simple list"><tr><td> </td></tr><tr><td><em class="parameter"><code>[global]</code></em></td></tr><tr><td><a class="indexterm" name="id2548748"></a><em class="parameter"><code>domain master = no</code></em></td></tr><tr><td><a class="indexterm" name="id2548761"></a><em class="parameter"><code>local master = yes</code></em></td></tr><tr><td><a class="indexterm" name="id2548773"></a><em class="parameter"><code>preferred master = yes</code></em></td></tr><tr><td><a class="indexterm" name="id2548786"></a><em class="parameter"><code>os level = 65</code></em></td></tr></table></div><p>
+<a class="indexterm" name="id2548802"></a>
+Do not do this for more than one Samba server on each subnet, or they will war with
+each other over which is to be the LMB.
+</p><p>
+<a class="indexterm" name="id2548814"></a>
+<a class="indexterm" name="id2548821"></a>
+The <a class="indexterm" name="id2548828"></a>local master parameter allows Samba to act as a
+LMB. The <a class="indexterm" name="id2548836"></a>preferred master causes <span><strong class="command">nmbd</strong></span>
+to force a browser election on startup and the <a class="indexterm" name="id2548850"></a>os level
+parameter sets Samba high enough so it should win any browser elections.
+</p><p>
+<a class="indexterm" name="id2548862"></a>
+If you have an NT machine on the subnet that you wish to be the LMB, you can disable Samba from
+becoming an LMB by setting the following options in the <em class="parameter"><code>[global]</code></em> section of the
+<code class="filename">smb.conf</code> file as shown in <a href="NetworkBrowsing.html#nombexample" title="Example 9.3. smb.conf for Not Being a Master Browser">smb.conf for Not Being a Master Browser</a>.
+</p><p>
+</p><div class="example"><a name="nombexample"></a><p class="title"><b>Example 9.3. smb.conf for Not Being a Master Browser</b></p><table class="simplelist" border="0" summary="Simple list"><tr><td> </td></tr><tr><td><em class="parameter"><code>[global]</code></em></td></tr><tr><td><a class="indexterm" name="id2548918"></a><em class="parameter"><code>domain master = no</code></em></td></tr><tr><td><a class="indexterm" name="id2548931"></a><em class="parameter"><code>local master = no</code></em></td></tr><tr><td><a class="indexterm" name="id2548943"></a><em class="parameter"><code>preferred master = no</code></em></td></tr><tr><td><a class="indexterm" name="id2548956"></a><em class="parameter"><code>os level = 0</code></em></td></tr></table></div><p>
+</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2548972"></a>Domain Browsing Configuration</h3></div></div></div><p>
+<a class="indexterm" name="id2548980"></a>
+<a class="indexterm" name="id2548987"></a>
+<a class="indexterm" name="id2548993"></a>
+<a class="indexterm" name="id2549000"></a>
+If you are adding Samba servers to a Windows NT domain, then you must not set up a Samba server as a DMB. By
+default, a Windows NT PDC for a domain is also the DMB for that domain. Network browsing may break if a Samba
+server other than the PDC registers the DMB NetBIOS name (<em class="replaceable"><code>DOMAIN</code></em><1B>) with
+WINS.
+</p><p>
+<a class="indexterm" name="id2549019"></a>
+For subnets other than the one containing the Windows NT PDC, you may set up Samba servers as LMBs as
+described. To make a Samba server a Local Master Browser, set the following options in the <em class="parameter"><code>[global]</code></em> section of the <code class="filename">smb.conf</code> file as shown in <a href="NetworkBrowsing.html#remsmb" title="Example 9.4. Local Master Browser smb.conf">Local Master Browser
+smb.conf</a>
+</p><div class="example"><a name="remsmb"></a><p class="title"><b>Example 9.4. Local Master Browser smb.conf</b></p><table class="simplelist" border="0" summary="Simple list"><tr><td> </td></tr><tr><td><em class="parameter"><code>[global]</code></em></td></tr><tr><td><a class="indexterm" name="id2549075"></a><em class="parameter"><code>domain master = no</code></em></td></tr><tr><td><a class="indexterm" name="id2549088"></a><em class="parameter"><code>local master = yes</code></em></td></tr><tr><td><a class="indexterm" name="id2549101"></a><em class="parameter"><code>preferred master = yes</code></em></td></tr><tr><td><a class="indexterm" name="id2549114"></a><em class="parameter"><code>os level = 65</code></em></td></tr></table></div><p>
+<a class="indexterm" name="id2549129"></a>
+<a class="indexterm" name="id2549136"></a>
+If you wish to have a Samba server fight the election with machines on the same subnet, you may set the
+<a class="indexterm" name="id2549145"></a>os level parameter to lower levels. By doing this you can tune the order of machines
+that will become LMBs if they are running. For more details on this, refer to <a href="NetworkBrowsing.html#browse-force-master" title="Forcing Samba to Be the Master">Forcing Samba to Be the Master</a>.
+</p><p>
+<a class="indexterm" name="id2549167"></a>
+<a class="indexterm" name="id2549173"></a>
+<a class="indexterm" name="id2549180"></a>
+If you have Windows NT machines that are members of the domain on all subnets and you are sure they will
+always be running, you can disable Samba from taking part in browser elections and ever becoming an LMB by
+setting the following options in the <em class="parameter"><code>[global]</code></em> section of the <code class="filename">smb.conf</code> file as shown
+in <a href="NetworkBrowsing.html#xremmb" title="Example 9.5. smb.conf for Not Being a master browser"><code class="filename">smb.conf</code> for Not Being a master browser</a>
+</p><p>
+</p><div class="example"><a name="xremmb"></a><p class="title"><b>Example 9.5. <code class="filename">smb.conf</code> for Not Being a master browser</b></p><em class="parameter"><code>[global]</code></em><a class="indexterm" name="id2549239"></a>domain master = no
+<a class="indexterm" name="id2549246"></a>local master = no
+<a class="indexterm" name="id2549253"></a>preferred master = no
+<a class="indexterm" name="id2549261"></a>os level = 0
+</div><p>
+</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="browse-force-master"></a>Forcing Samba to Be the Master</h3></div></div></div><p>
+<a class="indexterm" name="id2549283"></a>
+<a class="indexterm" name="id2549290"></a>
+<a class="indexterm" name="id2549296"></a>
+<a class="indexterm" name="id2549303"></a>
+<a class="indexterm" name="id2549310"></a>
+<a class="indexterm" name="id2549317"></a>
+<a class="indexterm" name="id2549324"></a>
+Who becomes the master browser is determined by an election process using broadcasts. Each election packet
+contains a number of parameters that determine what precedence (bias) a host should have in the election. By
+default Samba uses a low precedence and thus loses elections to just about every Windows network server or
+client.
+</p><p>
+If you want Samba to win elections, set the <a class="indexterm" name="id2549340"></a>os level global option in <code class="filename">smb.conf</code> to a
+higher number. It defaults to 20. Using 34 would make it win all elections over every other system (except
+other Samba systems).
+</p><p>
+An <a class="indexterm" name="id2549359"></a>os level of two would make it beat Windows for Workgroups and Windows 9x/Me, but
+not MS Windows NT/200x Server. An MS Windows NT/200x Server domain controller uses level 32. The maximum os
+level is 255.
+</p><p>
+<a class="indexterm" name="id2549373"></a>
+<a class="indexterm" name="id2549380"></a>
+<a class="indexterm" name="id2549387"></a>
+<a class="indexterm" name="id2549394"></a>
+If you want Samba to force an election on startup, set the <a class="indexterm" name="id2549402"></a>preferred master global
+option in <code class="filename">smb.conf</code> to <code class="constant">yes</code>. Samba will then have a slight advantage over other
+potential master browsers that are not preferred master browsers. Use this parameter with care, because if
+you have two hosts (whether they are Windows 9x/Me or NT/200x/XP or Samba) on the same local subnet both set
+with <a class="indexterm" name="id2549423"></a>preferred master to <code class="constant">yes</code>, then periodically and continually
+they will force an election in order to become the LMB.
+</p><p>
+<a class="indexterm" name="id2549439"></a>
+<a class="indexterm" name="id2549445"></a>
+<a class="indexterm" name="id2549452"></a>
+<a class="indexterm" name="id2549459"></a>
+<a class="indexterm" name="id2549465"></a>
+If you want Samba to be a <span class="emphasis"><em>DMB</em></span>, then it is recommended that you also set <a class="indexterm" name="id2549477"></a>preferred master to <code class="constant">yes</code>, because Samba will not become a DMB for the whole of
+your LAN or WAN if it is not also a LMB on its own broadcast isolated subnet.
+</p><p>
+<a class="indexterm" name="id2549493"></a>
+<a class="indexterm" name="id2549500"></a>
+<a class="indexterm" name="id2549507"></a>
+<a class="indexterm" name="id2549513"></a>
+<a class="indexterm" name="id2549520"></a>
+It is possible to configure two Samba servers to attempt to become the DMB for a domain. The first server that
+comes up will be the DMB. All other Samba servers will attempt to become the DMB every 5 minutes. They will
+find that another Samba server is already the DMB and will fail. This provides automatic redundancy should the
+current DMB fail. The network bandwidth overhead of browser elections is relatively small, requiring
+approximately four UDP packets per machine per election. The maximum size of a UDP packet is 576 bytes.
+</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2549538"></a>Making Samba the Domain Master</h3></div></div></div><p>
+<a class="indexterm" name="id2549546"></a>
+<a class="indexterm" name="id2549553"></a>
+<a class="indexterm" name="id2549560"></a>
+<a class="indexterm" name="id2549567"></a>
+The domain master browser is responsible for collating the browse lists of multiple subnets so browsing can
+occur between subnets. You can make Samba act as the domain master browser by setting <a class="indexterm" name="id2549577"></a>domain master = yes in <code class="filename">smb.conf</code>. By default it will not be a domain master browser.
+</p><p>
+<a class="indexterm" name="id2549594"></a>
+<a class="indexterm" name="id2549601"></a>
+Do not set Samba to be the domain master for a workgroup that has the same name as an NT/200x domain. If
+Samba is configured to be the domain master for a workgroup that is present on the same network as a Windows
+NT/200x domain that has the same name, network browsing problems will certainly be experienced.
+</p><p>
+When Samba is the domain master and the master browser, it will listen for master announcements (made roughly
+every 12 minutes) from LMBs on other subnets and then contact them to synchronize browse lists.
+</p><p>
+<a class="indexterm" name="id2549624"></a>
+<a class="indexterm" name="id2549630"></a>
+If you want Samba to be the domain master, you should also set the <a class="indexterm" name="id2549639"></a>os level high
+enough to make sure it wins elections, and set <a class="indexterm" name="id2549647"></a>preferred master to
+<code class="constant">yes</code>, to get Samba to force an election on startup.
+</p><p>
+<a class="indexterm" name="id2549662"></a>
+<a class="indexterm" name="id2549668"></a>
+All servers (including Samba) and clients should be using a WINS server to resolve NetBIOS names. If your
+clients are only using broadcasting to resolve NetBIOS names, then two things will occur:
+</p><div class="orderedlist"><ol type="1"><li><p>
+<a class="indexterm" name="id2549691"></a>
+<a class="indexterm" name="id2549697"></a>
+ LMBs will be unable to find a DMB because they will be looking only on the local subnet.
+ </p></li><li><p>
+<a class="indexterm" name="id2549712"></a>
+ If a client happens to get hold of a domain-wide browse list and a user attempts to access a
+ host in that list, it will be unable to resolve the NetBIOS name of that host.
+ </p></li></ol></div><p>
+<a class="indexterm" name="id2549728"></a>
+If, however, both Samba and your clients are using a WINS server, then:
+</p><div class="orderedlist"><ol type="1"><li><p>
+ LMBs will contact the WINS server and, as long as Samba has registered that it is a DMB with the WINS
+ server, the LMB will receive Samba's IP address as its DMB.
+ </p></li><li><p>
+ When a client receives a domain-wide browse list and a user attempts to access a host in that list, it will
+ contact the WINS server to resolve the NetBIOS name of that host. As long as that host has registered its
+ NetBIOS name with the same WINS server, the user will be able to see that host..
+ </p></li></ol></div></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2549766"></a>Note about Broadcast Addresses</h3></div></div></div><p>
+<a class="indexterm" name="id2549775"></a>
+If your network uses a zero-based broadcast address (for example, if it ends in a 0), then you will strike problems. Windows for Workgroups
+does not seem to support a zeros broadcast, and you will probably find that browsing and name lookups will not work.
+</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2549788"></a>Multiple Interfaces</h3></div></div></div><p>
+<a class="indexterm" name="id2549796"></a>
+Samba supports machines with multiple network interfaces. If you have multiple interfaces, you will
+need to use the <a class="indexterm" name="id2549805"></a>interfaces option in <code class="filename">smb.conf</code> to configure them. For example, the
+machine you are working with has 4 network interfaces; <code class="literal">eth0</code>, <code class="literal">eth1</code>,
+<code class="literal">eth2</code>, <code class="literal">eth3</code> and only interfaces <code class="literal">eth1</code> and
+<code class="literal">eth4</code> should be used by Samba. In this case, the following <code class="filename">smb.conf</code> file entries would
+permit that intent:
+</p><table class="simplelist" border="0" summary="Simple list"><tr><td><a class="indexterm" name="id2549868"></a><em class="parameter"><code>interfaces = eth1, eth4</code></em></td></tr><tr><td><a class="indexterm" name="id2549881"></a><em class="parameter"><code>bind interfaces only = Yes</code></em></td></tr></table><p>
+<a class="indexterm" name="id2549894"></a>
+<a class="indexterm" name="id2549901"></a>
+<a class="indexterm" name="id2549908"></a>
+<a class="indexterm" name="id2549915"></a>
+<a class="indexterm" name="id2549921"></a>
+<a class="indexterm" name="id2549928"></a>
+<a class="indexterm" name="id2549935"></a>
+The <a class="indexterm" name="id2549942"></a>bind interfaces only = Yes is necessary to exclude TCP/IP session
+services (ports 135, 139, and 445) over the interfaces that are not specified. Please be aware that
+<span><strong class="command">nmbd</strong></span> will listen for incoming UDP port 137 packets on the unlisted interfaces, but it will
+not answer them. It will, however, send its broadcast packets over the unlisted interfaces. Total isolation of
+ethernet interface requires the use of a firewall to block ports 137 and 138 (UDP), and ports 135, 139, and
+445 (TCP) on all network interfaces that must not be able to access the Samba server.
+</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2549966"></a>Use of the Remote Announce Parameter</h3></div></div></div><p>
+The <a class="indexterm" name="id2549975"></a>remote announce parameter of
+<code class="filename">smb.conf</code> can be used to forcibly ensure
+that all the NetBIOS names on a network get announced to a remote network.
+The syntax of the <a class="indexterm" name="id2549990"></a>remote announce parameter is:
+</p><table class="simplelist" border="0" summary="Simple list"><tr><td><a class="indexterm" name="id2550003"></a><em class="parameter"><code>remote announce = 192.168.12.23 [172.16.21.255] ...</code></em></td></tr></table><p>
+<span class="emphasis"><em>or</em></span>
+</p><table class="simplelist" border="0" summary="Simple list"><tr><td><a class="indexterm" name="id2550025"></a><em class="parameter"><code>remote announce = 192.168.12.23/MIDEARTH [172.16.21.255/ELVINDORF] ...</code></em></td></tr></table><p>
+
+where:
+</p><div class="variablelist"><dl><dt><span class="term"><em class="replaceable"><code>192.168.12.23</code></em> and <em class="replaceable"><code>172.16.21.255</code></em></span></dt><dd><p>
+<a class="indexterm" name="id2550054"></a>
+<a class="indexterm" name="id2550063"></a>
+ is either the LMB IP address or the broadcast address of the remote network.
+ That is, the LMB is at 192.168.1.23, or the address could be given as 172.16.21.255 where the netmask
+ is assumed to be 24 bits (255.255.255.0). When the remote announcement is made to the broadcast
+ address of the remote network, every host will receive our announcements. This is noisy and therefore
+ undesirable but may be necessary if we do not know the IP address of the remote LMB.
+ </p></dd><dt><span class="term"><em class="replaceable"><code>WORKGROUP</code></em></span></dt><dd><p>is optional and can be either our own workgroup or that of the remote network. If you use the
+ workgroup name of the remote network, our NetBIOS machine names will end up looking like
+ they belong to that workgroup. This may cause name resolution problems and should be avoided.
+ </p></dd></dl></div><p>
+</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2550101"></a>Use of the Remote Browse Sync Parameter</h3></div></div></div><p>
+<a class="indexterm" name="id2550109"></a>
+<a class="indexterm" name="id2550115"></a>
+The <a class="indexterm" name="id2550122"></a>remote browse sync parameter of <code class="filename">smb.conf</code> is used to announce to another LMB that
+it must synchronize its NetBIOS name list with our Samba LMB. This works only if the Samba server that has
+this option is simultaneously the LMB on its network segment.
+</p><p>
+The syntax of the <a class="indexterm" name="id2550143"></a>remote browse sync parameter is:
+
+</p><table class="simplelist" border="0" summary="Simple list"><tr><td><a class="indexterm" name="id2550156"></a><em class="parameter"><code>remote browse sync</code></em></td></tr></table><p>
+<a class="indexterm" name="id2550169"></a>
+<a class="indexterm" name="id2550175"></a>
+where <em class="replaceable"><code>192.168.10.40</code></em> is either the IP address of the
+remote LMB or the network broadcast address of the remote segment.
+</p></div></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2550191"></a>WINS: The Windows Internetworking Name Server</h2></div></div></div><p>
+<a class="indexterm" name="id2550200"></a>
+<a class="indexterm" name="id2550206"></a>
+<a class="indexterm" name="id2550213"></a>
+Use of WINS (either Samba WINS or MS Windows NT Server WINS) is highly
+recommended. Every NetBIOS machine registers its name together with a
+name_type value for each of several types of service it has available.
+It registers its name directly as a unique (the type 0x03) name.
+It also registers its name if it is running the LanManager-compatible
+server service (used to make shares and printers available to other users)
+by registering the server (the type 0x20) name.
+</p><p>
+<a class="indexterm" name="id2550232"></a>
+<a class="indexterm" name="id2550238"></a>
+All NetBIOS names are up to 15 characters in length. The name_type variable
+is added to the end of the name, thus creating a 16 character name. Any
+name that is shorter than 15 characters is padded with spaces to the 15th
+character. Thus, all NetBIOS names are 16 characters long (including the
+name_type information).
+</p><p>
+<a class="indexterm" name="id2550254"></a>
+<a class="indexterm" name="id2550261"></a>
+<a class="indexterm" name="id2550268"></a>
+<a class="indexterm" name="id2550274"></a>
+WINS can store these 16-character names as they get registered. A client
+that wants to log onto the network can ask the WINS server for a list
+of all names that have registered the NetLogon service name_type. This saves
+broadcast traffic and greatly expedites logon processing. Since broadcast
+name resolution cannot be used across network segments, this type of
+information can only be provided via WINS or via a statically configured
+<code class="filename">lmhosts</code> file that must reside on all clients in the
+absence of WINS.
+</p><p>
+<a class="indexterm" name="id2550299"></a>
+<a class="indexterm" name="id2550306"></a>
+<a class="indexterm" name="id2550312"></a>
+<a class="indexterm" name="id2550319"></a>
+<a class="indexterm" name="id2550326"></a>
+WINS also forces browse list synchronization by all LMBs. LMBs must synchronize their browse list with the
+DMB, and WINS helps the LMB to identify its DMB. By definition this will work only within a single workgroup.
+Note that the DMB has nothing to do with what is referred to as an MS Windows NT domain. The latter is a
+reference to a security environment, while the DMB refers to the master controller for browse list information
+only.
+</p><p>
+<a class="indexterm" name="id2550343"></a>
+<a class="indexterm" name="id2550350"></a>
+<a class="indexterm" name="id2550357"></a>
+<a class="indexterm" name="id2550364"></a>
+WINS will work correctly only if every client TCP/IP protocol stack
+is configured to use the WINS servers. Any client that is not
+configured to use the WINS server will continue to use only broadcast-based
+name registration, so WINS may never get to know about it. In any case,
+machines that have not registered with a WINS server will fail name-to-address
+lookup attempts by other clients and will therefore cause workstation access
+errors.
+</p><p>
+To configure Samba as a WINS server, just add
+<a class="indexterm" name="id2550382"></a>wins support = yes to the <code class="filename">smb.conf</code>
+file [global] section.
+</p><p>
+To configure Samba to register with a WINS server, just add <a class="indexterm" name="id2550401"></a>wins server = 10.0.0.18 to your <code class="filename">smb.conf</code> file <em class="parameter"><code>[global]</code></em> section.
+</p><div class="important" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Important</h3><p>
+Never use <a class="indexterm" name="id2550425"></a>wins support = yes together with <a class="indexterm" name="id2550432"></a>wins server = 10.0.0.18 particularly not using its own IP address. Specifying both will cause <span class="application">nmbd</span>
+to refuse to start!
+</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2550448"></a>WINS Server Configuration</h3></div></div></div><p>
+<a class="indexterm" name="id2550456"></a>
+Either a Samba server or a Windows NT server machine may be set up
+as a WINS server. To configure a Samba server to be a WINS server, you must
+add to the <code class="filename">smb.conf</code> file on the selected Server the following line to
+the <em class="parameter"><code>[global]</code></em> section:
+</p><p>
+</p><table class="simplelist" border="0" summary="Simple list"><tr><td><a class="indexterm" name="id2550487"></a><em class="parameter"><code>wins support = yes</code></em></td></tr></table><p>
+</p><p>
+<a class="indexterm" name="id2550503"></a>
+Versions of Samba prior to 1.9.17 had this parameter default to
+yes. If you have any older versions of Samba on your network, it is
+strongly suggested you upgrade to a recent version, or at the very
+least set the parameter to “<span class="quote">no</span>” on all these machines.
+</p><p>
+Machines configured with <a class="indexterm" name="id2550521"></a>wins support = yes will keep a list of
+all NetBIOS names registered with them, acting as a DNS for NetBIOS names.
+</p><p>
+<a class="indexterm" name="id2550533"></a>
+It is strongly recommended to set up only one WINS server. Do not set the
+<a class="indexterm" name="id2550542"></a>wins support = yes option on more than one Samba
+server on a network.
+</p><p>
+<a class="indexterm" name="id2550553"></a>
+<a class="indexterm" name="id2550562"></a>
+<a class="indexterm" name="id2550569"></a>
+<a class="indexterm" name="id2550576"></a>
+<a class="indexterm" name="id2550583"></a>
+To configure Windows NT/200x Server as a WINS server, install and configure the WINS service. See the Windows
+NT/200x documentation for details. Windows NT/200x WINS servers can replicate to each other, allowing more
+than one to be set up in a complex subnet environment. Because Microsoft refuses to document the replication
+protocols, Samba cannot currently participate in these replications. It is possible that a Samba-to-Samba WINS
+replication protocol may be defined in the future, in which case more than one Samba machine could be set up
+as a WINS server. Currently only one Samba server should have the <a class="indexterm" name="id2550601"></a>wins support = yes parameter set.
+</p><p>
+<a class="indexterm" name="id2550611"></a>
+<a class="indexterm" name="id2550618"></a>
+After the WINS server has been configured, you must ensure that all machines participating on the network are
+configured with the address of this WINS server. If your WINS server is a Samba machine, fill in the Samba
+machine IP address in the <span class="guilabel">Primary WINS Server</span> field of the <span class="guilabel">Control
+Panel->Network->Protocols->TCP->WINS Server</span> dialogs in Windows 9x/Me or Windows NT/200x. To tell a
+Samba server the IP address of the WINS server, add the following line to the <em class="parameter"><code>[global]</code></em> section of all <code class="filename">smb.conf</code> files:
+</p><table class="simplelist" border="0" summary="Simple list"><tr><td><a class="indexterm" name="id2550663"></a><em class="parameter"><code>wins server = <name or IP address></code></em></td></tr></table><p>
+where <name or IP address> is either the DNS name of the WINS server
+machine or its IP address.
+</p><p>
+This line must not be set in the <code class="filename">smb.conf</code> file of the Samba
+server acting as the WINS server itself. If you set both the
+<a class="indexterm" name="id2550692"></a>wins support = yes option and the
+<a class="indexterm" name="id2550700"></a>wins server = <name> option then
+<span><strong class="command">nmbd</strong></span> will fail to start.
+</p><p>
+<a class="indexterm" name="id2550718"></a>
+<a class="indexterm" name="id2550725"></a>
+<a class="indexterm" name="id2550732"></a>
+<a class="indexterm" name="id2550739"></a>
+There are two possible scenarios for setting up cross-subnet browsing.
+The first details setting up cross-subnet browsing on a network containing
+Windows 9x/Me, Samba, and Windows NT/200x machines that are not configured as
+part of a Windows NT domain. The second details setting up cross-subnet
+browsing on networks that contain NT domains.
+</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2550754"></a>WINS Replication</h3></div></div></div><p>
+<a class="indexterm" name="id2550762"></a>
+<a class="indexterm" name="id2550771"></a>
+Samba-3 permits WINS replication through the use of the <code class="filename">wrepld</code> utility. This tool is not
+currently in use because it is still in development and has not been worked on for a long time. As soon as
+this tool becomes moderately functional, we will prepare man pages and enhance this section of the
+documentation to provide usage and technical details.
+</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2550792"></a>Static WINS Entries</h3></div></div></div><p>
+<a class="indexterm" name="id2550800"></a>
+<a class="indexterm" name="id2550806"></a>
+<a class="indexterm" name="id2550813"></a>
+<a class="indexterm" name="id2550820"></a>
+Adding static entries to your Samba WINS server is actually fairly easy. All you have to do is add a line to
+<code class="filename">wins.dat</code>, typically located in <code class="filename">/usr/local/samba/var/locks</code> or <code class="filename">/var/run/samba</code>.
+</p><p>
+Entries in <code class="filename">wins.dat</code> take the form of:
+</p><pre class="programlisting">
+"NAME#TYPE" TTL ADDRESS+ FLAGS
+</pre><p>
+<a class="indexterm" name="id2550866"></a>
+<a class="indexterm" name="id2550872"></a>
+where NAME is the NetBIOS name, TYPE is the NetBIOS type, TTL is the time-to-live as an absolute time in
+seconds, ADDRESS+ is one or more addresses corresponding to the registration, and FLAGS are the NetBIOS flags
+for the registration.
+</p><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>
+A change that has been made to the <code class="filename">wins.dat</code> will not take effect until <span class="application">nmbd</span> has been
+restarted. It should be noted that since the <code class="filename">wins.dat</code> file changes dynamically, <span class="application">nmbd</span>
+should be stopped before editting this file. Do not forget to restart <span class="application">nmbd</span> when this file has been editted.
+</p></div><p>
+A typical dynamic entry looks like this:
+</p><pre class="programlisting">
+"MADMAN#03" 1155298378 192.168.1.2 66R
+</pre><p>
+To make a NetBIOS name static (permanent), simply set the TTL to 0, like this:
+</p><pre class="programlisting">
+"MADMAN#03" 0 192.168.1.2 66R
+</pre><p>
+</p><p>
+<a class="indexterm" name="id2550945"></a>
+<a class="indexterm" name="id2550952"></a>
+<a class="indexterm" name="id2550959"></a>
+<a class="indexterm" name="id2550966"></a>
+<a class="indexterm" name="id2550972"></a>
+<a class="indexterm" name="id2550979"></a>
+<a class="indexterm" name="id2550986"></a>
+The NetBIOS flags may be interpreted as additive hexadecimal values: 00 - Broadcast node registration, 20 -
+Peer node registration, 40 - Meta node registration, 60 - Hybrid node registration, 02 - Permanent name, 04 -
+Active name, 80 - Group name. The 'R' indicates this is a registration record. Thus 66R means: Hybrid node
+active and permanent NetBIOS name. These values may be found in the <code class="filename">nameserv.h</code> header
+file from the Samba source code repository. These are the values for the NB flags.
+</p><p>
+<a class="indexterm" name="id2551010"></a>
+Though this method works with early Samba-3 versions, there is a possibility that it may change in future
+versions if WINS replication is added.
+</p></div></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2551023"></a>Helpful Hints</h2></div></div></div><p>
+The following hints should be carefully considered because they are stumbling points
+for many new network administrators.
+</p><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2551034"></a>Windows Networking Protocols</h3></div></div></div><p>
+<a class="indexterm" name="id2551042"></a>
+<a class="indexterm" name="id2551049"></a>
+A common cause of browsing problems results from the installation of more than one protocol on an MS Windows
+machine.
+</p><div class="warning" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Warning</h3><p>
+Do not use more than one protocol on MS Windows clients.
+</p></div><p>
+<a class="indexterm" name="id2551067"></a>
+<a class="indexterm" name="id2551073"></a>
+Every NetBIOS machine takes part in a process of electing the LMB (and DMB)
+every 15 minutes. A set of election criteria is used to determine the order
+of precedence for winning this election process. A machine running Samba or
+Windows NT will be biased, so the most suitable machine will predictably
+win and thus retain its role.
+</p><p>
+<a class="indexterm" name="id2551089"></a>
+<a class="indexterm" name="id2551096"></a>
+<a class="indexterm" name="id2551103"></a>
+<a class="indexterm" name="id2551109"></a>
+<a class="indexterm" name="id2551116"></a>
+<a class="indexterm" name="id2551123"></a>
+The election process is <span class="emphasis"><em>fought out, so to speak</em></span> over every NetBIOS network interface. In
+the case of a Windows 9x/Me machine that has both TCP/IP and IPX installed and has NetBIOS enabled over both
+protocols, the election will be decided over both protocols. As often happens, if the Windows 9x/Me machine is
+the only one with both protocols, then the LMB may be won on the NetBIOS interface over the IPX protocol.
+Samba will then lose the LMB role because Windows 9x/Me will insist it knows who the LMB is. Samba will then
+cease to function as an LMB, and browse list operation on all TCP/IP-only machines will therefore fail.
+</p><p>
+<a class="indexterm" name="id2551156"></a>
+<a class="indexterm" name="id2551163"></a>
+Windows 95, 98, 98se, and Me are referred to generically as Windows 9x/Me.
+The Windows NT4, 200x, and XP use common protocols. These are roughly
+referred to as the Windows NT family, but it should be recognized that 2000 and
+XP/2003 introduce new protocol extensions that cause them to behave
+differently from MS Windows NT4. Generally, where a server does not support
+the newer or extended protocol, these will fall back to the NT4 protocols.
+</p><p>
+The safest rule of all to follow is: Use only one protocol!
+</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2551184"></a>Name Resolution Order</h3></div></div></div><p>
+<a class="indexterm" name="id2551192"></a>
+<a class="indexterm" name="id2551199"></a>
+Resolution of NetBIOS names to IP addresses can take place using a number
+of methods. The only ones that can provide NetBIOS name_type information
+are:
+</p><div class="itemizedlist"><ul type="disc"><li><p>WINS the best tool.</p></li><li><p>LMHOSTS static and hard to maintain.</p></li><li><p>Broadcast uses UDP and cannot resolve names across remote segments.</p></li></ul></div><p>
+Alternative means of name resolution include:
+</p><div class="itemizedlist"><ul type="disc"><li><p>Static <code class="filename">/etc/hosts</code> hard to maintain and lacks name_type info.</p></li><li><p>DNS is a good choice but lacks essential NetBIOS name_type information.</p></li></ul></div><p>
+<a class="indexterm" name="id2551268"></a>
+<a class="indexterm" name="id2551274"></a>
+Many sites want to restrict DNS lookups and avoid broadcast name
+resolution traffic. The <em class="parameter"><code>name resolve order</code></em> parameter is of great help here.
+The syntax of the <em class="parameter"><code>name resolve order</code></em> parameter is:
+</p><table class="simplelist" border="0" summary="Simple list"><tr><td><a class="indexterm" name="id2551302"></a><em class="parameter"><code>name resolve order = wins lmhosts bcast host</code></em></td></tr></table><p>
+<span class="emphasis"><em>or</em></span>
+</p><table class="simplelist" border="0" summary="Simple list"><tr><td><a class="indexterm" name="id2551324"></a><em class="parameter"><code>name resolve order = wins lmhosts (eliminates bcast and host)</code></em></td></tr></table><p>
+The default is:
+</p><table class="simplelist" border="0" summary="Simple list"><tr><td><a class="indexterm" name="id2551343"></a><em class="parameter"><code>name resolve order = host lmhost wins bcast</code></em></td></tr></table><p>
+<a class="indexterm" name="id2551356"></a>
+where “<span class="quote">host</span>” refers to the native methods used by the UNIX system to implement the
+gethostbyname() function call. This is normally controlled by <code class="filename">/etc/host.conf</code>,
+<code class="filename">/etc/nsswitch.conf</code> and <code class="filename">/etc/resolv.conf</code>.
+</p></div></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2551391"></a>Technical Overview of Browsing</h2></div></div></div><p>
+<a class="indexterm" name="id2551399"></a>
+SMB networking provides a mechanism by which clients can access a list
+of machines in a network called <a class="indexterm" name="id2551407"></a>browse list. This list
+contains machines that are ready to offer file and/or print services
+to other machines within the network. It therefore 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.
+</p><p>
+<a class="indexterm" name="id2551423"></a>
+<a class="indexterm" name="id2551430"></a>
+<a class="indexterm" name="id2551437"></a>
+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.
+</p><p>
+<a class="indexterm" name="id2551454"></a>
+<a class="indexterm" name="id2551460"></a>
+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.
+</p><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2551473"></a>Browsing Support in Samba</h3></div></div></div><p>
+<a class="indexterm" name="id2551481"></a>
+<a class="indexterm" name="id2551488"></a>
+<a class="indexterm" name="id2551494"></a>
+<a class="indexterm" name="id2551501"></a>
+Samba facilitates browsing. The browsing is supported by <span class="application">nmbd</span>
+and is also controlled by options in the <code class="filename">smb.conf</code> file.
+Samba can act as an LMB for a workgroup, and the ability
+to support domain logons and scripts is now available.
+</p><p>
+<a class="indexterm" name="id2551527"></a>
+<a class="indexterm" name="id2551534"></a>
+<a class="indexterm" name="id2551540"></a>
+Samba can also act as a DMB for a workgroup. This
+means that it will collate lists from LMBs 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.
+</p><p>
+<a class="indexterm" name="id2551555"></a>
+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
+DMB per workgroup, regardless of whether it is NT, Samba,
+or any other type of domain master that is providing this service.
+</p><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>
+<a class="indexterm" name="id2551571"></a>
+<a class="indexterm" name="id2551578"></a>
+<span><strong class="command">nmbd</strong></span> 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 WAN, 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.
+</p></div><p>
+<a class="indexterm" name="id2551601"></a>
+To get browsing to work, you need to run <span><strong class="command">nmbd</strong></span> as usual, but must
+use the <a class="indexterm" name="id2551615"></a>workgroup option in <code class="filename">smb.conf</code>
+to control what workgroup Samba becomes a part of.
+</p><p>
+<a class="indexterm" name="id2551632"></a>
+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
+used only for “<span class="quote">unusual</span>” purposes: announcements over the Internet, for
+example. See <a class="indexterm" name="id2551647"></a>remote announce in the
+<code class="filename">smb.conf</code> man page.
+</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2551662"></a>Problem Resolution</h3></div></div></div><p>
+<a class="indexterm" name="id2551670"></a>
+<a class="indexterm" name="id2551677"></a>
+If something does not work, the <code class="filename">log.nmbd</code> file will help
+to track down the problem. Try a <a class="indexterm" name="id2551691"></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 <code class="filename">browse.dat</code>.
+</p><p>
+<a class="indexterm" name="id2551709"></a>
+<a class="indexterm" name="id2551716"></a>
+If it does not work, you should still be able to
+type the server name as <code class="filename">\\SERVER</code> in <span><strong class="command">filemanager</strong></span>, then
+press enter, and <span><strong class="command">filemanager</strong></span> should display the list of available shares.
+</p><p>
+<a class="indexterm" name="id2551746"></a>
+<a class="indexterm" name="id2551753"></a>
+Some people find browsing fails because they do not have the global
+<a class="indexterm" name="id2551761"></a>guest account set to a valid account. Remember that the
+IPC$ connection that lists the shares is done as guest and so you must have a valid guest account.
+</p><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>
+<a class="indexterm" name="id2551775"></a>
+<a class="indexterm" name="id2551782"></a>
+<a class="indexterm" name="id2551789"></a>
+<a class="indexterm" name="id2551796"></a>
+<a class="indexterm" name="id2551803"></a>
+The <code class="literal">IPC$</code> share is used by all SMB/CIFS clients to obtain the list of resources
+that is available on the server. This is the source of the list of shares and printers when browsing
+an SMB/CIFS server (also Windows machines) using the Windows Explorer to browse resources through
+the Windows Network Neighborhood (also called My Network Places) through to a Windows server. At
+this point, the client has opened a connection to the <code class="literal">\\server\IPC4</code> resource.
+Clicking on a share will then open up a connection to the <code class="literal">\\server\share</code>.
+</p></div><p>
+<a class="indexterm" name="id2551839"></a>
+<a class="indexterm" name="id2551846"></a>
+<a class="indexterm" name="id2551853"></a>
+<a class="indexterm" name="id2551860"></a>
+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.
+</p><p>
+<a class="indexterm" name="id2551877"></a>
+The other big problem people have is that their broadcast address,
+netmask, or IP address is wrong (specified with the <a class="indexterm" name="id2551886"></a>interfaces option
+in <code class="filename">smb.conf</code>)
+</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2551901"></a>Cross-Subnet Browsing</h3></div></div></div><p>
+<a class="indexterm" name="id2551909"></a>
+<a class="indexterm" name="id2551918"></a>
+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.
+</p><p>
+<a class="indexterm" name="id2551932"></a>
+<a class="indexterm" name="id2551939"></a>
+<a class="indexterm" name="id2551946"></a>
+<a class="indexterm" name="id2551953"></a>
+<a class="indexterm" name="id2551959"></a>
+<a class="indexterm" name="id2551966"></a>
+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. The Samba hacks, <em class="parameter"><code>remote browse sync</code></em>, and <em class="parameter"><code>remote
+announce</code></em> are designed to get around the natural limitations that prevent UDP broadcast
+propagation. The hacks are not a universal solution and they should not be used in place of WINS, they are
+considered last resort methods.
+</p><p>
+<a class="indexterm" name="id2552004"></a>
+<a class="indexterm" name="id2552011"></a>
+<a class="indexterm" name="id2552018"></a>
+<a class="indexterm" name="id2552025"></a>
+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 <code class="filename">smb.conf</code> file.
+</p><p>
+<a class="indexterm" name="id2552047"></a>
+<a class="indexterm" name="id2552054"></a>
+<a class="indexterm" name="id2552060"></a>
+It is possible to operate Samba-3 without NetBIOS over TCP/IP. If you do this, be warned that if used outside
+of MS ADS, this will forgo network browsing support. ADS permits network browsing support through DNS,
+providing appropriate DNS records are inserted for all Samba servers.
+</p><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2552073"></a>Behavior of Cross-Subnet Browsing</h4></div></div></div><p>
+<a class="indexterm" name="id2552081"></a>
+<a class="indexterm" name="id2552088"></a>
+Cross-subnet browsing is a complicated dance, containing multiple moving parts. It has taken Microsoft several
+years to get the code that correctly achieves this, and Samba lags behind in some areas. Samba is capable of
+cross-subnet browsing when configured correctly.
+</p><p>
+Consider a network set up as in <a href="NetworkBrowsing.html#browsing1" title="Figure 9.1. Cross-Subnet Browsing Example.">Cross-Subnet Browsing Example</a>.
+</p><div class="figure"><a name="browsing1"></a><p class="title"><b>Figure 9.1. Cross-Subnet Browsing Example.</b></p><div class="mediaobject"><img src="images/browsing1.png" width="216" alt="Cross-Subnet Browsing Example."></div></div><p>
+<a class="indexterm" name="id2552156"></a>
+<a class="indexterm" name="id2552162"></a>
+<a class="indexterm" name="id2552169"></a>
+This consists of three 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, and 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 the DMB (i.e., it will collate the browse lists for the workgroup). Machine N2_D is
+configured as a WINS server, and all the other machines are configured to register their NetBIOS names with
+it.
+</p><p>
+<a class="indexterm" name="id2552188"></a>
+<a class="indexterm" name="id2552195"></a>
+<a class="indexterm" name="id2552202"></a>
+As these machines are booted up, elections for master browsers
+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 LMBs for
+their particular subnet. N1_C has an advantage in winning as the
+LMB on subnet 1 because it is set up as DMB.
+</p><p>
+<a class="indexterm" name="id2552217"></a>
+<a class="indexterm" name="id2552224"></a>
+On each of the three networks, machines that are configured to
+offer sharing services will broadcast that they are offering
+these services. The LMB 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.
+</p><p>
+<a class="indexterm" name="id2552241"></a>
+<a class="indexterm" name="id2552248"></a>
+<a class="indexterm" name="id2552255"></a>
+<a class="indexterm" name="id2552261"></a>
+<a class="indexterm" name="id2552268"></a>
+For each network, the LMB on that network is
+considered <span class="emphasis"><em>authoritative</em></span> for all the names it receives via
+local broadcast. This is because a machine seen by the LMB
+via a local broadcast must be on the same network as the
+Local Master Browser and thus is a <span class="emphasis"><em>trusted</em></span>
+and <span class="emphasis"><em>verifiable</em></span> resource. Machines on other networks that
+the LMBs learn about when collating their
+browse lists have not been directly seen. These records are
+called <span class="emphasis"><em>non-authoritative.</em></span>
+</p><p>
+<a class="indexterm" name="id2552300"></a>
+At this point the browse lists appear as shown in <a href="NetworkBrowsing.html#browsubnet" title="Table 9.1. Browse Subnet Example 1">Browse Subnet Example 1</a> (these are
+the machines you would see in your network neighborhood if you looked in it on a particular network right now).
+</p><p>
+</p><div class="table"><a name="browsubnet"></a><p class="title"><b>Table 9.1. Browse Subnet Example 1</b></p><table summary="Browse Subnet Example 1" border="1"><colgroup><col><col><col></colgroup><thead><tr><th align="left">Subnet</th><th align="left">Browse Master</th><th align="left">List</th></tr></thead><tbody><tr><td align="left">Subnet1</td><td align="left">N1_C</td><td align="left">N1_A, N1_B, N1_C, N1_D, N1_E</td></tr><tr><td align="left">Subnet2</td><td align="left">N2_B</td><td align="left">N2_A, N2_B, N2_C, N2_D</td></tr><tr><td align="left">Subnet3</td><td align="left">N3_D</td><td align="left">N3_A, N3_B, N3_C, N3_D</td></tr></tbody></table></div><p>
+</p><p>
+At this point all the subnets are separate, and no machine is seen across any of the subnets.
+</p><p>
+<a class="indexterm" name="id2552394"></a>
+<a class="indexterm" name="id2552401"></a>
+<a class="indexterm" name="id2552407"></a>
+<a class="indexterm" name="id2552414"></a>
+Now examine subnet 2 in <a href="NetworkBrowsing.html#brsbex" title="Table 9.2. Browse Subnet Example 2">Browse Subnet Example 2</a>.
+As soon as N2_B has become the LMB, it looks for a DMB 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 DMB
+(N1_C) with the WINS server as soon as it was started.
+</p><p>
+<a class="indexterm" name="id2552440"></a>
+<a class="indexterm" name="id2552447"></a>
+<a class="indexterm" name="id2552454"></a>
+<a class="indexterm" name="id2552461"></a>
+Once N2_B knows the address of the DMB, it
+tells it that is the LMB for subnet 2 by
+sending a <span class="emphasis"><em>MasterAnnouncement</em></span> packet as a UDP port 138 packet.
+It then synchronizes with it by doing a <span class="emphasis"><em>NetServerEnum2</em></span> call. This
+tells the DMB to send it all the server
+names it knows about. Once the DMB receives
+the <span class="emphasis"><em>MasterAnnouncement</em></span> packet, it schedules a synchronization
+request to the sender of that packet. After both synchronizations
+are complete, the browse lists look like those in <a href="NetworkBrowsing.html#brsbex" title="Table 9.2. Browse Subnet Example 2">Browse Subnet Example 2</a>
+</p><div class="table"><a name="brsbex"></a><p class="title"><b>Table 9.2. Browse Subnet Example 2</b></p><table summary="Browse Subnet Example 2" border="1"><colgroup><col align="left"><col align="left"><col align="justify"></colgroup><thead><tr><th align="left">Subnet</th><th align="left">Browse Master</th><th align="justify">List</th></tr></thead><tbody><tr><td align="left">Subnet1</td><td align="left">N1_C</td><td align="justify">N1_A, N1_B, N1_C, N1_D, N1_E,
+N2_A(*), N2_B(*), N2_C(*), N2_D(*)</td></tr><tr><td align="left">Subnet2</td><td align="left">N2_B</td><td align="justify">N2_A, N2_B, N2_C, N2_D, N1_A(*),
+N1_B(*), N1_C(*), N1_D(*), N1_E(*)</td></tr><tr><td align="left">Subnet3</td><td align="left">N3_D</td><td align="justify">N3_A, N3_B, N3_C, N3_D</td></tr></tbody></table></div><p>
+<a class="indexterm" name="id2552575"></a>
+Servers with an (*) after them are non-authoritative names.
+</p><p>
+<a class="indexterm" name="id2552586"></a>
+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 see only the servers on their own subnet.
+</p><p>
+<a class="indexterm" name="id2552600"></a>
+The same sequence of events that occurred for N2_B now occurs
+for the LMB on subnet 3 (N3_D). When it
+synchronizes browse lists with the DMB (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 <a href="NetworkBrowsing.html#brsex2" title="Table 9.3. Browse Subnet Example 3">Browse Subnet Example 3</a>
+</p><div class="table"><a name="brsex2"></a><p class="title"><b>Table 9.3. Browse Subnet Example 3</b></p><table summary="Browse Subnet Example 3" border="1"><colgroup><col align="left"><col align="left"><col align="justify"></colgroup><thead><tr><th align="left">Subnet</th><th align="left">Browse Master</th><th align="left">List</th></tr></thead><tbody><tr><td align="left">Subnet1</td><td align="left">N1_C</td><td align="left">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(*)</td></tr><tr><td align="left">Subnet2</td><td align="left">N2_B</td><td align="left">N2_A, N2_B, N2_C, N2_D, N1_A(*),
+N1_B(*), N1_C(*), N1_D(*), N1_E(*)</td></tr><tr><td align="left">Subnet3</td><td align="left">N3_D</td><td align="left">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(*)</td></tr></tbody></table></div><p>
+Servers with an (*) after them are non-authoritative names.
+</p><p>
+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 see only the servers on subnets 1 and 2, but not 3.
+</p><p>
+<a class="indexterm" name="id2552716"></a>
+<a class="indexterm" name="id2552723"></a>
+<a class="indexterm" name="id2552730"></a>
+Finally, the LMB for subnet 2 (N2_B) will sync again
+with the DMB (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 <a href="NetworkBrowsing.html#brsex3" title="Table 9.4. Browse Subnet Example 4">Browse Subnet Example 4</a>.
+</p><div class="table"><a name="brsex3"></a><p class="title"><b>Table 9.4. Browse Subnet Example 4</b></p><table summary="Browse Subnet Example 4" border="1"><colgroup><col align="left"><col align="left"><col align="justify"></colgroup><thead><tr><th align="left">Subnet</th><th align="left">Browse Master</th><th align="left">List</th></tr></thead><tbody><tr><td align="left">Subnet1</td><td align="left">N1_C</td><td align="left">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(*)</td></tr><tr><td align="left">Subnet2</td><td align="left">N2_B</td><td align="left">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(*)</td></tr><tr><td align="left">Subnet3</td><td align="left">N3_D</td><td align="left">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(*)</td></tr></tbody></table></div><p>
+Servers with an (*) after them are non-authoritative names.
+</p><p>
+Synchronizations between the DMB and LMBs
+will continue to occur, but this should remain a
+steady-state operation.
+</p><p>
+If either router R1 or R2 fails, the following will occur:
+</p><div class="orderedlist"><ol type="1"><li><p>
+<a class="indexterm" name="id2552859"></a>
+ 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.
+ </p></li><li><p>
+ Attempts to connect to these inaccessible computers will fail, but the
+ names will not be removed from the Network Neighborhood lists.
+ </p></li><li><p>
+<a class="indexterm" name="id2552884"></a>
+<a class="indexterm" name="id2552891"></a>
+<a class="indexterm" name="id2552898"></a>
+ 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 effect is similar to that of
+ losing access to a DNS server.
+ </p></li></ol></div></div></div></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2552915"></a>Common Errors</h2></div></div></div><p>
+<a class="indexterm" name="id2552923"></a>
+<a class="indexterm" name="id2552930"></a>
+Many questions are asked on the mailing lists regarding browsing. The majority of browsing
+problems originate from incorrect configuration of NetBIOS name resolution. Some are of
+particular note.
+</p><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2552942"></a>Flushing the Samba NetBIOS Name Cache</h3></div></div></div><p>
+How Can One Flush the Samba NetBIOS Name Cache without Restarting Samba?
+</p><p>
+<a class="indexterm" name="id2552954"></a>
+<a class="indexterm" name="id2552961"></a>
+<a class="indexterm" name="id2552968"></a>
+<a class="indexterm" name="id2552975"></a>
+Samba's <span><strong class="command">nmbd</strong></span> process controls all browse list handling. Under normal circumstances it is
+safe to restart <span><strong class="command">nmbd</strong></span>. This will effectively flush the Samba NetBIOS name cache and cause it
+to be rebuilt. This does not make certain that a rogue machine name will not reappear
+in the browse list. When <span><strong class="command">nmbd</strong></span> is taken out of service, another machine on the network will
+become the browse master. This new list may still have the rogue entry in it. If you really
+want to clear a rogue machine from the list, every machine on the network must be
+shut down and restarted after all machines are down. Failing a complete restart, the only
+other thing you can do is wait until the entry times out and is then flushed from the list.
+This may take a long time on some networks (perhaps months).
+</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2553015"></a>Server Resources Cannot Be Listed</h3></div></div></div><p>“<span class="quote">My Client Reports "‘<span class="quote">This server is not configured to list shared resources."</span>’</span>”</p><p>
+Your guest account is probably invalid for some reason. Samba uses the
+guest account for browsing in <span><strong class="command">smbd</strong></span>. Check that your guest account is
+valid.
+</p><p>Also see <a class="indexterm" name="id2553043"></a>guest account in the <code class="filename">smb.conf</code> man page.</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2553059"></a>I Get an "<span class="errorname">Unable to browse the network</span>" Error</h3></div></div></div><p>This error can have multiple causes:
+<a class="indexterm" name="id2553071"></a>
+ </p><div class="itemizedlist"><ul type="disc"><li><p>There is no LMB. Configure <span class="application">nmbd</span>
+ or any other machine to serve as LMB.</p></li><li><p>You cannot log onto the machine that is the LMB.
+ Can you log on to it as a guest user? </p></li><li><p>There is no IP connectivity to the LMB.
+ Can you reach it by broadcast?</p></li></ul></div></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2553106"></a>Browsing of Shares and Directories is Very Slow</h3></div></div></div><p>“<span class="quote">
+<a class="indexterm" name="id2553116"></a>
+There are only two machines on a test network. One is a Samba server, the other a Windows XP machine.
+Authentication and logons work perfectly, but when I try to explore shares on the Samba server, the
+Windows XP client becomes unresponsive. Sometimes it does not respond for some minutes. Eventually,
+Windows Explorer will respond and displays files and directories without problem.
+</span>”
+</p><p>“<span class="quote">
+<a class="indexterm" name="id2553135"></a>
+But, the share is immediately available from a command shell (<span><strong class="command">cmd</strong></span>, followed by
+exploration with DOS command. Is this a Samba problem, or is it a Windows problem? How can I solve this?
+</span>”</p><p>
+Here are a few possibilities:
+</p><div class="variablelist"><dl><dt><span class="term">Bad Networking Hardware</span></dt><dd><p>
+<a class="indexterm" name="id2553166"></a>
+<a class="indexterm" name="id2553173"></a>
+<a class="indexterm" name="id2553180"></a>
+<a class="indexterm" name="id2553187"></a>
+<a class="indexterm" name="id2553194"></a>
+ Most common defective hardware problems center around low cost or defective hubs, routers,
+ network interface controllers (NICs), and bad wiring. If one piece of hardware is defective,
+ the whole network may suffer. Bad networking hardware can cause data corruption. Most bad
+ networking hardware problems are accompanied by an increase in apparent network traffic,
+ but not all.
+ </p></dd><dt><span class="term">The Windows XP WebClient</span></dt><dd><p>
+<a class="indexterm" name="id2553219"></a>
+ A number of sites have reported similar slow network browsing problems and found that when
+ the WebClient service is turned off, the problem disappears. This is certainly something
+ that should be explored because it is a simple solution if it works.
+ </p></dd><dt><span class="term">Inconsistent WINS Configuration</span></dt><dd><p>
+<a class="indexterm" name="id2553245"></a>
+<a class="indexterm" name="id2553251"></a>
+ This type of problem is common when one client is configured to use a WINS server (that is
+ a TCP/IP configuration setting) and there is no WINS server on the network. Alternatively,
+ this will happen if there is a WINS server and Samba is not configured to use it. The use of
+ WINS is highly recommended if the network is using NetBIOS over TCP/IP protocols. If use
+ of NetBIOS over TCP/IP is disabled on all clients, Samba should not be configured as a WINS
+ server, nor should it be configured to use one.
+ </p></dd><dt><span class="term">Incorrect DNS Configuration</span></dt><dd><p>
+<a class="indexterm" name="id2553278"></a>
+<a class="indexterm" name="id2553285"></a>
+ If use of NetBIOS over TCP/IP is disabled, Active Directory is in use and the DNS server
+ has been incorrectly configured. For further information refer to
+ <a href="NetworkBrowsing.html#adsdnstech" title="DNS and Active Directory">DNS and Active Directory</a>.
+ </p></dd></dl></div></div></div></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="optional.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="optional.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="passdb.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Part III. Advanced Configuration </td><td width="20%" align="center"><a accesskey="h" href="index.html">Home</a></td><td width="40%" align="right" valign="top"> Chapter 10. Account Information Databases</td></tr></table></div></body></html>
projects / samba / blobdiff