1 <html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>Chapter 10. Samba / MS Windows Network Browsing Guide</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. Samba / MS Windows Network Browsing Guide</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. Samba / MS Windows Network Browsing Guide</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><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#id2903558">Features and Benefits</a></dt><dt><a href="NetworkBrowsing.html#id2903637">What is Browsing?</a></dt><dt><a href="NetworkBrowsing.html#id2903747">Discussion</a></dt><dd><dl><dt><a href="NetworkBrowsing.html#id2903764">NetBIOS over TCP/IP</a></dt><dt><a href="NetworkBrowsing.html#id2903926">TCP/IP - without NetBIOS</a></dt><dt><a href="NetworkBrowsing.html#id2904058">DNS and Active Directory</a></dt></dl></dd><dt><a href="NetworkBrowsing.html#id2904194">How Browsing Functions</a></dt><dd><dl><dt><a href="NetworkBrowsing.html#id2904320">Setting up WORKGROUP Browsing</a></dt><dt><a href="NetworkBrowsing.html#id2904541">Setting up DOMAIN Browsing</a></dt><dt><a href="NetworkBrowsing.html#browse-force-master">Forcing Samba to be the master</a></dt><dt><a href="NetworkBrowsing.html#id2904811">Making Samba the domain master</a></dt><dt><a href="NetworkBrowsing.html#id2904967">Note about broadcast addresses</a></dt><dt><a href="NetworkBrowsing.html#id2904984">Multiple interfaces</a></dt><dt><a href="NetworkBrowsing.html#id2905013">Use of the Remote Announce parameter</a></dt><dt><a href="NetworkBrowsing.html#id2905122">Use of the Remote Browse Sync parameter</a></dt></dl></dd><dt><a href="NetworkBrowsing.html#id2905183">WINS - The Windows Internetworking Name Server</a></dt><dd><dl><dt><a href="NetworkBrowsing.html#id2905341">Setting up a WINS server</a></dt><dt><a href="NetworkBrowsing.html#id2905540">WINS Replication</a></dt><dt><a href="NetworkBrowsing.html#id2905565">Static WINS Entries</a></dt></dl></dd><dt><a href="NetworkBrowsing.html#id2905650">Helpful Hints</a></dt><dd><dl><dt><a href="NetworkBrowsing.html#id2905663">Windows Networking Protocols</a></dt><dt><a href="NetworkBrowsing.html#id2905730">Name Resolution Order</a></dt></dl></dd><dt><a href="NetworkBrowsing.html#id2905867">Technical Overview of browsing</a></dt><dd><dl><dt><a href="NetworkBrowsing.html#id2905914">Browsing support in Samba</a></dt><dt><a href="NetworkBrowsing.html#id2906021">Problem resolution</a></dt><dt><a href="NetworkBrowsing.html#id2906100">Browsing across subnets</a></dt></dl></dd><dt><a href="NetworkBrowsing.html#id2906720">Common Errors</a></dt><dd><dl><dt><a href="NetworkBrowsing.html#id2906735">How can one flush the Samba NetBIOS name cache without restarting Samba?</a></dt><dt><a href="NetworkBrowsing.html#id2906764">My client reports "This server is not configured to list shared resources"</a></dt></dl></dd></dl></div><p>
2 This document contains detailed information as well as a fast track guide to
3 implementing browsing across subnets and / or across workgroups (or domains).
4 WINS is the best tool for resolution of NetBIOS names to IP addresses. WINS is
5 NOT involved in browse list handling except by way of name to address resolution.
6 </p><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>
7 MS Windows 2000 and later can be configured to operate with NO NetBIOS
8 over TCP/IP. Samba-3 and later also supports this mode of operation.
9 When the use of NetBIOS over TCP/IP has been disabled then the primary
10 means for resolution of MS Windows machine names is via DNS and Active Directory.
11 The following information assumes that your site is running NetBIOS over TCP/IP.
12 </p></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2903558"></a>Features and Benefits</h2></div></div><div></div></div><p>
13 Someone once referred to the past in terms of: <span class="emphasis"><em>They were the worst of times,
14 they were the best of times. The more we look back, them more we long for what was and
15 hope it never returns!</em></span>.
17 For many MS Windows network administrators, that statement sums up their feelings about
18 NetBIOS networking precisely. For those who mastered NetBIOS networking, its fickle
19 nature was just par for the course. For those who never quite managed to tame its
20 lusty features, NetBIOS is like Paterson's Curse.
22 For those not familiar with botanical problems in Australia: Paterson's curse,
23 Echium plantagineum, was introduced to Australia from Europe during the mid-nineteenth
24 century. Since then it has spread rapidly. The high seed production, with densities of
25 thousands of seeds per square metre, a seed longevity of more than seven years, and an
26 ability to germinate at any time of year, given the right conditions, are some of the
27 features which make it such a persistent weed.
29 In this chapter we explore vital aspects of SMB (Server Message Block) networking with
30 a particular focus on SMB as implemented through running NetBIOS (Network Basic
31 Input / Output System) over TCP/IP. Since Samba does NOT implement SMB or NetBIOS over
32 any other protocols we need to know how to configure our network environment and simply
33 remember to use nothing but TCP/IP on all our MS Windows network clients.
35 Samba provides the ability to implement a WINS (Windows Internetworking Name Server)
36 and implements extensions to Microsoft's implementation of WINS. These extensions
37 help Samba to affect stable WINS operations beyond the normal scope of MS WINS.
39 Please note that WINS is exclusively a service that applies only to those systems
40 that run NetBIOS over TCP/IP. MS Windows 200x / XP have the capacity to turn off
41 support for NetBIOS, in which case WINS is of no relevance. Samba-3 supports this also.
43 For those networks on which NetBIOS has been disabled (ie: WINS is NOT required)
44 the use of DNS is necessary for host name resolution.
45 </p></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2903637"></a>What is Browsing?</h2></div></div><div></div></div><p>
46 To most people browsing means that they can see the MS Windows and Samba servers
47 in the Network Neighborhood, and when the computer icon for a particular server is
48 clicked, it opens up and shows the shares and printers available on the target server.
50 What seems so simple is in fact a very complex interaction of different technologies.
51 The technologies (or methods) employed in making all of this work includes:
52 </p><table class="simplelist" border="0" summary="Simple list"><tr><td>MS Windows machines register their presence to the network</td></tr><tr><td>Machines announce themselves to other machines on the network</td></tr><tr><td>One or more machine on the network collates the local announcements</td></tr><tr><td>The client machine finds the machine that has the collated list of machines</td></tr><tr><td>The client machine is able to resolve the machine names to IP addresses</td></tr><tr><td>The client machine is able to connect to a target machine</td></tr></table><p>
53 The Samba application that controls browse list management and name resolution is
54 called <tt class="filename">nmbd</tt>. The configuration parameters involved in nmbd's operation are:
55 </p><pre class="programlisting">
68 Name Resolution Method:
69 -----------------------
80 For Samba, the WINS Server and WINS Support are mutually exclusive options. Those marked with
81 an '*' are the only options that commonly MAY need to be modified. Even if not one of these
82 parameters is set <tt class="filename">nmbd</tt> will still do it's job.
83 </p></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2903747"></a>Discussion</h2></div></div><div></div></div><p>
84 Firstly, all MS Windows networking uses SMB (Server Message Block) based messaging.
85 SMB messaging may be implemented with or without NetBIOS. MS Windows 200x supports
86 NetBIOS over TCP/IP for backwards compatibility. Microsoft is intent on phasing out NetBIOS
88 </p><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2903764"></a>NetBIOS over TCP/IP</h3></div></div><div></div></div><p>
89 Samba implements NetBIOS, as does MS Windows NT / 200x / XP, by encapsulating it over TCP/IP.
90 MS Windows products can do likewise. NetBIOS based networking uses broadcast messaging to
91 affect browse list management. When running NetBIOS over TCP/IP, this uses UDP based messaging.
92 UDP messages can be broadcast or unicast.
94 Normally, only unicast UDP messaging can be forwarded by routers. The
95 <b class="command">remote announce</b> parameter to smb.conf helps to project browse announcements
96 to remote network segments via unicast UDP. Similarly, the
97 <b class="command">remote browse sync</b> parameter of <tt class="filename">smb.conf</tt>
98 implements browse list collation using unicast UDP.
100 Secondly, in those networks where Samba is the only SMB server technology,
101 wherever possible <tt class="filename">nmbd</tt> should be configured on one (1) machine as the WINS
102 server. This makes it easy to manage the browsing environment. If each network
103 segment is configured with it's own Samba WINS server, then the only way to
104 get cross segment browsing to work is by using the
105 <b class="command">remote announce</b> and the <b class="command">remote browse sync</b>
106 parameters to your <tt class="filename">smb.conf</tt> file.
108 If only one WINS server is used for an entire multi-segment network then
109 the use of the <b class="command">remote announce</b> and the
110 <b class="command">remote browse sync</b> parameters should NOT be necessary.
112 As of Samba 3 WINS replication is being worked on. The bulk of the code has
113 been committed, but it still needs maturation. This is NOT a supported feature
114 of the Samba-3.0.0 release. Hopefully, this will become a supported feature
115 of one of the Samba-3 release series.
117 Right now Samba WINS does not support MS-WINS replication. This means that
118 when setting up Samba as a WINS server there must only be one <tt class="filename">nmbd</tt>
119 configured as a WINS server on the network. Some sites have used multiple Samba WINS
120 servers for redundancy (one server per subnet) and then used
121 <b class="command">remote browse sync</b> and <b class="command">remote announce</b>
122 to affect browse list collation across all segments. Note that this means clients
123 will only resolve local names, and must be configured to use DNS to resolve names
124 on other subnets in order to resolve the IP addresses of the servers they can see
125 on other subnets. This setup is not recommended, but is mentioned as a practical
126 consideration (ie: an 'if all else fails' scenario).
128 Lastly, take note that browse lists are a collection of unreliable broadcast
129 messages that are repeated at intervals of not more than 15 minutes. This means
130 that it will take time to establish a browse list and it can take up to 45
131 minutes to stabilise, particularly across network segments.
132 </p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2903926"></a>TCP/IP - without NetBIOS</h3></div></div><div></div></div><p>
133 All TCP/IP using systems use various forms of host name resolution. The primary
134 methods for TCP/IP hostname resolutions involves either a static file (<tt class="filename">/etc/hosts
135 </tt>) or DNS (the Domain Name System). DNS is the technology that makes
136 the Internet usable. DNS based host name resolution is supported by nearly all TCP/IP
137 enabled systems. Only a few embedded TCP/IP systems do not support DNS.
139 When an MS Windows 200x / XP system attempts to resolve a host name to an IP address
140 it follows a defined path:
141 </p><div class="orderedlist"><ol type="1"><li><p>
142 Checks the <tt class="filename">hosts</tt> file. It is located in
143 <tt class="filename">C:\WinNT\System32\Drivers\etc</tt>.
147 Checks the NetBIOS name cache
149 Queries the WINS server
151 Does a broadcast name lookup over UDP
153 Looks up entries in LMHOSTS. It is located in
154 <tt class="filename">C:\WinNT\System32\Drivers\etc</tt>.
155 </p></li></ol></div><p>
156 Windows 200x / XP can register it's host name with a Dynamic DNS server. You can
157 force register with a Dynamic DNS server in Windows 200x / XP using:
158 <b class="command">ipconfig /registerdns</b>
160 With Active Directory (ADS), a correctly functioning DNS server is absolutely
161 essential. In the absence of a working DNS server that has been correctly configured,
162 MS Windows clients and servers will be totally unable to locate each other,
163 consequently network services will be severely impaired.
165 The use of Dynamic DNS is highly recommended with Active Directory, in which case
166 the use of BIND9 is preferred for it's ability to adequately support the SRV (service)
167 records that are needed for Active Directory.
168 </p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2904058"></a>DNS and Active Directory</h3></div></div><div></div></div><p>
169 Occasionally we hear from Unix network administrators who want to use a Unix based Dynamic
170 DNS server in place of the Microsoft DNS server. While this might be desirable to some, the
171 MS Windows 200x DNS server is auto-configured to work with Active Directory. It is possible
172 to use BIND version 8 or 9, but it will almost certainly be necessary to create service records
173 so that MS Active Directory clients can resolve host names to locate essential network services.
174 The following are some of the default service records that Active Directory requires:
175 </p><div class="itemizedlist"><ul type="disc"><li><p>_ldap._tcp.pdc.ms-dcs.<span class="emphasis"><em>Domain</em></span></p><p>
176 This provides the address of the Windows NT PDC for the Domain.
177 </p></li><li><p>_ldap._tcp.pdc.ms-dcs.<span class="emphasis"><em>DomainTree</em></span></p><p>
178 Resolves the addresses of Global Catalog servers in the domain.
179 </p></li><li><p>_ldap._tcp.<span class="emphasis"><em>site</em></span>.sites.writable.ms-dcs.<span class="emphasis"><em>Domain</em></span></p><p>
180 Provides list of domain controllers based on sites.
181 </p></li><li><p>_ldap._tcp.writable.ms-dcs.<span class="emphasis"><em>Domain</em></span></p><p>
182 Enumerates list of domain controllers that have the writable
183 copies of the Active Directory data store.
184 </p></li><li><p>_ldap._tcp.<span class="emphasis"><em>GUID</em></span>.domains.ms-dcs.<span class="emphasis"><em>DomainTree</em></span></p><p>
185 Entry used by MS Windows clients to locate machines using the
186 Global Unique Identifier.
187 </p></li><li><p>_ldap._tcp.<span class="emphasis"><em>Site</em></span>.gc.ms-dcs.<span class="emphasis"><em>DomainTree</em></span></p><p>
188 Used by MS Windows clients to locate site configuration dependent
189 Global Catalog server.
190 </p></li></ul></div></div></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2904194"></a>How Browsing Functions</h2></div></div><div></div></div><p>
191 MS Windows machines register their NetBIOS names
192 (ie: the machine name for each service type in operation) on start
193 up. The exact method by which this name registration
194 takes place is determined by whether or not the MS Windows client/server
195 has been given a WINS server address, whether or not LMHOSTS lookup
196 is enabled, or if DNS for NetBIOS name resolution is enabled, etc.
198 In the case where there is no WINS server, all name registrations as
199 well as name lookups are done by UDP broadcast. This isolates name
200 resolution to the local subnet, unless LMHOSTS is used to list all
201 names and IP addresses. In such situations Samba provides a means by
202 which the Samba server name may be forcibly injected into the browse
203 list of a remote MS Windows network (using the
204 <b class="command">remote announce</b> parameter).
206 Where a WINS server is used, the MS Windows client will use UDP
207 unicast to register with the WINS server. Such packets can be routed
208 and thus WINS allows name resolution to function across routed networks.
210 During the startup process an election will take place to create a
211 local master browser if one does not already exist. On each NetBIOS network
212 one machine will be elected to function as the domain master browser. This
213 domain browsing has nothing to do with MS security domain control.
214 Instead, the domain master browser serves the role of contacting each local
215 master browser (found by asking WINS or from LMHOSTS) and exchanging browse
216 list contents. This way every master browser will eventually obtain a complete
217 list of all machines that are on the network. Every 11-15 minutes an election
218 is held to determine which machine will be the master browser. By the nature of
219 the election criteria used, the machine with the highest uptime, or the
220 most senior protocol version, or other criteria, will win the election
221 as domain master browser.
223 Clients wishing to browse the network make use of this list, but also depend
224 on the availability of correct name resolution to the respective IP
227 Any configuration that breaks name resolution and/or browsing intrinsics
228 will annoy users because they will have to put up with protracted
229 inability to use the network services.
231 Samba supports a feature that allows forced synchronisation
232 of browse lists across routed networks using the <b class="command">remote
233 browse sync</b> parameter in the <tt class="filename">smb.conf</tt> file.
234 This causes Samba to contact the local master browser on a remote network and
235 to request browse list synchronisation. This effectively bridges
236 two networks that are separated by routers. The two remote
237 networks may use either broadcast based name resolution or WINS
238 based name resolution, but it should be noted that the <b class="command">remote
239 browse sync</b> parameter provides browse list synchronisation - and
240 that is distinct from name to address resolution, in other
241 words, for cross subnet browsing to function correctly it is
242 essential that a name to address resolution mechanism be provided.
243 This mechanism could be via DNS, <tt class="filename">/etc/hosts</tt>,
245 </p><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2904320"></a>Setting up WORKGROUP Browsing</h3></div></div><div></div></div><p>
246 To set up cross subnet browsing on a network containing machines
247 in up to be in a WORKGROUP, not an NT Domain you need to set up one
248 Samba server to be the Domain Master Browser (note that this is *NOT*
249 the same as a Primary Domain Controller, although in an NT Domain the
250 same machine plays both roles). The role of a Domain master browser is
251 to collate the browse lists from local master browsers on all the
252 subnets that have a machine participating in the workgroup. Without
253 one machine configured as a domain master browser each subnet would
254 be an isolated workgroup, unable to see any machines on any other
255 subnet. It is the presence of a domain master browser that makes
256 cross subnet browsing possible for a workgroup.
258 In an WORKGROUP environment the domain master browser must be a
259 Samba server, and there must only be one domain master browser per
260 workgroup name. To set up a Samba server as a domain master browser,
261 set the following option in the <i class="parameter"><tt>[global]</tt></i> section
262 of the <tt class="filename">smb.conf</tt> file :
264 </p><pre class="programlisting">
268 The domain master browser should also preferrably be the local master
269 browser for its own subnet. In order to achieve this set the following
270 options in the <i class="parameter"><tt>[global]</tt></i> section of the <tt class="filename">smb.conf</tt> file :
272 </p><pre class="programlisting">
275 preferred master = yes
279 The domain master browser may be the same machine as the WINS
280 server, if you require.
282 Next, you should ensure that each of the subnets contains a
283 machine that can act as a local master browser for the
284 workgroup. Any MS Windows NT/2K/XP/2003 machine should be
285 able to do this, as will Windows 9x machines (although these
286 tend to get rebooted more often, so it's not such a good idea
287 to use these). To make a Samba server a local master browser
288 set the following options in the <i class="parameter"><tt>[global]</tt></i> section of the
289 <tt class="filename">smb.conf</tt> file :
291 </p><pre class="programlisting">
294 preferred master = yes
298 Do not do this for more than one Samba server on each subnet,
299 or they will war with each other over which is to be the local
302 The <i class="parameter"><tt>local master</tt></i> parameter allows Samba to act as a
303 local master browser. The <i class="parameter"><tt>preferred master</tt></i> causes nmbd
304 to force a browser election on startup and the <i class="parameter"><tt>os level</tt></i>
305 parameter sets Samba high enough so that it should win any browser elections.
307 If you have an NT machine on the subnet that you wish to
308 be the local master browser then you can disable Samba from
309 becoming a local master browser by setting the following
310 options in the <i class="parameter"><tt>[global]</tt></i> section of the
311 <tt class="filename">smb.conf</tt> file :
313 </p><pre class="programlisting">
316 preferred master = no
319 </p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2904541"></a>Setting up DOMAIN Browsing</h3></div></div><div></div></div><p>
320 If you are adding Samba servers to a Windows NT Domain then
321 you must not set up a Samba server as a domain master browser.
322 By default, a Windows NT Primary Domain Controller for a domain
323 is also the Domain master browser for that domain, and many
324 things will break if a Samba server registers the Domain master
325 browser NetBIOS name (<i class="replaceable"><tt>DOMAIN</tt></i><1B>)
326 with WINS instead of the PDC.
328 For subnets other than the one containing the Windows NT PDC
329 you may set up Samba servers as local master browsers as
330 described. To make a Samba server a local master browser set
331 the following options in the <b class="command">[global]</b> section
332 of the <tt class="filename">smb.conf</tt> file :
334 </p><pre class="programlisting">
337 preferred master = yes
341 If you wish to have a Samba server fight the election with machines
342 on the same subnet you may set the <i class="parameter"><tt>os level</tt></i> parameter
343 to lower levels. By doing this you can tune the order of machines that
344 will become local master browsers if they are running. For
345 more details on this see the section <a href="NetworkBrowsing.html#browse-force-master" title="Forcing Samba to be the master">
346 Forcing Samba to be the master browser</a>
349 If you have Windows NT machines that are members of the domain
350 on all subnets, and you are sure they will always be running then
351 you can disable Samba from taking part in browser elections and
352 ever becoming a local master browser by setting following options
353 in the <i class="parameter"><tt>[global]</tt></i> section of the <tt class="filename">smb.conf</tt>
356 </p><pre class="programlisting">
359 preferred master = no
362 </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>
363 Who becomes the <i class="parameter"><tt>master browser</tt></i> is determined by an election
364 process using broadcasts. Each election packet contains a number of parameters
365 which determine what precedence (bias) a host should have in the
366 election. By default Samba uses a very low precedence and thus loses
367 elections to just about anyone else.
369 If you want Samba to win elections then just set the <i class="parameter"><tt>os level</tt></i> global
370 option in <tt class="filename">smb.conf</tt> to a higher number. It defaults to 0. Using 34
371 would make it win all elections over every other system (except other
374 A <i class="parameter"><tt>os level</tt></i> of 2 would make it beat WfWg and Win95, but not MS Windows
375 NT/2K Server. A MS Windows NT/2K Server domain controller uses level 32.
376 </p><p>The maximum os level is 255</p><p>
377 If you want Samba to force an election on startup, then set the
378 <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
379 then have a slight advantage over other potential master browsers
380 that are not preferred master browsers. Use this parameter with
381 care, as if you have two hosts (whether they are Windows 95 or NT or
382 Samba) on the same local subnet both set with <i class="parameter"><tt>preferred master</tt></i> to
383 <tt class="constant">yes</tt>, then periodically and continually they will force an election
384 in order to become the local master browser.
386 If you want Samba to be a <i class="parameter"><tt>domain master browser</tt></i>, then it is
387 recommended that you also set <i class="parameter"><tt>preferred master</tt></i> to <tt class="constant">yes</tt>, because
388 Samba will not become a domain master browser for the whole of your
389 LAN or WAN if it is not also a local master browser on its own
390 broadcast isolated subnet.
392 It is possible to configure two Samba servers to attempt to become
393 the domain master browser for a domain. The first server that comes
394 up will be the domain master browser. All other Samba servers will
395 attempt to become the domain master browser every 5 minutes. They
396 will find that another Samba server is already the domain master
397 browser and will fail. This provides automatic redundancy, should
398 the current domain master browser fail.
399 </p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2904811"></a>Making Samba the domain master</h3></div></div><div></div></div><p>
400 The domain master is responsible for collating the browse lists of
401 multiple subnets so that browsing can occur between subnets. You can
402 make Samba act as the domain master by setting <i class="parameter"><tt>domain master = yes</tt></i>
403 in <tt class="filename">smb.conf</tt>. By default it will not be a domain master.
405 Note that you should <span class="emphasis"><em>not</em></span> set Samba to be the domain master for a
406 workgroup that has the same name as an NT Domain.
408 When Samba is the domain master and the master browser, it will listen
409 for master announcements (made roughly every twelve minutes) from local
410 master browsers on other subnets and then contact them to synchronise
413 If you want Samba to be the domain master then I suggest you also set
414 the <i class="parameter"><tt>os level</tt></i> high enough to make sure it wins elections, and set
415 <i class="parameter"><tt>preferred master</tt></i> to <tt class="constant">yes</tt>, to get Samba to force an election on
418 Note that all your servers (including Samba) and clients should be
419 using a WINS server to resolve NetBIOS names. If your clients are only
420 using broadcasting to resolve NetBIOS names, then two things will occur:
421 </p><div class="orderedlist"><ol type="1"><li><p>
422 your local master browsers will be unable to find a domain master
423 browser, as it will only be looking on the local subnet.
425 if a client happens to get hold of a domain-wide browse list, and
426 a user attempts to access a host in that list, it will be unable to
427 resolve the NetBIOS name of that host.
428 </p></li></ol></div><p>
429 If, however, both Samba and your clients are using a WINS server, then:
430 </p><div class="orderedlist"><ol type="1"><li><p>
431 your local master browsers will contact the WINS server and, as long as
432 Samba has registered that it is a domain master browser with the WINS
433 server, your local master browser will receive Samba's IP address
434 as its domain master browser.
436 when a client receives a domain-wide browse list, and a user attempts
437 to access a host in that list, it will contact the WINS server to
438 resolve the NetBIOS name of that host. as long as that host has
439 registered its NetBIOS name with the same WINS server, the user will
440 be able to see that host.
441 </p></li></ol></div></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2904967"></a>Note about broadcast addresses</h3></div></div><div></div></div><p>
442 If your network uses a "0" based broadcast address (for example if it
443 ends in a 0) then you will strike problems. Windows for Workgroups
444 does not seem to support a 0's broadcast and you will probably find
445 that browsing and name lookups won't work.
446 </p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2904984"></a>Multiple interfaces</h3></div></div><div></div></div><p>
447 Samba now supports machines with multiple network interfaces. If you
448 have multiple interfaces then you will need to use the <b class="command">interfaces</b>
449 option in <tt class="filename">smb.conf</tt> to configure them.
450 </p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2905013"></a>Use of the Remote Announce parameter</h3></div></div><div></div></div><p>
451 The <i class="parameter"><tt>remote announce</tt></i> parameter of
452 <tt class="filename">smb.conf</tt> can be used to forcibly ensure
453 that all the NetBIOS names on a network get announced to a remote network.
454 The syntax of the <i class="parameter"><tt>remote announce</tt></i> parameter is:
455 </p><pre class="programlisting">
456 remote announce = a.b.c.d [e.f.g.h] ...
458 <span class="emphasis"><em>or</em></span>
459 </p><pre class="programlisting">
460 remote announce = a.b.c.d/WORKGROUP [e.f.g.h/WORKGROUP] ...
464 </p><div class="variablelist"><dl><dt><span class="term"><i class="replaceable"><tt>a.b.c.d</tt></i> and
465 <i class="replaceable"><tt>e.f.g.h</tt></i></span></dt><dd><p>is either the LMB (Local Master Browser) IP address
466 or the broadcast address of the remote network.
467 ie: the LMB is at 192.168.1.10, or the address
468 could be given as 192.168.1.255 where the netmask
469 is assumed to be 24 bits (255.255.255.0).
470 When the remote announcement is made to the broadcast
471 address of the remote network, every host will receive
472 our announcements. This is noisy and therefore
473 undesirable but may be necessary if we do NOT know
474 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
475 or that of the remote network. If you use the
476 workgroup name of the remote network then our
477 NetBIOS machine names will end up looking like
478 they belong to that workgroup, this may cause
479 name resolution problems and should be avoided.
480 </p></dd></dl></div><p>
481 </p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2905122"></a>Use of the Remote Browse Sync parameter</h3></div></div><div></div></div><p>
482 The <i class="parameter"><tt>remote browse sync</tt></i> parameter of
483 <tt class="filename">smb.conf</tt> is used to announce to
484 another LMB that it must synchronise its NetBIOS name list with our
485 Samba LMB. It works ONLY if the Samba server that has this option is
486 simultaneously the LMB on its network segment.
488 The syntax of the <i class="parameter"><tt>remote browse sync</tt></i> parameter is:
490 </p><pre class="programlisting">
491 remote browse sync = <i class="replaceable"><tt>a.b.c.d</tt></i>
494 where <i class="replaceable"><tt>a.b.c.d</tt></i> is either the IP address of the
495 remote LMB or else is the network broadcast address of the remote segment.
496 </p></div></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2905183"></a>WINS - The Windows Internetworking Name Server</h2></div></div><div></div></div><p>
497 Use of WINS (either Samba WINS <span class="emphasis"><em>or</em></span> MS Windows NT Server WINS) is highly
498 recommended. Every NetBIOS machine registers its name together with a
499 name_type value for each of several types of service it has available.
500 eg: It registers its name directly as a unique (the type 0x03) name.
501 It also registers its name if it is running the LanManager compatible
502 server service (used to make shares and printers available to other users)
503 by registering the server (the type 0x20) name.
505 All NetBIOS names are up to 15 characters in length. The name_type variable
506 is added to the end of the name - thus creating a 16 character name. Any
507 name that is shorter than 15 characters is padded with spaces to the 15th
508 character. ie: All NetBIOS names are 16 characters long (including the
509 name_type information).
511 WINS can store these 16 character names as they get registered. A client
512 that wants to log onto the network can ask the WINS server for a list
513 of all names that have registered the NetLogon service name_type. This saves
514 broadcast traffic and greatly expedites logon processing. Since broadcast
515 name resolution can not be used across network segments this type of
516 information can only be provided via WINS <span class="emphasis"><em>or</em></span> via statically configured
517 <tt class="filename">lmhosts</tt> files that must reside on all clients in the
520 WINS also serves the purpose of forcing browse list synchronisation by all
521 LMB's. LMB's must synchronise their browse list with the DMB (domain master
522 browser) and WINS helps the LMB to identify it's DMB. By definition this
523 will work only within a single workgroup. Note that the domain master browser
524 has NOTHING to do with what is referred to as an MS Windows NT Domain. The
525 later is a reference to a security environment while the DMB refers to the
526 master controller for browse list information only.
528 Use of WINS will work correctly only if EVERY client TCP/IP protocol stack
529 has been configured to use the WINS server/s. Any client that has not been
530 configured to use the WINS server will continue to use only broadcast based
531 name registration so that WINS may NEVER get to know about it. In any case,
532 machines that have not registered with a WINS server will fail name to address
533 lookup attempts by other clients and will therefore cause workstation access
536 To configure Samba as a WINS server just add
537 <i class="parameter"><tt>wins support = yes</tt></i> to the <tt class="filename">smb.conf</tt>
538 file [globals] section.
540 To configure Samba to register with a WINS server just add
541 <i class="parameter"><tt>wins server = a.b.c.d</tt></i> to your <tt class="filename">smb.conf</tt> file <i class="parameter"><tt>[globals]</tt></i> section.
542 </p><div class="important" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Important</h3><p>
543 Never use both <i class="parameter"><tt>wins support = yes</tt></i> together
544 with <i class="parameter"><tt>wins server = a.b.c.d</tt></i>
545 particularly not using it's own IP address.
546 Specifying both will cause <span class="application">nmbd</span> to refuse to start!
547 </p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2905341"></a>Setting up a WINS server</h3></div></div><div></div></div><p>
548 Either a Samba machine or a Windows NT Server machine may be set up
549 as a WINS server. To set a Samba machine to be a WINS server you must
550 add the following option to the <tt class="filename">smb.conf</tt> file on the selected machine :
551 in the <i class="parameter"><tt>[globals]</tt></i> section add the line
553 </p><pre class="programlisting">
557 Versions of Samba prior to 1.9.17 had this parameter default to
558 yes. If you have any older versions of Samba on your network it is
559 strongly suggested you upgrade to a recent version, or at the very
560 least set the parameter to 'no' on all these machines.
562 Machines with <i class="parameter"><tt>wins support = yes</tt></i> will keep a list of
563 all NetBIOS names registered with them, acting as a DNS for NetBIOS names.
565 You should set up only ONE WINS server. Do NOT set the
566 <i class="parameter"><tt>wins support = yes</tt></i> option on more than one Samba
569 To set up a Windows NT Server as a WINS server you need to set up
570 the WINS service - see your NT documentation for details. Note that
571 Windows NT WINS Servers can replicate to each other, allowing more
572 than one to be set up in a complex subnet environment. As Microsoft
573 refuses to document these replication protocols, Samba cannot currently
574 participate in these replications. It is possible in the future that
575 a Samba->Samba WINS replication protocol may be defined, in which
576 case more than one Samba machine could be set up as a WINS server
577 but currently only one Samba server should have the
578 <i class="parameter"><tt>wins support = yes</tt></i> parameter set.
580 After the WINS server has been configured you must ensure that all
581 machines participating on the network are configured with the address
582 of this WINS server. If your WINS server is a Samba machine, fill in
583 the Samba machine IP address in the <span class="guilabel">Primary WINS Server</span> field of
584 the <span class="guilabel">Control Panel->Network->Protocols->TCP->WINS Server</span> dialogs
585 in Windows 95 or Windows NT. To tell a Samba server the IP address
586 of the WINS server add the following line to the <i class="parameter"><tt>[global]</tt></i> section of
587 all <tt class="filename">smb.conf</tt> files :
589 </p><pre class="programlisting">
590 wins server = <name or IP address>
593 where <name or IP address> is either the DNS name of the WINS server
594 machine or its IP address.
596 Note that this line MUST NOT BE SET in the <tt class="filename">smb.conf</tt> file of the Samba
597 server acting as the WINS server itself. If you set both the
598 <i class="parameter"><tt>wins support = yes</tt></i> option and the
599 <i class="parameter"><tt>wins server = <name></tt></i> option then
600 nmbd will fail to start.
602 There are two possible scenarios for setting up cross subnet browsing.
603 The first details setting up cross subnet browsing on a network containing
604 Windows 95, Samba and Windows NT machines that are not configured as
605 part of a Windows NT Domain. The second details setting up cross subnet
606 browsing on networks that contain NT Domains.
607 </p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2905540"></a>WINS Replication</h3></div></div><div></div></div><p>
608 Samba-3 permits WINS replication through the use of the <tt class="filename">wrepld</tt> utility.
609 This tool is not currently capable of being used as it is still in active development.
610 As soon as this tool becomes moderately functional we will prepare man pages and enhance this
611 section of the documentation to provide usage and technical details.
612 </p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2905565"></a>Static WINS Entries</h3></div></div><div></div></div><p>
613 Adding static entries to your Samba-3 WINS server is actually fairly easy.
614 All you have to do is add a line to <tt class="filename">wins.dat</tt>, typically
615 located in <tt class="filename">/usr/local/samba/var/locks</tt>.
617 Entries in <tt class="filename">wins.dat</tt> take the form of
619 </p><pre class="programlisting">
620 "NAME#TYPE" TTL ADDRESS+ FLAGS
623 where NAME is the NetBIOS name, TYPE is the NetBIOS type, TTL is the
624 time-to-live as an absolute time in seconds, ADDRESS+ is one or more
625 addresses corresponding to the registration and FLAGS are the NetBIOS
626 flags for the registration.
628 A typical dynamic entry looks like:
629 </p><pre class="programlisting">
630 "MADMAN#03" 1055298378 192.168.1.2 66R
633 To make it static, all that has to be done is set the TTL to 0:
635 </p><pre class="programlisting">
636 "MADMAN#03" 0 192.168.1.2 66R
639 Though this method works with early Samba-3 versions, there's a
640 possibility that it may change in future versions if WINS replication
642 </p></div></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2905650"></a>Helpful Hints</h2></div></div><div></div></div><p>
643 The following hints should be carefully considered as they are stumbling points
644 for many new network administrators.
645 </p><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2905663"></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>
646 Do NOT use more than one (1) protocol on MS Windows machines
648 A very common cause of browsing problems results from installing more than
649 one protocol on an MS Windows machine.
651 Every NetBIOS machine takes part in a process of electing the LMB (and DMB)
652 every 15 minutes. A set of election criteria is used to determine the order
653 of precedence for winning this election process. A machine running Samba or
654 Windows NT will be biased so that the most suitable machine will predictably
655 win and thus retain it's role.
657 The election process is "fought out" so to speak over every NetBIOS network
658 interface. In the case of a Windows 9x machine that has both TCP/IP and IPX
659 installed and has NetBIOS enabled over both protocols the election will be
660 decided over both protocols. As often happens, if the Windows 9x machine is
661 the only one with both protocols then the LMB may be won on the NetBIOS
662 interface over the IPX protocol. Samba will then lose the LMB role as Windows
663 9x will insist it knows who the LMB is. Samba will then cease to function
664 as an LMB and thus browse list operation on all TCP/IP only machines will
666 </p><p><span class="emphasis"><em>
667 Windows 95, 98, 98se, Me are referred to generically as Windows 9x.
668 The Windows NT4, 2000, XP and 2003 use common protocols. These are roughly
669 referred to as the WinNT family, but it should be recognised that 2000 and
670 XP/2003 introduce new protocol extensions that cause them to behave
671 differently from MS Windows NT4. Generally, where a server does NOT support
672 the newer or extended protocol, these will fall back to the NT4 protocols.
674 The safest rule of all to follow it this - USE ONLY ONE PROTOCOL!
675 </p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2905730"></a>Name Resolution Order</h3></div></div><div></div></div><p>
676 Resolution of NetBIOS names to IP addresses can take place using a number
677 of methods. The only ones that can provide NetBIOS name_type information
679 </p><table class="simplelist" border="0" summary="Simple list"><tr><td>WINS: the best tool!</td></tr><tr><td>LMHOSTS: is static and hard to maintain.</td></tr><tr><td>Broadcast: uses UDP and can not resolve names across remote segments.</td></tr></table><p>
680 Alternative means of name resolution includes:
681 </p><table class="simplelist" border="0" summary="Simple list"><tr><td><tt class="filename">/etc/hosts</tt>: is static, hard to maintain, and lacks name_type info</td></tr><tr><td>DNS: is a good choice but lacks essential name_type info.</td></tr></table><p>
682 Many sites want to restrict DNS lookups and want to avoid broadcast name
683 resolution traffic. The <i class="parameter"><tt>name resolve order</tt></i> parameter is
684 of great help here. The syntax of the <i class="parameter"><tt>name resolve order</tt></i>
686 </p><pre class="programlisting">
687 name resolve order = wins lmhosts bcast host
689 <span class="emphasis"><em>or</em></span>
690 </p><pre class="programlisting">
691 name resolve order = wins lmhosts (eliminates bcast and host)
694 </p><pre class="programlisting">
695 name resolve order = host lmhost wins bcast
697 where "host" refers the the native methods used by the Unix system
698 to implement the gethostbyname() function call. This is normally
699 controlled by <tt class="filename">/etc/host.conf</tt>, <tt class="filename">/etc/nsswitch.conf</tt> and <tt class="filename">/etc/resolv.conf</tt>.
700 </p></div></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2905867"></a>Technical Overview of browsing</h2></div></div><div></div></div><p>
701 SMB networking provides a mechanism by which clients can access a list
702 of machines in a network, a so-called <i class="parameter"><tt>browse list</tt></i>. This list
703 contains machines that are ready to offer file and/or print services
704 to other machines within the network. Thus it does not include
705 machines which aren't currently able to do server tasks. The browse
706 list is heavily used by all SMB clients. Configuration of SMB
707 browsing has been problematic for some Samba users, hence this
710 MS Windows 2000 and later, as with Samba 3 and later, can be
711 configured to not use NetBIOS over TCP/IP. When configured this way,
712 it is imperative that name resolution (using DNS/LDAP/ADS) be correctly
713 configured and operative. Browsing will NOT work if name resolution
714 from SMB machine names to IP addresses does not function correctly.
716 Where NetBIOS over TCP/IP is enabled use of a WINS server is highly
717 recommended to aid the resolution of NetBIOS (SMB) names to IP addresses.
718 WINS allows remote segment clients to obtain NetBIOS name_type information
719 that can NOT be provided by any other means of name resolution.
720 </p><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2905914"></a>Browsing support in Samba</h3></div></div><div></div></div><p>
721 Samba facilitates browsing. The browsing is supported by <span class="application">nmbd</span>
722 and is also controlled by options in the <tt class="filename">smb.conf</tt> file.
723 Samba can act as a local browse master for a workgroup and the ability
724 to support domain logons and scripts is now available.
726 Samba can also act as a domain master browser for a workgroup. This
727 means that it will collate lists from local browse masters into a
728 wide area network server list. In order for browse clients to
729 resolve the names they may find in this list, it is recommended that
730 both Samba and your clients use a WINS server.
732 Note that you should NOT set Samba to be the domain master for a
733 workgroup that has the same name as an NT Domain: on each wide area
734 network, you must only ever have one domain master browser per workgroup,
735 regardless of whether it is NT, Samba or any other type of domain master
736 that is providing this service.
737 </p><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>
738 Nmbd can be configured as a WINS server, but it is not
739 necessary to specifically use Samba as your WINS server. MS Windows
740 NT4, Server or Advanced Server 2000 or 2003 can be configured as
741 your WINS server. In a mixed NT/2000/2003 server and Samba environment on
742 a Wide Area Network, it is recommended that you use the Microsoft
743 WINS server capabilities. In a Samba-only environment, it is
744 recommended that you use one and only one Samba server as your WINS server.
746 To get browsing to work you need to run nmbd as usual, but will need
747 to use the <i class="parameter"><tt>workgroup</tt></i> option in <tt class="filename">smb.conf</tt>
748 to control what workgroup Samba becomes a part of.
750 Samba also has a useful option for a Samba server to offer itself for
751 browsing on another subnet. It is recommended that this option is only
752 used for 'unusual' purposes: announcements over the internet, for
753 example. See <i class="parameter"><tt>remote announce</tt></i> in the
754 <tt class="filename">smb.conf</tt> man page.
755 </p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2906021"></a>Problem resolution</h3></div></div><div></div></div><p>
756 If something doesn't work then hopefully the log.nmbd file will help
757 you track down the problem. Try a debug level of 2 or 3 for finding
758 problems. Also note that the current browse list usually gets stored
759 in text form in a file called <tt class="filename">browse.dat</tt>.
761 Note that if it doesn't work for you, then you should still be able to
762 type the server name as <tt class="filename">\\SERVER</tt> in filemanager then
763 hit enter and filemanager should display the list of available shares.
765 Some people find browsing fails because they don't have the global
766 <i class="parameter"><tt>guest account</tt></i> set to a valid account. Remember that the
767 IPC$ connection that lists the shares is done as guest, and thus you must
768 have a valid guest account.
769 </p><p><span class="emphasis"><em>
770 MS Windows 2000 and upwards (as with Samba) can be configured to disallow
771 anonymous (ie: Guest account) access to the IPC$ share. In that case, the
772 MS Windows 2000/XP/2003 machine acting as an SMB/CIFS client will use the
773 name of the currently logged in user to query the IPC$ share. MS Windows
774 9X clients are not able to do this and thus will NOT be able to browse
777 The other big problem people have is that their broadcast address,
778 netmask or IP address is wrong (specified with the "interfaces" option
779 in <tt class="filename">smb.conf</tt>)
780 </p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2906100"></a>Browsing across subnets</h3></div></div><div></div></div><p>
781 Since the release of Samba 1.9.17(alpha1), Samba has supported the
782 replication of browse lists across subnet boundaries. This section
783 describes how to set this feature up in different settings.
785 To see browse lists that span TCP/IP subnets (ie. networks separated
786 by routers that don't pass broadcast traffic), you must set up at least
787 one WINS server. The WINS server acts as a DNS for NetBIOS names, allowing
788 NetBIOS name to IP address translation to be done by doing a direct
789 query of the WINS server. This is done via a directed UDP packet on
790 port 137 to the WINS server machine. The reason for a WINS server is
791 that by default, all NetBIOS name to IP address translation is done
792 by broadcasts from the querying machine. This means that machines
793 on one subnet will not be able to resolve the names of machines on
794 another subnet without using a WINS server.
796 Remember, for browsing across subnets to work correctly, all machines,
797 be they Windows 95, Windows NT, or Samba servers must have the IP address
798 of a WINS server given to them by a DHCP server, or by manual configuration
799 (for Win95 and WinNT, this is in the TCP/IP Properties, under Network
800 settings) for Samba this is in the <tt class="filename">smb.conf</tt> file.
801 </p><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2906150"></a>How does cross subnet browsing work ?</h4></div></div><div></div></div><p>
802 Cross subnet browsing is a complicated dance, containing multiple
803 moving parts. It has taken Microsoft several years to get the code
804 that achieves this correct, and Samba lags behind in some areas.
805 Samba is capable of cross subnet browsing when configured correctly.
807 Consider a network set up as follows :
810 </p><pre class="programlisting">
812 N1_A N1_B N1_C N1_D N1_E
814 -------------------------------------------------------
817 |R1 | Router 1 Router 2 |R2 |
820 | subnet 2 subnet 3 |
821 -------------------------- ------------------------------------
823 N2_A N2_B N2_C N2_D N3_A N3_B N3_C N3_D
827 Consisting of 3 subnets (1, 2, 3) connected by two routers
828 (R1, R2) - these do not pass broadcasts. Subnet 1 has 5 machines
829 on it, subnet 2 has 4 machines, subnet 3 has 4 machines. Assume
830 for the moment that all these machines are configured to be in the
831 same workgroup (for simplicity's sake). Machine N1_C on subnet 1
832 is configured as Domain Master Browser (ie. it will collate the
833 browse lists for the workgroup). Machine N2_D is configured as
834 WINS server and all the other machines are configured to register
835 their NetBIOS names with it.
837 As all these machines are booted up, elections for master browsers
838 will take place on each of the three subnets. Assume that machine
839 N1_C wins on subnet 1, N2_B wins on subnet 2, and N3_D wins on
840 subnet 3 - these machines are known as local master browsers for
841 their particular subnet. N1_C has an advantage in winning as the
842 local master browser on subnet 1 as it is set up as Domain Master
845 On each of the three networks, machines that are configured to
846 offer sharing services will broadcast that they are offering
847 these services. The local master browser on each subnet will
848 receive these broadcasts and keep a record of the fact that
849 the machine is offering a service. This list of records is
850 the basis of the browse list. For this case, assume that
851 all the machines are configured to offer services so all machines
852 will be on the browse list.
854 For each network, the local master browser on that network is
855 considered 'authoritative' for all the names it receives via
856 local broadcast. This is because a machine seen by the local
857 master browser via a local broadcast must be on the same
858 network as the local master browser and thus is a 'trusted'
859 and 'verifiable' resource. Machines on other networks that
860 the local master browsers learn about when collating their
861 browse lists have not been directly seen - these records are
862 called 'non-authoritative'.
864 At this point the browse lists look as follows (these are
865 the machines you would see in your network neighborhood if
866 you looked in it on a particular network right now).
868 </p><div class="table"><a name="id2906267"></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>
870 Note that at this point all the subnets are separate, no
871 machine is seen across any of the subnets.
873 Now examine subnet 2. As soon as N2_B has become the local
874 master browser it looks for a Domain master browser to synchronize
875 its browse list with. It does this by querying the WINS server
876 (N2_D) for the IP address associated with the NetBIOS name
877 WORKGROUP<1B>. This name was registered by the Domain master
878 browser (N1_C) with the WINS server as soon as it was booted.
880 Once N2_B knows the address of the Domain master browser it
881 tells it that is the local master browser for subnet 2 by
882 sending a MasterAnnouncement packet as a UDP port 138 packet.
883 It then synchronizes with it by doing a NetServerEnum2 call. This
884 tells the Domain Master Browser to send it all the server
885 names it knows about. Once the domain master browser receives
886 the MasterAnnouncement packet it schedules a synchronization
887 request to the sender of that packet. After both synchronizations
888 are done the browse lists look like :
890 </p><div class="table"><a name="id2906382"></a><p class="title"><b>Table 10.2. Browse subnet example 2</b></p><table summary="Browse subnet example 2" 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, N2_A(*), N2_B(*), N2_C(*), N2_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</td></tr></tbody></table></div><p>
892 Servers with a (*) after them are non-authoritative names.
894 At this point users looking in their network neighborhood on
895 subnets 1 or 2 will see all the servers on both, users on
896 subnet 3 will still only see the servers on their own subnet.
898 The same sequence of events that occured for N2_B now occurs
899 for the local master browser on subnet 3 (N3_D). When it
900 synchronizes browse lists with the domain master browser (N1_A)
901 it gets both the server entries on subnet 1, and those on
902 subnet 2. After N3_D has synchronized with N1_C and vica-versa
903 the browse lists look like.
905 </p><div class="table"><a name="id2906481"></a><p class="title"><b>Table 10.3. Browse subnet example 3</b></p><table summary="Browse subnet example 3" 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, 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>
907 Servers with a (*) after them are non-authoritative names.
909 At this point users looking in their network neighborhood on
910 subnets 1 or 3 will see all the servers on all subnets, users on
911 subnet 2 will still only see the servers on subnets 1 and 2, but not 3.
913 Finally, the local master browser for subnet 2 (N2_B) will sync again
914 with the domain master browser (N1_C) and will receive the missing
915 server entries. Finally - and as a steady state (if no machines
916 are removed or shut off) the browse lists will look like :
918 </p><div class="table"><a name="id2906581"></a><p class="title"><b>Table 10.4. Browse subnet example 4</b></p><table summary="Browse subnet example 4" 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, 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>
920 Servers with a (*) after them are non-authoritative names.
922 Synchronizations between the domain master browser and local
923 master browsers will continue to occur, but this should be a
924 steady state situation.
926 If either router R1 or R2 fails the following will occur:
927 </p><div class="orderedlist"><ol type="1"><li><p>
928 Names of computers on each side of the inaccessible network fragments
929 will be maintained for as long as 36 minutes, in the network neighbourhood
932 Attempts to connect to these inaccessible computers will fail, but the
933 names will not be removed from the network neighbourhood lists.
935 If one of the fragments is cut off from the WINS server, it will only
936 be able to access servers on its local subnet, by using subnet-isolated
937 broadcast NetBIOS name resolution. The effects are similar to that of
938 losing access to a DNS server.
939 </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="id2906720"></a>Common Errors</h2></div></div><div></div></div><p>
940 Many questions are asked on the mailing lists regarding browsing. The majority of browsing
941 problems originate out of incorrect configuration of NetBIOS name resolution. Some are of
943 </p><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2906735"></a>How can one flush the Samba NetBIOS name cache without restarting Samba?</h3></div></div><div></div></div><p>
944 Samba's nmbd process controls all browse list handling. Under normal circumstances it is
945 safe to restart nmbd. This will effectively flush the Samba NetBIOS name cache and cause it
946 to be rebuilt. Note that this does NOT make certain that a rogue machine name will not re-appear
947 in the browse list. When nmbd is taken out of service another machine on the network will
948 become the browse master. This new list may still have the rogue entry in it. If you really
949 want to clear a rogue machine from the list then every machine on the network will need to be
950 shut down and restarted at after all machines are down. Failing a complete restart, the only
951 other thing you can do is wait until the entry times out and is then flushed from the list.
952 This may take a long time on some networks (months).
953 </p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2906764"></a>My client reports "This server is not configured to list shared resources"</h3></div></div><div></div></div><p>
954 Your guest account is probably invalid for some reason. Samba uses the
955 guest account for browsing in smbd. Check that your guest account is
957 </p><p>See also <i class="parameter"><tt>guest account</tt></i> in the <tt class="filename">smb.conf</tt> man page.</p></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>
git.samba.org / sfrench / samba-autobuild / .git / blob