diff options
| author | Gerald Carter <jerry@samba.org> | 2003-10-10 16:46:22 +0000 |
|---|---|---|
| committer | Gerald Carter <jerry@samba.org> | 2003-10-10 16:46:22 +0000 |
| commit | fec4b31bc1a76e408732e1a80b366d97fcf38143 (patch) | |
| tree | e23398c2bcc4e3b2da28c8007ca453228aefb44f /docs/htmldocs/NetworkBrowsing.html | |
| parent | 20c7b998a38424e8e7b4d218f923937b9e8862d4 (diff) | |
| download | samba-fec4b31bc1a76e408732e1a80b366d97fcf38143.tar.gz samba-fec4b31bc1a76e408732e1a80b366d97fcf38143.tar.bz2 samba-fec4b31bc1a76e408732e1a80b366d97fcf38143.zip | |
removing docs tree from 3.0
(This used to be commit 0a3eb5574c91685ab07436c67b031266fb329693)
Diffstat (limited to 'docs/htmldocs/NetworkBrowsing.html')
| -rw-r--r-- | docs/htmldocs/NetworkBrowsing.html | 900 |
1 files changed, 0 insertions, 900 deletions
diff --git a/docs/htmldocs/NetworkBrowsing.html b/docs/htmldocs/NetworkBrowsing.html deleted file mode 100644 index ffe96d2471..0000000000 --- a/docs/htmldocs/NetworkBrowsing.html +++ /dev/null @@ -1,900 +0,0 @@ -<html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>Chapter 10. Network Browsing</title><link rel="stylesheet" href="samba.css" type="text/css"><meta name="generator" content="DocBook XSL Stylesheets V1.60.1"><link rel="home" href="index.html" title="SAMBA Project Documentation"><link rel="up" href="optional.html" title="Part III. Advanced Configuration"><link rel="previous" href="optional.html" title="Part III. Advanced Configuration"><link rel="next" href="passdb.html" title="Chapter 11. 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 10. 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 10. 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><tt class="email"><<a href="mailto:jht@samba.org">jht@samba.org</a>></tt></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><tt class="email"><<a href="mailto:jelmer@samba.org">jelmer@samba.org</a>></tt></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></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><a href="NetworkBrowsing.html#id2897285">Features and Benefits</a></dt><dt><a href="NetworkBrowsing.html#id2887786">What Is Browsing?</a></dt><dt><a href="NetworkBrowsing.html#netdiscuss">Discussion</a></dt><dd><dl><dt><a href="NetworkBrowsing.html#id2888109">NetBIOS over TCP/IP</a></dt><dt><a href="NetworkBrowsing.html#id2888380">TCP/IP without NetBIOS</a></dt><dt><a href="NetworkBrowsing.html#adsdnstech">DNS and Active Directory</a></dt></dl></dd><dt><a href="NetworkBrowsing.html#id2888743">How Browsing Functions</a></dt><dd><dl><dt><a href="NetworkBrowsing.html#DMB">Configuring WORKGROUP Browsing</a></dt><dt><a href="NetworkBrowsing.html#id2900135">DOMAIN Browsing Configuration</a></dt><dt><a href="NetworkBrowsing.html#browse-force-master">Forcing Samba to Be the Master</a></dt><dt><a href="NetworkBrowsing.html#id2900550">Making Samba the Domain Master</a></dt><dt><a href="NetworkBrowsing.html#id2900727">Note about Broadcast Addresses</a></dt><dt><a href="NetworkBrowsing.html#id2900745">Multiple Interfaces</a></dt><dt><a href="NetworkBrowsing.html#id2900780">Use of the Remote Announce Parameter</a></dt><dt><a href="NetworkBrowsing.html#id2900939">Use of the Remote Browse Sync Parameter</a></dt></dl></dd><dt><a href="NetworkBrowsing.html#id2901016">WINS The Windows Internetworking Name Server</a></dt><dd><dl><dt><a href="NetworkBrowsing.html#id2901208">WINS Server Configuration</a></dt><dt><a href="NetworkBrowsing.html#id2901481">WINS Replication</a></dt><dt><a href="NetworkBrowsing.html#id2901518">Static WINS Entries</a></dt></dl></dd><dt><a href="NetworkBrowsing.html#id2901602">Helpful Hints</a></dt><dd><dl><dt><a href="NetworkBrowsing.html#id2901616">Windows Networking Protocols</a></dt><dt><a href="NetworkBrowsing.html#id2901696">Name Resolution Order</a></dt></dl></dd><dt><a href="NetworkBrowsing.html#id2901872">Technical Overview of Browsing</a></dt><dd><dl><dt><a href="NetworkBrowsing.html#id2901926">Browsing Support in Samba</a></dt><dt><a href="NetworkBrowsing.html#id2902057">Problem Resolution</a></dt><dt><a href="NetworkBrowsing.html#id2902187">Cross-Subnet Browsing</a></dt></dl></dd><dt><a href="NetworkBrowsing.html#id2902960">Common Errors</a></dt><dd><dl><dt><a href="NetworkBrowsing.html#id2902975">How Can One Flush the Samba NetBIOS Name Cache without Restarting Samba?</a></dt><dt><a href="NetworkBrowsing.html#id2903041">Server Resources Can Not Be Listed</a></dt><dt><a href="NetworkBrowsing.html#id2903097">I get an `Unable to browse the network' error</a></dt><dt><a href="NetworkBrowsing.html#id2903157">Browsing of Shares and Directories is Very Slow</a></dt></dl></dd></dl></div><p> -This document 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. 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> -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="id2897285"></a>Features and Benefits</h2></div></div><div></div></div><p> -Someone 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="id2897309"></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-nineteenth -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 seven years, and an -ability to germinate at any time of year, given the right conditions, are some of the -features which make it such a persistent weed. -</p><p> -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> -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> -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> -For those networks on which NetBIOS has been disabled (i.e., WINS is not required) -the use of DNS is necessary for host name resolution. -</p></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2887786"></a>What Is Browsing?</h2></div></div><div></div></div><p> -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>MS Windows machines register their presence to the network.</li><li>Machines announce themselves to other machines on the network.</li><li>One or more machine on the network collates the local announcements.</li><li>The client machine finds the machine that has the collated list of machines.</li><li>The client machine is able to resolve the machine names to IP addresses.</li><li>The client machine is able to connect to a target machine.</li></ul></div><p> -The Samba application that controls browse list management and name resolution is -called <tt class="filename">nmbd</tt>. The configuration parameters involved in nmbd's operation are: -</p><p>Browsing options: <a class="indexterm" name="id2887863"></a><i class="parameter"><tt>os level</tt></i>(*), - <a class="indexterm" name="id2887876"></a><i class="parameter"><tt>lm announce</tt></i>, - <a class="indexterm" name="id2887890"></a><i class="parameter"><tt>lm interval</tt></i>, - <a class="indexterm" name="id2887904"></a><i class="parameter"><tt>preferred master</tt></i>(*), - <a class="indexterm" name="id2887918"></a><i class="parameter"><tt>local master</tt></i>(*), - <a class="indexterm" name="id2887932"></a><i class="parameter"><tt>domain master</tt></i>(*), - <a class="indexterm" name="id2887946"></a><i class="parameter"><tt>browse list</tt></i>, - <a class="indexterm" name="id2887959"></a><i class="parameter"><tt>enhanced browsing</tt></i>. -</p><p>Name Resolution Method: - <a class="indexterm" name="id2887977"></a><i class="parameter"><tt>name resolve order</tt></i>(*). -</p><p>WINS options: - <a class="indexterm" name="id2887996"></a><i class="parameter"><tt>dns proxy</tt></i>, - <a class="indexterm" name="id2888009"></a><i class="parameter"><tt>wins proxy</tt></i>, - <a class="indexterm" name="id2888023"></a><i class="parameter"><tt>wins server</tt></i>(*), - <a class="indexterm" name="id2888037"></a><i class="parameter"><tt>wins support</tt></i>(*), - <a class="indexterm" name="id2888051"></a><i class="parameter"><tt>wins hook</tt></i>. -</p><p> -<a class="indexterm" name="id2888069"></a> -For Samba, the WINS Server and WINS Support are mutually exclusive options. Those marked with -an (*) are the only options that commonly may need to be modified. Even if none of these -parameters is set, <tt class="filename">nmbd</tt> will still do its job. -</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></div></div><p> -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="id2888109"></a>NetBIOS over TCP/IP</h3></div></div><div></div></div><p> -Samba implements NetBIOS, as does MS Windows NT/200x/XP, by encapsulating it over TCP/IP. -MS Windows products can do likewise. 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="id2888131"></a> -Normally, only unicast UDP messaging can be forwarded by routers. The -<a class="indexterm" name="id2888140"></a><i class="parameter"><tt>remote announce</tt></i> parameter to smb.conf helps to project browse announcements -to remote network segments via unicast UDP. Similarly, the -<a class="indexterm" name="id2888156"></a><i class="parameter"><tt>remote browse sync</tt></i> parameter of <tt class="filename">smb.conf</tt> -implements browse list collation using unicast UDP. -</p><p> -Secondly, in those networks where Samba is the only SMB server technology, -wherever possible <tt class="filename">nmbd</tt> 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="id2888196"></a> -<a class="indexterm" name="id2888207"></a> -<a class="indexterm" name="id2888215"></a><i class="parameter"><tt>remote announce</tt></i> and the <a class="indexterm" name="id2888229"></a><i class="parameter"><tt>remote browse sync</tt></i> -parameters to your <tt class="filename">smb.conf</tt> file. -</p><p> -<a class="indexterm" name="id2888255"></a> -If only one WINS server is used for an entire multi-segment network, then -the use of the <a class="indexterm" name="id2888264"></a><i class="parameter"><tt>remote announce</tt></i> and the -<a class="indexterm" name="id2888278"></a><i class="parameter"><tt>remote browse sync</tt></i> parameters should not be necessary. -</p><p> -<a class="indexterm" name="id2888297"></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.0 release. Hopefully, this will become a supported feature -of one of the Samba-3 release series. -</p><p> -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 <tt class="filename">nmbd</tt> -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="id2888330"></a><i class="parameter"><tt>remote browse sync</tt></i> and <a class="indexterm" name="id2888343"></a><i class="parameter"><tt>remote announce</tt></i> -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). -</p><p> -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></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2888380"></a>TCP/IP without NetBIOS</h3></div></div><div></div></div><p> -<a class="indexterm" name="id2888391"></a> -<a class="indexterm" name="id2888400"></a> -<a class="indexterm" name="id2888408"></a> -All TCP/IP-enabled systems use various forms of host name resolution. The primary -methods for TCP/IP hostname resolution involve either a static file (<tt class="filename">/etc/hosts</tt>) -or the Domain Name System (DNS). DNS is the technology that makes -the Internet usable. DNS-based host name resolution is supported by nearly all -TCP/IP-enabled systems. Only a few embedded TCP/IP systems do not support DNS. -</p><p> -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 <tt class="filename">hosts</tt> file. It is located in - <tt class="filename">C:\Windows NT\System32\Drivers\etc</tt>. - </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. It is located in - <tt class="filename">C:\Windows NT\System32\Drivers\etc</tt>. - </p></li></ol></div><p> -<a class="indexterm" name="id2888511"></a> -Windows 200x/XP can register its host name with a Dynamic DNS server. You can -force register with a Dynamic DNS server in Windows 200x/XP using: -<b class="command">ipconfig /registerdns</b>. -</p><p> -With Active Directory (ADS), 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 -consequently network services will be severely impaired. -</p><p> -The use of Dynamic DNS 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. -</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></div></div><p> -<a class="indexterm" name="id2888564"></a> -Occasionally we hear from UNIX network administrators who want to use a UNIX-based Dynamic -DNS server in place of the Microsoft DNS server. While this might be desirable to some, the -MS Windows 200x DNS server is auto-configured 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 -so MS Active Directory clients can resolve host names to locate essential network services. -The following are some of the default service records that Active Directory requires: -</p><div class="variablelist"><dl><dt><span class="term">_ldap._tcp.pdc.ms-dcs.<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.ms-dcs.<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.ms-dcs.<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.ms-dcs.<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 datastore. - </p></dd><dt><span class="term">_ldap._tcp.<span class="emphasis"><em>GUID</em></span>.domains.ms-dcs.<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.ms-dcs.<span class="emphasis"><em>DomainTree</em></span></span></dt><dd><p> - Used by MS Windows clients to locate site configuration dependent Global Catalog server. - </p></dd></dl></div></div></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2888743"></a>How Browsing Functions</h2></div></div><div></div></div><p> -MS Windows machines register their NetBIOS names -(i.e., the machine name for each service type in operation) on start-up. -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, or if DNS for NetBIOS name resolution is enabled, etc. -</p><p> -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="id2888773"></a><i class="parameter"><tt>remote announce</tt></i> parameter). -</p><p> -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> -During the startup process an election will take place to create a -Local Master Browser if one does not already exist. On each NetBIOS network -one machine will be elected to function as the Domain Master Browser. This -domain browsing has nothing to do with MS security Domain Control. -Instead, the Domain Master Browser serves the role of contacting each local -master browser (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 Domain Master Browser. -</p><p> -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/addresses. -</p><p> -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> -Samba supports a feature that allows forced synchronization of browse lists across -routed networks using the <a class="indexterm" name="id2888836"></a><i class="parameter"><tt>remote browse sync</tt></i> -parameter in the <tt class="filename">smb.conf</tt> file. This causes Samba to contact the local master -browser 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="id2888863"></a><i class="parameter"><tt>remote browse sync</tt></i> 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, <tt class="filename">/etc/hosts</tt>, 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></div></div><p> -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 Domain Master Browser (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 Domain Master Browser is -to collate the browse lists from Local Master Browsers on all the -subnets that have a machine participating in the workgroup. Without -one machine configured as a Domain Master Browser, each subnet would -be an isolated workgroup unable to see any machines on another -subnet. It is the presence of a Domain Master Browser that makes -cross-subnet browsing possible for a workgroup. -</p><p> -In a WORKGROUP environment the Domain Master Browser must be a -Samba server, and there must only be one Domain Master Browser per -workgroup name. To set up a Samba server as a Domain Master Browser, -set the following option in the <i class="parameter"><tt>[global]</tt></i> section -of the <tt class="filename">smb.conf</tt> file: -</p><p> -</p><table class="simplelist" border="0" summary="Simple list"><tr><td><i class="parameter"><tt>domain master = yes</tt></i></td></tr></table><p> -</p><p> -The Domain Master Browser should preferably be the local master -browser for its own subnet. In order to achieve this, set the following -options in the <i class="parameter"><tt>[global]</tt></i> section of the <tt class="filename">smb.conf</tt> -file as shown in <link linkend="dmbexample">. -</p><p> -</p><div class="example"><a name="dmbexample"></a><p class="title"><b>Example 10.1. Domain Master Browser smb.conf</b></p><table class="simplelist" border="0" summary="Simple list"><tr><td> </td></tr><tr><td><i class="parameter"><tt>[global]</tt></i></td></tr><tr><td><i class="parameter"><tt>domain master = yes</tt></i></td></tr><tr><td><i class="parameter"><tt>local master = yes</tt></i></td></tr><tr><td><i class="parameter"><tt>preferred master = yes</tt></i></td></tr><tr><td><i class="parameter"><tt>os level = 65</tt></i></td></tr></table></div><p> -</p><p> -The Domain Master Browser may be the same machine as the WINS server, if necessary. -</p><p> -Next, you should ensure that each of the subnets contains a machine that can act as -a Local Master Browser 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 these). To make a Samba -server a Local Master Browser set the following options in the -<i class="parameter"><tt>[global]</tt></i> section of the <tt class="filename">smb.conf</tt> file as -shown in <link linkend="lmbexample">: -</p><p> -</p><div class="example"><a name="lmbexample"></a><p class="title"><b>Example 10.2. Local master browser smb.conf</b></p><table class="simplelist" border="0" summary="Simple list"><tr><td> </td></tr><tr><td><i class="parameter"><tt>[global]</tt></i></td></tr><tr><td><i class="parameter"><tt>domain master = no</tt></i></td></tr><tr><td><i class="parameter"><tt>local master = yes</tt></i></td></tr><tr><td><i class="parameter"><tt>preferred master = yes</tt></i></td></tr><tr><td><i class="parameter"><tt>os level = 65</tt></i></td></tr></table></div><p> -</p><p> -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 Local Master Browser. -</p><p> -The <a class="indexterm" name="id2899988"></a><i class="parameter"><tt>local master</tt></i> parameter allows Samba to act as a -Local Master Browser. The <a class="indexterm" name="id2900005"></a><i class="parameter"><tt>preferred master</tt></i> causes <b class="command">nmbd</b> -to force a browser election on startup and the <a class="indexterm" name="id2900026"></a><i class="parameter"><tt>os level</tt></i> -parameter sets Samba high enough so it should win any browser elections. -</p><p> -If you have an NT machine on the subnet that you wish to be the Local Master Browser, you can disable Samba from -becoming a Local Master Browser by setting the following options in the <i class="parameter"><tt>[global]</tt></i> section of the -<tt class="filename">smb.conf</tt> file as shown in <link linkend="nombexample">: -</p><p> -</p><div class="example"><a name="nombexample"></a><p class="title"><b>Example 10.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><i class="parameter"><tt>[global]</tt></i></td></tr><tr><td><i class="parameter"><tt>domain master = no</tt></i></td></tr><tr><td><i class="parameter"><tt>local master = no</tt></i></td></tr><tr><td><i class="parameter"><tt>preferred master = no</tt></i></td></tr><tr><td><i class="parameter"><tt>os level = 0</tt></i></td></tr></table></div><p> -</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2900135"></a>DOMAIN Browsing Configuration</h3></div></div><div></div></div><p> -If you are adding Samba servers to a Windows NT Domain, then you must not set up a Samba server as a Domain Master Browser. -By default, a Windows NT Primary Domain Controller for a domain is also the Domain Master Browser for that domain. Network -browsing may break if a Samba server registers the domain master browser NetBIOS name (<i class="replaceable"><tt>DOMAIN</tt></i><1B>) -with WINS instead of the PDC. -</p><p> -For subnets other than the one containing the Windows NT PDC, you may set up Samba servers as Local Master Browsers as -described. To make a Samba server a Local Master Browser, set the following options in the <i class="parameter"><tt>[global]</tt></i> section -of the <tt class="filename">smb.conf</tt> file as shown in <link linkend="remsmb">: -</p><p> -</p><div class="example"><a name="remsmb"></a><p class="title"><b>Example 10.4. Local Master Browser smb.conf</b></p><table class="simplelist" border="0" summary="Simple list"><tr><td> </td></tr><tr><td><i class="parameter"><tt>[global]</tt></i></td></tr><tr><td><i class="parameter"><tt>domain master = no</tt></i></td></tr><tr><td><i class="parameter"><tt>local master = yes</tt></i></td></tr><tr><td><i class="parameter"><tt>preferred master = yes</tt></i></td></tr><tr><td><i class="parameter"><tt>os level = 65</tt></i></td></tr></table></div><p> -</p><p> -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="id2900256"></a><i class="parameter"><tt>os level</tt></i> parameter to lower levels. -By doing this you can tune the order of machines that will become Local Master Browsers if -they are running. For more details on this refer to <link linkend="browse-force-master">. -</p><p> -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 a Local Master Browser by setting the following options in the -<i class="parameter"><tt>[global]</tt></i> section of the <tt class="filename">smb.conf</tt> file as shown in <link linkend="xremmb">: -</p><p> -</p><div class="example"><a name="xremmb"></a><p class="title"><b>Example 10.5. smb.conf for not being a master browser</b></p><table class="simplelist" border="0" summary="Simple list"><tr><td> </td></tr><tr><td><i class="parameter"><tt>[global]</tt></i></td></tr><tr><td><i class="parameter"><tt>domain master = no</tt></i></td></tr><tr><td><i class="parameter"><tt>local master = no</tt></i></td></tr><tr><td><i class="parameter"><tt>preferred master = no</tt></i></td></tr><tr><td><i class="parameter"><tt>os level = 0</tt></i></td></tr></table></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></div></div><p> -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="id2900406"></a><i class="parameter"><tt>os level</tt></i> -global option in <tt class="filename">smb.conf</tt> to a higher number. It defaults to zero. Using 34 would make it win -all elections every other system (except other samba systems). -</p><p> -An <a class="indexterm" name="id2900432"></a><i class="parameter"><tt>os level</tt></i> 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> -If you want Samba to force an election on startup, set the -<a class="indexterm" name="id2900455"></a><i class="parameter"><tt>preferred master</tt></i> global option in <tt class="filename">smb.conf</tt> to <tt class="constant">yes</tt>. -Samba will then have a slight advantage over other potential master browsers that are not Perferred Master Browsers. -Use this parameter with care, as 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="id2900485"></a><i class="parameter"><tt>preferred master</tt></i> -to <tt class="constant">yes</tt>, then periodically and continually they will force an election in order -to become the Local Master Browser. -</p><p> -If you want Samba to be a <span class="emphasis"><em>Domain Master Browser</em></span>, then it is recommended that -you also set <a class="indexterm" name="id2900514"></a><i class="parameter"><tt>preferred master</tt></i> to <tt class="constant">yes</tt>, because -Samba will not become a Domain Master Browser for the whole of your LAN or WAN if it is not also a -Local Master Browser on its own broadcast isolated subnet. -</p><p> -It is possible to configure two Samba servers to attempt to become the Domain Master Browser for a domain. The first server that comes -up will be the Domain Master Browser. All other Samba servers will attempt to become the Domain Master Browser every five minutes. They -will find that another Samba server is already the domain master browser and will fail. This provides automatic redundancy, should -the current Domain Master Browser fail. -</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2900550"></a>Making Samba the Domain Master</h3></div></div><div></div></div><p> -The domain master 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 by setting <a class="indexterm" name="id2900564"></a><i class="parameter"><tt>domain master</tt></i> = yes -in <tt class="filename">smb.conf</tt>. By default it will not be a Domain Master. -</p><p> -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 twelve minutes) from Local Master Browsers on -other subnets and then contact them to synchronize browse lists. -</p><p> -If you want Samba to be the domain master, you should also set the -<a class="indexterm" name="id2900610"></a><i class="parameter"><tt>os level</tt></i> high enough to make sure it wins elections, and -set <a class="indexterm" name="id2900625"></a><i class="parameter"><tt>preferred master</tt></i> to <tt class="constant">yes</tt>, to -get Samba to force an election on startup. -</p><p> -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> - Local Master Browsers will be unable to find a Domain Master Browser, as they will be looking only on the local subnet. - </p></li><li><p> - 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> -If, however, both Samba and your clients are using a WINS server, then: -</p><div class="orderedlist"><ol type="1"><li><p> - Local master browsers will contact the WINS server and, as long as Samba has registered that it is a Domain Master Browser with the WINS - server, the Local Master Browser will receive Samba's IP address as its Domain Master Browser. - </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="id2900727"></a>Note about Broadcast Addresses</h3></div></div><div></div></div><p> -If your network uses a 0 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="id2900745"></a>Multiple Interfaces</h3></div></div><div></div></div><p> -Samba supports machines with multiple network interfaces. If you have multiple interfaces, you will -need to use the <a class="indexterm" name="id2900757"></a><i class="parameter"><tt>interfaces</tt></i> option in <tt class="filename">smb.conf</tt> to configure them. -</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2900780"></a>Use of the Remote Announce Parameter</h3></div></div><div></div></div><p> -The <a class="indexterm" name="id2900790"></a><i class="parameter"><tt>remote announce</tt></i> parameter of -<tt class="filename">smb.conf</tt> 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="id2900814"></a><i class="parameter"><tt>remote announce</tt></i> parameter is: -</p><table class="simplelist" border="0" summary="Simple list"><tr><td><i class="parameter"><tt>remote announce = a.b.c.d [e.f.g.h] ...</tt></i></td></tr></table><p> -<span class="emphasis"><em>or</em></span> -</p><table class="simplelist" border="0" summary="Simple list"><tr><td><i class="parameter"><tt>remote announce = a.b.c.d/WORKGROUP [e.f.g.h/WORKGROUP] ...</tt></i></td></tr></table><p> - -where: -</p><div class="variablelist"><dl><dt><span class="term"><i class="replaceable"><tt>a.b.c.d</tt></i> and <i class="replaceable"><tt>e.f.g.h</tt></i></span></dt><dd><p> -<a class="indexterm" name="id2900884"></a> -<a class="indexterm" name="id2900896"></a> - is either the LMB (Local Master Browser) IP address or the broadcast address of the remote network. - i.e., the LMB is at 192.168.1.10, or the address could be given as 192.168.1.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"><i class="replaceable"><tt>WORKGROUP</tt></i></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="id2900939"></a>Use of the Remote Browse Sync Parameter</h3></div></div><div></div></div><p> -The <a class="indexterm" name="id2900949"></a><i class="parameter"><tt>remote browse sync</tt></i> parameter of -<tt class="filename">smb.conf</tt> 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="id2900978"></a><i class="parameter"><tt>remote browse sync</tt></i> parameter is: - -</p><table class="simplelist" border="0" summary="Simple list"><tr><td><i class="parameter"><tt>remote browse sync = a.b.c.d</tt></i></td></tr></table><p> - -where <i class="replaceable"><tt>a.b.c.d</tt></i> is either the IP address of the -remote LMB or else is 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="id2901016"></a>WINS The Windows Internetworking Name Server</h2></div></div><div></div></div><p> -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> -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> -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 -<tt class="filename">lmhosts</tt> file that must reside on all clients in the -absence of WINS. -</p><p> -WINS also serves the purpose of forcing browse list synchronization by all -LMBs. LMBs must synchronize their browse list with the DMB (Domain Master -Browser) and WINS helps the LMB to identify its DMB. By definition this -will work only within a single workgroup. Note that the Domain Master Browser -has nothing to do with what is referred to as an MS Windows NT Domain. The -later is a reference to a security environment while the DMB refers to the -master controller for browse list information only. -</p><p> -WINS will work correctly only if every client TCP/IP protocol stack -has been configured to use the WINS servers. Any client that has not been -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="id2901110"></a><i class="parameter"><tt>wins support</tt></i> = yes to the <tt class="filename">smb.conf</tt> -file [global] section. -</p><p> -To configure Samba to register with a WINS server just add -<a class="indexterm" name="id2901137"></a><i class="parameter"><tt>wins server</tt></i> = a.b.c.d -to your <tt class="filename">smb.conf</tt> file <i class="parameter"><tt>[global]</tt></i> section. -</p><div class="important" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Important</h3><p> -Never use both <a class="indexterm" name="id2901170"></a><i class="parameter"><tt>wins support</tt></i> = yes together -with <a class="indexterm" name="id2901185"></a><i class="parameter"><tt>wins server</tt></i> = a.b.c.d -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="id2901208"></a>WINS Server Configuration</h3></div></div><div></div></div><p> -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 <tt class="filename">smb.conf</tt> file on the selected Server the following line to -the <i class="parameter"><tt>[global]</tt></i> section: -</p><p> -</p><table class="simplelist" border="0" summary="Simple list"><tr><td><i class="parameter"><tt>wins support = yes</tt></i></td></tr></table><p> -</p><p> -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="id2901271"></a><i class="parameter"><tt>wins support</tt></i> = yes will keep a list of -all NetBIOS names registered with them, acting as a DNS for NetBIOS names. -</p><p> -It is strongly recommended to set up only one WINS server. Do not set the -<a class="indexterm" name="id2901293"></a><i class="parameter"><tt>wins support</tt></i> = yes option on more than one Samba -server. -</p><p> -<a class="indexterm" name="id2901313"></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. As Microsoft -refuses to document the replication protocols, Samba cannot currently -participate in these replications. It is possible in the future that -a Samba-to-Samba WINS replication protocol may be defined, 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="id2901335"></a><i class="parameter"><tt>wins support</tt></i> = yes parameter set. -</p><p> -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 <i class="parameter"><tt>[global]</tt></i> section of -all <tt class="filename">smb.conf</tt> files: -</p><p> -</p><table class="simplelist" border="0" summary="Simple list"><tr><td><i class="parameter"><tt>wins server = <name or IP address></tt></i></td></tr></table><p> -</p><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 <tt class="filename">smb.conf</tt> file of the Samba -server acting as the WINS server itself. If you set both the -<a class="indexterm" name="id2901432"></a><i class="parameter"><tt>wins support</tt></i> = yes option and the -<a class="indexterm" name="id2901447"></a><i class="parameter"><tt>wins server</tt></i> = <name> option then -<b class="command">nmbd</b> will fail to start. -</p><p> -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="id2901481"></a>WINS Replication</h3></div></div><div></div></div><p> -<a class="indexterm" name="id2901492"></a> -Samba-3 permits WINS replication through the use of the <tt class="filename">wrepld</tt> utility. -This tool is not currently capable of being used as it is still in active development. -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="id2901518"></a>Static WINS Entries</h3></div></div><div></div></div><p> -Adding static entries to your Samba WINS server is actually fairly easy. -All you have to do is add a line to <tt class="filename">wins.dat</tt>, typically -located in <tt class="filename">/usr/local/samba/var/locks</tt>. -</p><p> -Entries in <tt class="filename">wins.dat</tt> take the form of: - -</p><pre class="programlisting"> -"NAME#TYPE" TTL ADDRESS+ FLAGS -</pre><p> - -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><p> -A typical dynamic entry looks like this: -</p><pre class="programlisting"> -"MADMAN#03" 1055298378 192.168.1.2 66R -</pre><p> - -To make it static, all that has to be done is set the TTL to 0, like this: - -</p><pre class="programlisting"> -"MADMAN#03" 0 192.168.1.2 66R -</pre><p> -</p><p> -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="id2901602"></a>Helpful Hints</h2></div></div><div></div></div><p> -The following hints should be carefully considered as 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="id2901616"></a>Windows Networking Protocols</h3></div></div><div></div></div><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 machines. -</p></div><p> -A common cause of browsing problems results from installing more than -one protocol on an MS Windows machine. -</p><p> -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> -The election process is “<span class="quote">fought out</span>” so to speak 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 as Windows -9x/Me will insist it knows who the LMB is. Samba will then cease to function -as an LMB and thus browse list operation on all TCP/IP-only machines will -fail. -</p><p> -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="id2901696"></a>Name Resolution Order</h3></div></div><div></div></div><p> -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>WINS the best tool.</li><li>LMHOSTS static and hard to maintain.</li><li>Broadcast uses UDP and cannot resolve names across remote segments.</li></ul></div><p> -Alternative means of name resolution include: -</p><div class="itemizedlist"><ul type="disc"><li>Static <tt class="filename">/etc/hosts</tt> hard to maintain, and lacks name_type info.</li><li>DNS is a good choice but lacks essential name_type info.</li></ul></div><p> -Many sites want to restrict DNS lookups and avoid broadcast name -resolution traffic. The <i class="parameter"><tt>name resolve order</tt></i> parameter is of great help here. -The syntax of the <i class="parameter"><tt>name resolve order</tt></i> parameter is: -</p><table class="simplelist" border="0" summary="Simple list"><tr><td><i class="parameter"><tt>name resolve order = wins lmhosts bcast host</tt></i></td></tr></table><p> -<span class="emphasis"><em>or</em></span> -</p><table class="simplelist" border="0" summary="Simple list"><tr><td><i class="parameter"><tt>name resolve order = wins lmhosts (eliminates bcast and host)</tt></i></td></tr></table><p> -The default is: -</p><table class="simplelist" border="0" summary="Simple list"><tr><td><i class="parameter"><tt>name resolve order = host lmhost wins bcast</tt></i></td></tr></table><p> -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 <tt class="filename">/etc/host.conf</tt>, <tt class="filename">/etc/nsswitch.conf</tt> and <tt class="filename">/etc/resolv.conf</tt>. -</p></div></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2901872"></a>Technical Overview of Browsing</h2></div></div><div></div></div><p> -SMB networking provides a mechanism by which clients can access a list -of machines in a network, a so-called <a class="indexterm" name="id2901884"></a><i class="parameter"><tt>browse list</tt></i>. This list -contains machines that are ready to offer file and/or print services -to other machines within the network. Thus it does not include -machines that aren't currently able to do server tasks. The browse -list is heavily used by all SMB clients. Configuration of SMB -browsing has been problematic for some Samba users, hence this -document. -</p><p> -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> -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="id2901926"></a>Browsing Support in Samba</h3></div></div><div></div></div><p> -Samba facilitates browsing. The browsing is supported by <span class="application">nmbd</span> -and is also controlled by options in the <tt class="filename">smb.conf</tt> file. -Samba can act as a local browse master for a workgroup and the ability -to support domain logons and scripts is now available. -</p><p> -Samba can also act as a Domain Master Browser for a workgroup. This -means that it will collate lists from Local Master Browsers into a -wide area network server list. In order for browse clients to -resolve the names they may find in this list, it is recommended that -both Samba and your clients use a WINS server. -</p><p> -Do not set Samba to be the Domain Master for a workgroup that has the same -name as an NT Domain. On each wide area network, you must only ever have one -Domain Master Browser per workgroup, regardless of whether it is NT, Samba -or any other type of domain master that is providing this service. -</p><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p> -<b class="command">nmbd</b> can be configured as a WINS server, but it is not -necessary to specifically use Samba as your WINS server. MS Windows -NT4, Server or Advanced Server 200x can be configured as -your WINS server. In a mixed NT/200x server and Samba environment on -a Wide Area Network, it is recommended that you use the Microsoft -WINS server capabilities. In a Samba-only environment, it is -recommended that you use one and only one Samba server as the WINS server. -</p></div><p> -To get browsing to work you need to run nmbd as usual, but will need -to use the <a class="indexterm" name="id2902000"></a><i class="parameter"><tt>workgroup</tt></i> option in <tt class="filename">smb.conf</tt> -to control what workgroup Samba becomes a part of. -</p><p> -Samba also has a useful option for a Samba server to offer itself for -browsing on another subnet. It is recommended that this option is only -used for “<span class="quote">unusual</span>” purposes: announcements over the Internet, for -example. See <a class="indexterm" name="id2902033"></a><i class="parameter"><tt>remote announce</tt></i> in the -<tt class="filename">smb.conf</tt> man page. -</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2902057"></a>Problem Resolution</h3></div></div><div></div></div><p> -If something does not work, the <tt class="filename">log.nmbd</tt> file will help -to track down the problem. Try a <a class="indexterm" name="id2902075"></a><i class="parameter"><tt>log level</tt></i> of 2 or 3 for finding -problems. Also note that the current browse list usually gets stored -in text form in a file called <tt class="filename">browse.dat</tt>. -</p><p> -If it does not work, you should still be able to -type the server name as <tt class="filename">\\SERVER</tt> in <b class="command">filemanager</b>, then -press enter and <b class="command">filemanager</b> should display the list of available shares. -</p><p> -Some people find browsing fails because they do not have the global -<a class="indexterm" name="id2902130"></a><i class="parameter"><tt>guest account</tt></i> set to a valid account. Remember that the -IPC$ connection that lists the shares is done as guest and, thus, you must have a valid guest account. -</p><p> -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> -The other big problem people have is that their broadcast address, -netmask or IP address is wrong (specified with the <a class="indexterm" name="id2902164"></a><i class="parameter"><tt>interfaces</tt></i> option -in <tt class="filename">smb.conf</tt>) -</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2902187"></a>Cross-Subnet Browsing</h3></div></div><div></div></div><p> -<a class="indexterm" name="id2902198"></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> -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. -</p><p> -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 <tt class="filename">smb.conf</tt> file. -</p><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2902248"></a>Behavior of Cross-Subnet Browsing</h4></div></div><div></div></div><p> -Cross-subnet Browsing is a complicated dance, containing multiple -moving parts. It has taken Microsoft several years to get the code -that achieves this correct, and Samba lags behind in some areas. -Samba is capable of cross-subnet browsing when configured correctly. -</p><p> -Consider a network set up as <link linkend="browsing1">. -</p><div class="figure"><a name="browsing1"></a><p class="title"><b>Figure 10.1. Cross-Subnet Browsing Example.</b></p><div class="mediaobject"><img src="projdoc/imagefiles/browsing1.png" width="270" alt="Cross-Subnet Browsing Example."></div></div><p> -This consists of 3 subnets (1, 2, 3) connected by two routers -(R1, R2) which do not pass broadcasts. Subnet 1 has five machines -on it, subnet 2 has four machines, subnet 3 has four machines. Assume -for the moment that all machines are configured to be in the -same workgroup (for simplicity's sake). Machine N1_C on subnet 1 -is configured as Domain Master Browser (i.e., it will collate the -browse lists for the workgroup). Machine N2_D is configured as -WINS server and all the other machines are configured to register -their NetBIOS names with it. -</p><p> -As these machines are booted up, elections for master browsers -will take place on each of the three subnets. Assume that machine -N1_C wins on subnet 1, N2_B wins on subnet 2, and N3_D wins on -subnet 3. These machines are known as Local Master Browsers for -their particular subnet. N1_C has an advantage in winning as the -Local Master Browser on subnet 1 as it is set up as Domain Master -Browser. -</p><p> -On each of the three networks, machines that are configured to -offer sharing services will broadcast that they are offering -these services. The Local Master Browser on each subnet will -receive these broadcasts and keep a record of the fact that -the machine is offering a service. This list of records is -the basis of the browse list. For this case, assume that -all the machines are configured to offer services, so all machines -will be on the browse list. -</p><p> -For each network, the Local Master Browser on that network is -considered “<span class="quote">authoritative</span>” for all the names it receives via -local broadcast. This is because a machine seen by the Local Master -Browser via a local broadcast must be on the same network as the -Local Master Browser and thus is a “<span class="quote">trusted</span>” -and “<span class="quote">verifiable</span>” resource. Machines on other networks that -the Local Master Browsers learn about when collating their -browse lists have not been directly seen. These records are -called “<span class="quote">non-authoritative.</span>” -</p><p> -At this point the browse lists appear as shown in <link linkend="browsubnet"> (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 10.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> -Now examine subnet 2. As soon as N2_B has become the Local -Master Browser it looks for a Domain Master Browser with which to synchronize -its browse list. It does this by querying the WINS server -(N2_D) for the IP address associated with the NetBIOS name -WORKGROUP<1B>. This name was registered by the Domain Master -Browser (N1_C) with the WINS server as soon as it was started. -</p><p> -Once N2_B knows the address of the Domain Master Browser, it -tells it that is the Local Master Browser for subnet 2 by -sending a <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 Domain Master Browser to send it all the server -names it knows about. Once the Domain Master Browser 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 as shown in <link linkend="brsbex">: -</p><div class="table"><a name="brsbex"></a><p class="title"><b>Table 10.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> -Servers with an (*) after them are non-authoritative names. -</p><p> -At this point users looking in their network neighborhood on -subnets 1 or 2 will see all the servers on both, users on -subnet 3 will still only see the servers on their own subnet. -</p><p> -The same sequence of events that occurred for N2_B now occurs -for the Local Master Browser on subnet 3 (N3_D). When it -synchronizes browse lists with the Domain Master Browser (N1_A) -it gets both the server entries on subnet 1, and those on -subnet 2. After N3_D has synchronized with N1_C and vica versa, -the browse lists will appear as shown in <link linkend="brsex2">. -</p><div class="table"><a name="brsex2"></a><p class="title"><b>Table 10.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="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(*), N3_A(*), N3_B(*), N3_C(*), N3_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, 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 only see the servers on subnets 1 and 2, but not 3. -</p><p> -Finally, the Local Master Browser for subnet 2 (N2_B) will sync again -with the Domain Master Browser (N1_C) and will receive the missing -server entries. Finally, as when a steady state (if no machines -are removed or shut off) has been achieved, the browse lists will appear -as shown in <link linkend="brsex3">. -</p><div class="table"><a name="brsex3"></a><p class="title"><b>Table 10.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="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(*), N3_A(*), N3_B(*), -N3_C(*), N3_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(*), N3_A(*), N3_B(*), -N3_C(*), N3_D(*)</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, 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 Domain Master Browser and Local -Master Browsers 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> - 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> - If one of the fragments is cut off from the WINS server, it will only - be able to access servers on its local subnet using subnet-isolated - broadcast NetBIOS name resolution. The effects are similar to that of - losing access to a DNS server. - </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="id2902960"></a>Common Errors</h2></div></div><div></div></div><p> -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="id2902975"></a>How Can One Flush the Samba NetBIOS Name Cache without Restarting Samba?</h3></div></div><div></div></div><p> -<a class="indexterm" name="id2902987"></a> -Samba's <b class="command">nmbd</b> process controls all browse list handling. Under normal circumstances it is -safe to restart <b class="command">nmbd</b>. 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 re-appear -in the browse list. When <b class="command">nmbd</b> 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 will need to 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="id2903041"></a>Server Resources Can Not Be Listed</h3></div></div><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 <b class="command">smbd</b>. Check that your guest account is -valid. -</p><p>Also see <a class="indexterm" name="id2903074"></a><i class="parameter"><tt>guest account</tt></i> in the <tt class="filename">smb.conf</tt> man page.</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2903097"></a>I get an <span class="errorname">`Unable to browse the network'</span> error</h3></div></div><div></div></div><p>This error can have multiple causes: -<a class="indexterm" name="id2903114"></a> - </p><div class="itemizedlist"><ul type="disc"><li><p>There is no Local Master Browser. Configure <span class="application">nmbd</span> - or any other machine to serve as Local Master Browser.</p></li><li><p>You cannot log onto the machine that is the local master - browser. Can you logon to it as a guest user? </p></li><li><p>There is no IP connectivity to the Local Master Browser. - 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="id2903157"></a>Browsing of Shares and Directories is Very Slow</h3></div></div><div></div></div><p>“<span class="quote"> -<a class="indexterm" name="id2903170"></a> -There are only two machines on a test network. One 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 unrespsonsive. Sometimes it does not respond for some minutes. Eventually, -Windows Explorer will respond and displays files and directories without problem. -display file and directory.</span>” -</p><p>“<span class="quote"> -But, the share is immediately available from a command shell (<b class="command">cmd</b>, 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="id2903224"></a> -<a class="indexterm" name="id2903233"></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 number of sites have reported similar slow network browsing problems and found that when - the WebClient service is turned off, the problem dissapears. This is certainly something - that should be explored as it is a simple solution if it works. - </p></dd><dt><span class="term">Inconsistent WINS Configuration</span></dt><dd><p> - 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. Alternately, - this will happen is 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 neither should it be configured to use one. - </p></dd><dt><span class="term">Incorrect DNS Configuration</span></dt><dd><p> - If use of NetBIOS over TCP/IP is disabled, Active Directory is in use and the DNS server - has been incorrectly configured. Refer <link linkend="adsdnstech"> for more information. - </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 11. Account Information Databases</td></tr></table></div></body></html> |