1 <chapter id="NetworkBrowsing">
4 <pubdate>July 5, 1998</pubdate>
5 <pubdate>Updated: April 21, 2003</pubdate>
8 <title>Samba / MS Windows Network Browsing Guide</title>
11 This document contains detailed information as well as a fast track guide to
12 implementing browsing across subnets and / or across workgroups (or domains).
13 WINS is the best tool for resolution of NetBIOS names to IP addresses. WINS is
14 NOT involved in browse list handling except by way of name to address resolution.
18 MS Windows 2000 and later can be configured to operate with NO NetBIOS
19 over TCP/IP. Samba-3 and later also supports this mode of operation.
20 When the use of NetBIOS over TCP/IP has been disabled then the primary
21 means for resolution of MS Windows machine names is via DNS and Active Directory.
22 The following information assumes that your site is running NetBIOS over TCP/IP.
26 <title>Features and Benefits</title>
29 Someone once referred to the past in terms of: <emphasis>They were the worst of times,
30 they were the best of times. The more we look back, them more we long for what was and
31 hope it never returns!</emphasis>.
35 For many MS Windows network administrators, that statement sums up their feelings about
36 NetBIOS networking precisely. For those who mastered NetBIOS networking, its fickle
37 nature was just par for the course. For those who never quite managed to tame its
38 lusty features, NetBIOS is like Paterson's Curse.
42 For those not familiar with botanical problems in Australia: Paterson's curse,
43 Echium plantagineum, was introduced to Australia from Europe during the mid-nineteenth
44 century. Since then it has spread rapidly. The high seed production, with densities of
45 thousands of seeds per square metre, a seed longevity of more than seven years, and an
46 ability to germinate at any time of year, given the right conditions, are some of the
47 features which make it such a persistent weed.
51 In this chapter we explore vital aspects of SMB (Server Message Block) networking with
52 a particular focus on SMB as implemented through running NetBIOS (Network Basic
53 Input / Output System) over TCP/IP. Since Samba does NOT implement SMB or NetBIOS over
54 any other protocols we need to know how to configure our network environment and simply
55 remember to use nothing but TCP/IP on all our MS Windows network clients.
59 Samba provides the ability to implement a WINS (Windows Internetworking Name Server)
60 and implements extensions to Microsoft's implementation of WINS. These extensions
61 help Samba to affect stable WINS operations beyond the normal scope of MS WINS.
65 Please note that WINS is exclusively a service that applies only to those systems
66 that run NetBIOS over TCP/IP. MS Windows 200x / XP have the capacity to turn off
67 support for NetBIOS, in which case WINS is of no relevance. Samba-3 supports this also.
71 For those networks on which NetBIOS has been disabled (ie: WINS is NOT required)
72 the use of DNS is necessary for host name resolution.
78 <title>What is Browsing?</title>
81 To most people browsing means that they can see the MS Windows and Samba servers
82 in the Network Neighborhood, and when the computer icon for a particular server is
83 clicked, it opens up and shows the shares and printers available on the target server.
87 What seems so simple is in fact a very complex interaction of different technologies.
88 The technologies (or methods) employed in making all of this work includes:
92 <member>MS Windows machines register their presence to the network</member>
93 <member>Machines announce themselves to other machines on the network</member>
94 <member>One or more machine on the network collates the local announcements</member>
95 <member>The client machine finds the machine that has the collated list of machines</member>
96 <member>The client machine is able to resolve the machine names to IP addresses</member>
97 <member>The client machine is able to connect to a target machine</member>
101 The Samba application that controls browse list management and name resolution is
102 called <filename>nmbd</filename>. The configuration parameters involved in nmbd's operation are:
105 <para><programlisting>
118 Name Resolution Method:
119 -----------------------
129 </programlisting></para>
132 For Samba, the WINS Server and WINS Support are mutually exclusive options. Those marked with
133 an '*' are the only options that commonly MAY need to be modified. Even if not one of these
134 parameters is set <filename>nmbd</filename> will still do it's job.
140 <title>Discussion</title>
143 Firstly, all MS Windows networking uses SMB (Server Message Block) based messaging.
144 SMB messaging may be implemented with or without NetBIOS. MS Windows 200x supports
145 NetBIOS over TCP/IP for backwards compatibility. Microsoft is intent on phasing out NetBIOS
150 <title>NetBIOS over TCP/IP</title>
153 Samba implements NetBIOS, as does MS Windows NT / 200x / XP, by encapsulating it over TCP/IP.
154 MS Windows products can do likewise. NetBIOS based networking uses broadcast messaging to
155 affect browse list management. When running NetBIOS over TCP/IP, this uses UDP based messaging.
156 UDP messages can be broadcast or unicast.
160 Normally, only unicast UDP messaging can be forwarded by routers. The
161 <command>remote announce</command> parameter to smb.conf helps to project browse announcements
162 to remote network segments via unicast UDP. Similarly, the
163 <command>remote browse sync</command> parameter of <filename>smb.conf</filename>
164 implements browse list collation using unicast UDP.
168 Secondly, in those networks where Samba is the only SMB server technology,
169 wherever possible <filename>nmbd</filename> should be configured on one (1) machine as the WINS
170 server. This makes it easy to manage the browsing environment. If each network
171 segment is configured with it's own Samba WINS server, then the only way to
172 get cross segment browsing to work is by using the
173 <command>remote announce</command> and the <command>remote browse sync</command>
174 parameters to your <filename>smb.conf</filename> file.
178 If only one WINS server is used for an entire multi-segment network then
179 the use of the <command>remote announce</command> and the
180 <command>remote browse sync</command> parameters should NOT be necessary.
184 As of Samba 3 WINS replication is being worked on. The bulk of the code has
185 been committed, but it still needs maturation. This is NOT a supported feature
186 of the Samba-3.0.0 release. Hopefully, this will become a supported feature
187 of one of the Samba-3 release series.
191 Right now Samba WINS does not support MS-WINS replication. This means that
192 when setting up Samba as a WINS server there must only be one <filename>nmbd</filename>
193 configured as a WINS server on the network. Some sites have used multiple Samba WINS
194 servers for redundancy (one server per subnet) and then used
195 <command>remote browse sync</command> and <command>remote announce</command>
196 to affect browse list collation across all segments. Note that this means clients
197 will only resolve local names, and must be configured to use DNS to resolve names
198 on other subnets in order to resolve the IP addresses of the servers they can see
199 on other subnets. This setup is not recommended, but is mentioned as a practical
200 consideration (ie: an 'if all else fails' scenario).
204 Lastly, take note that browse lists are a collection of unreliable broadcast
205 messages that are repeated at intervals of not more than 15 minutes. This means
206 that it will take time to establish a browse list and it can take up to 45
207 minutes to stabilise, particularly across network segments.
213 <title>TCP/IP - without NetBIOS</title>
216 All TCP/IP using systems use various forms of host name resolution. The primary
217 methods for TCP/IP hostname resolutions involves either a static file (<filename>/etc/hosts
218 </filename>) or DNS (the Domain Name System). DNS is the technology that makes
219 the Internet usable. DNS based host name resolution is supported by nearly all TCP/IP
220 enabled systems. Only a few embedded TCP/IP systems do not support DNS.
224 When an MS Windows 200x / XP system attempts to resolve a host name to an IP address
225 it follows a defined path:
230 Checks the <filename>hosts</filename> file. It is located in
231 <filename>C:\WinNT\System32\Drivers\etc</filename>.
239 Checks the NetBIOS name cache
243 Queries the WINS server
247 Does a broadcast name lookup over UDP
251 Looks up entries in LMHOSTS. It is located in
252 <filename>C:\WinNT\System32\Drivers\etc</filename>.
257 Windows 200x / XP can register it's host name with a Dynamic DNS server. You can
258 force register with a Dynamic DNS server in Windows 200x / XP using:
259 <command>ipconfig /registerdns</command>
263 With Active Directory (ADS), a correctly functioning DNS server is absolutely
264 essential. In the absence of a working DNS server that has been correctly configured,
265 MS Windows clients and servers will be totally unable to locate each other,
266 consequently network services will be severely impaired.
270 The use of Dynamic DNS is highly recommended with Active Directory, in which case
271 the use of BIND9 is preferred for it's ability to adequately support the SRV (service)
272 records that are needed for Active Directory.
278 <title>DNS and Active Directory</title>
281 Occasionally we hear from Unix network administrators who want to use a Unix based Dynamic
282 DNS server in place of the Microsoft DNS server. While this might be desirable to some, the
283 MS Windows 200x DNS server is auto-configured to work with Active Directory. It is possible
284 to use BIND version 8 or 9, but it will almost certainly be necessary to create service records
285 so that MS Active Directory clients can resolve host names to locate essential network services.
286 The following are some of the default service records that Active Directory requires:
290 <listitem><para>_ldap._tcp.pdc.ms-dcs.<emphasis>Domain</emphasis></para>
293 This provides the address of the Windows NT PDC for the Domain.
297 <listitem><para>_ldap._tcp.pdc.ms-dcs.<emphasis>DomainTree</emphasis></para>
300 Resolves the addresses of Global Catalog servers in the domain.
304 <listitem><para>_ldap._tcp.<emphasis>site</emphasis>.sites.writable.ms-dcs.<emphasis>Domain</emphasis></para>
306 Provides list of domain controllers based on sites.
310 <listitem><para>_ldap._tcp.writable.ms-dcs.<emphasis>Domain</emphasis></para>
313 Enumerates list of domain controllers that have the writable
314 copies of the Active Directory data store.
318 <listitem><para>_ldap._tcp.<emphasis>GUID</emphasis>.domains.ms-dcs.<emphasis>DomainTree</emphasis></para>
320 Entry used by MS Windows clients to locate machines using the
321 Global Unique Identifier.
325 <listitem><para>_ldap._tcp.<emphasis>Site</emphasis>.gc.ms-dcs.<emphasis>DomainTree</emphasis></para>
327 Used by MS Windows clients to locate site configuration dependent
328 Global Catalog server.
338 <title>How Browsing Functions</title>
341 MS Windows machines register their NetBIOS names
342 (ie: the machine name for each service type in operation) on start
343 up. The exact method by which this name registration
344 takes place is determined by whether or not the MS Windows client/server
345 has been given a WINS server address, whether or not LMHOSTS lookup
346 is enabled, or if DNS for NetBIOS name resolution is enabled, etc.
350 In the case where there is no WINS server, all name registrations as
351 well as name lookups are done by UDP broadcast. This isolates name
352 resolution to the local subnet, unless LMHOSTS is used to list all
353 names and IP addresses. In such situations Samba provides a means by
354 which the Samba server name may be forcibly injected into the browse
355 list of a remote MS Windows network (using the
356 <command>remote announce</command> parameter).
360 Where a WINS server is used, the MS Windows client will use UDP
361 unicast to register with the WINS server. Such packets can be routed
362 and thus WINS allows name resolution to function across routed networks.
366 During the startup process an election will take place to create a
367 local master browser if one does not already exist. On each NetBIOS network
368 one machine will be elected to function as the domain master browser. This
369 domain browsing has nothing to do with MS security domain control.
370 Instead, the domain master browser serves the role of contacting each local
371 master browser (found by asking WINS or from LMHOSTS) and exchanging browse
372 list contents. This way every master browser will eventually obtain a complete
373 list of all machines that are on the network. Every 11-15 minutes an election
374 is held to determine which machine will be the master browser. By the nature of
375 the election criteria used, the machine with the highest uptime, or the
376 most senior protocol version, or other criteria, will win the election
377 as domain master browser.
381 Clients wishing to browse the network make use of this list, but also depend
382 on the availability of correct name resolution to the respective IP
387 Any configuration that breaks name resolution and/or browsing intrinsics
388 will annoy users because they will have to put up with protracted
389 inability to use the network services.
393 Samba supports a feature that allows forced synchronisation
394 of browse lists across routed networks using the <command>remote
395 browse sync</command> parameter in the <filename>smb.conf</filename> file.
396 This causes Samba to contact the local master browser on a remote network and
397 to request browse list synchronisation. This effectively bridges
398 two networks that are separated by routers. The two remote
399 networks may use either broadcast based name resolution or WINS
400 based name resolution, but it should be noted that the <command>remote
401 browse sync</command> parameter provides browse list synchronisation - and
402 that is distinct from name to address resolution, in other
403 words, for cross subnet browsing to function correctly it is
404 essential that a name to address resolution mechanism be provided.
405 This mechanism could be via DNS, <filename>/etc/hosts</filename>,
410 <title>Setting up WORKGROUP Browsing</title>
413 To set up cross subnet browsing on a network containing machines
414 in up to be in a WORKGROUP, not an NT Domain you need to set up one
415 Samba server to be the Domain Master Browser (note that this is *NOT*
416 the same as a Primary Domain Controller, although in an NT Domain the
417 same machine plays both roles). The role of a Domain master browser is
418 to collate the browse lists from local master browsers on all the
419 subnets that have a machine participating in the workgroup. Without
420 one machine configured as a domain master browser each subnet would
421 be an isolated workgroup, unable to see any machines on any other
422 subnet. It is the presence of a domain master browser that makes
423 cross subnet browsing possible for a workgroup.
427 In an WORKGROUP environment the domain master browser must be a
428 Samba server, and there must only be one domain master browser per
429 workgroup name. To set up a Samba server as a domain master browser,
430 set the following option in the <parameter>[global]</parameter> section
431 of the &smb.conf; file :
441 The domain master browser should also preferrably be the local master
442 browser for its own subnet. In order to achieve this set the following
443 options in the <parameter>[global]</parameter> section of the &smb.conf; file :
450 preferred master = yes
456 The domain master browser may be the same machine as the WINS
457 server, if you require.
461 Next, you should ensure that each of the subnets contains a
462 machine that can act as a local master browser for the
463 workgroup. Any MS Windows NT/2K/XP/2003 machine should be
464 able to do this, as will Windows 9x machines (although these
465 tend to get rebooted more often, so it's not such a good idea
466 to use these). To make a Samba server a local master browser
467 set the following options in the <parameter>[global]</parameter> section of the
475 preferred master = yes
481 Do not do this for more than one Samba server on each subnet,
482 or they will war with each other over which is to be the local
487 The <parameter>local master</parameter> parameter allows Samba to act as a
488 local master browser. The <parameter>preferred master</parameter> causes nmbd
489 to force a browser election on startup and the <parameter>os level</parameter>
490 parameter sets Samba high enough so that it should win any browser elections.
494 If you have an NT machine on the subnet that you wish to
495 be the local master browser then you can disable Samba from
496 becoming a local master browser by setting the following
497 options in the <parameter>[global]</parameter> section of the
505 preferred master = no
513 <title>Setting up DOMAIN Browsing</title>
516 If you are adding Samba servers to a Windows NT Domain then
517 you must not set up a Samba server as a domain master browser.
518 By default, a Windows NT Primary Domain Controller for a domain
519 is also the Domain master browser for that domain, and many
520 things will break if a Samba server registers the Domain master
521 browser NetBIOS name (<replaceable>DOMAIN</replaceable><1B>)
522 with WINS instead of the PDC.
526 For subnets other than the one containing the Windows NT PDC
527 you may set up Samba servers as local master browsers as
528 described. To make a Samba server a local master browser set
529 the following options in the <command>[global]</command> section
530 of the &smb.conf; file :
537 preferred master = yes
543 If you wish to have a Samba server fight the election with machines
544 on the same subnet you may set the <parameter>os level</parameter> parameter
545 to lower levels. By doing this you can tune the order of machines that
546 will become local master browsers if they are running. For
547 more details on this see the section <link linkend="browse-force-master">
548 Forcing Samba to be the master browser</link>
553 If you have Windows NT machines that are members of the domain
554 on all subnets, and you are sure they will always be running then
555 you can disable Samba from taking part in browser elections and
556 ever becoming a local master browser by setting following options
557 in the <parameter>[global]</parameter> section of the &smb.conf;
565 preferred master = no
572 <sect2 id="browse-force-master">
573 <title>Forcing Samba to be the master</title>
576 Who becomes the <parameter>master browser</parameter> is determined by an election
577 process using broadcasts. Each election packet contains a number of parameters
578 which determine what precedence (bias) a host should have in the
579 election. By default Samba uses a very low precedence and thus loses
580 elections to just about anyone else.
584 If you want Samba to win elections then just set the <parameter>os level</parameter> global
585 option in &smb.conf; to a higher number. It defaults to 0. Using 34
586 would make it win all elections over every other system (except other
591 A <parameter>os level</parameter> of 2 would make it beat WfWg and Win95, but not MS Windows
592 NT/2K Server. A MS Windows NT/2K Server domain controller uses level 32.
595 <para>The maximum os level is 255</para>
598 If you want Samba to force an election on startup, then set the
599 <parameter>preferred master</parameter> global option in &smb.conf; to <constant>yes</constant>. Samba will
600 then have a slight advantage over other potential master browsers
601 that are not preferred master browsers. Use this parameter with
602 care, as if you have two hosts (whether they are Windows 95 or NT or
603 Samba) on the same local subnet both set with <parameter>preferred master</parameter> to
604 <constant>yes</constant>, then periodically and continually they will force an election
605 in order to become the local master browser.
609 If you want Samba to be a <parameter>domain master browser</parameter>, then it is
610 recommended that you also set <parameter>preferred master</parameter> to <constant>yes</constant>, because
611 Samba will not become a domain master browser for the whole of your
612 LAN or WAN if it is not also a local master browser on its own
613 broadcast isolated subnet.
617 It is possible to configure two Samba servers to attempt to become
618 the domain master browser for a domain. The first server that comes
619 up will be the domain master browser. All other Samba servers will
620 attempt to become the domain master browser every 5 minutes. They
621 will find that another Samba server is already the domain master
622 browser and will fail. This provides automatic redundancy, should
623 the current domain master browser fail.
629 <title>Making Samba the domain master</title>
632 The domain master is responsible for collating the browse lists of
633 multiple subnets so that browsing can occur between subnets. You can
634 make Samba act as the domain master by setting <parameter>domain master = yes</parameter>
635 in &smb.conf;. By default it will not be a domain master.
639 Note that you should <emphasis>not</emphasis> set Samba to be the domain master for a
640 workgroup that has the same name as an NT Domain.
644 When Samba is the domain master and the master browser, it will listen
645 for master announcements (made roughly every twelve minutes) from local
646 master browsers on other subnets and then contact them to synchronise
651 If you want Samba to be the domain master then I suggest you also set
652 the <parameter>os level</parameter> high enough to make sure it wins elections, and set
653 <parameter>preferred master</parameter> to <constant>yes</constant>, to get Samba to force an election on
658 Note that all your servers (including Samba) and clients should be
659 using a WINS server to resolve NetBIOS names. If your clients are only
660 using broadcasting to resolve NetBIOS names, then two things will occur:
666 your local master browsers will be unable to find a domain master
667 browser, as it will only be looking on the local subnet.
673 if a client happens to get hold of a domain-wide browse list, and
674 a user attempts to access a host in that list, it will be unable to
675 resolve the NetBIOS name of that host.
681 If, however, both Samba and your clients are using a WINS server, then:
687 your local master browsers will contact the WINS server and, as long as
688 Samba has registered that it is a domain master browser with the WINS
689 server, your local master browser will receive Samba's IP address
690 as its domain master browser.
696 when a client receives a domain-wide browse list, and a user attempts
697 to access a host in that list, it will contact the WINS server to
698 resolve the NetBIOS name of that host. as long as that host has
699 registered its NetBIOS name with the same WINS server, the user will
700 be able to see that host.
708 <title>Note about broadcast addresses</title>
711 If your network uses a "0" based broadcast address (for example if it
712 ends in a 0) then you will strike problems. Windows for Workgroups
713 does not seem to support a 0's broadcast and you will probably find
714 that browsing and name lookups won't work.
719 <title>Multiple interfaces</title>
722 Samba now supports machines with multiple network interfaces. If you
723 have multiple interfaces then you will need to use the <command>interfaces</command>
724 option in &smb.conf; to configure them.
728 <title>Use of the Remote Announce parameter</title>
730 The <parameter>remote announce</parameter> parameter of
731 <filename>smb.conf</filename> can be used to forcibly ensure
732 that all the NetBIOS names on a network get announced to a remote network.
733 The syntax of the <parameter>remote announce</parameter> parameter is:
735 remote announce = a.b.c.d [e.f.g.h] ...
737 <emphasis>or</emphasis>
739 remote announce = a.b.c.d/WORKGROUP [e.f.g.h/WORKGROUP] ...
744 <varlistentry><term><replaceable>a.b.c.d</replaceable> and
745 <replaceable>e.f.g.h</replaceable></term>
746 <listitem><para>is either the LMB (Local Master Browser) IP address
747 or the broadcast address of the remote network.
748 ie: the LMB is at 192.168.1.10, or the address
749 could be given as 192.168.1.255 where the netmask
750 is assumed to be 24 bits (255.255.255.0).
751 When the remote announcement is made to the broadcast
752 address of the remote network, every host will receive
753 our announcements. This is noisy and therefore
754 undesirable but may be necessary if we do NOT know
755 the IP address of the remote LMB.</para></listitem>
759 <term><replaceable>WORKGROUP</replaceable></term>
760 <listitem><para>is optional and can be either our own workgroup
761 or that of the remote network. If you use the
762 workgroup name of the remote network then our
763 NetBIOS machine names will end up looking like
764 they belong to that workgroup, this may cause
765 name resolution problems and should be avoided.
774 <title>Use of the Remote Browse Sync parameter</title>
777 The <parameter>remote browse sync</parameter> parameter of
778 <filename>smb.conf</filename> is used to announce to
779 another LMB that it must synchronise its NetBIOS name list with our
780 Samba LMB. It works ONLY if the Samba server that has this option is
781 simultaneously the LMB on its network segment.
785 The syntax of the <parameter>remote browse sync</parameter> parameter is:
788 remote browse sync = <replaceable>a.b.c.d</replaceable>
791 where <replaceable>a.b.c.d</replaceable> is either the IP address of the
792 remote LMB or else is the network broadcast address of the remote segment.
800 <title>WINS - The Windows Internetworking Name Server</title>
803 Use of WINS (either Samba WINS <emphasis>or</emphasis> MS Windows NT Server WINS) is highly
804 recommended. Every NetBIOS machine registers its name together with a
805 name_type value for each of several types of service it has available.
806 eg: It registers its name directly as a unique (the type 0x03) name.
807 It also registers its name if it is running the LanManager compatible
808 server service (used to make shares and printers available to other users)
809 by registering the server (the type 0x20) name.
813 All NetBIOS names are up to 15 characters in length. The name_type variable
814 is added to the end of the name - thus creating a 16 character name. Any
815 name that is shorter than 15 characters is padded with spaces to the 15th
816 character. ie: All NetBIOS names are 16 characters long (including the
817 name_type information).
821 WINS can store these 16 character names as they get registered. A client
822 that wants to log onto the network can ask the WINS server for a list
823 of all names that have registered the NetLogon service name_type. This saves
824 broadcast traffic and greatly expedites logon processing. Since broadcast
825 name resolution can not be used across network segments this type of
826 information can only be provided via WINS <emphasis>or</emphasis> via statically configured
827 <filename>lmhosts</filename> files that must reside on all clients in the
832 WINS also serves the purpose of forcing browse list synchronisation by all
833 LMB's. LMB's must synchronise their browse list with the DMB (domain master
834 browser) and WINS helps the LMB to identify it's DMB. By definition this
835 will work only within a single workgroup. Note that the domain master browser
836 has NOTHING to do with what is referred to as an MS Windows NT Domain. The
837 later is a reference to a security environment while the DMB refers to the
838 master controller for browse list information only.
842 Use of WINS will work correctly only if EVERY client TCP/IP protocol stack
843 has been configured to use the WINS server/s. Any client that has not been
844 configured to use the WINS server will continue to use only broadcast based
845 name registration so that WINS may NEVER get to know about it. In any case,
846 machines that have not registered with a WINS server will fail name to address
847 lookup attempts by other clients and will therefore cause workstation access
852 To configure Samba as a WINS server just add
853 <parameter>wins support = yes</parameter> to the <filename>smb.conf</filename>
854 file [globals] section.
858 To configure Samba to register with a WINS server just add
859 <parameter>wins server = a.b.c.d</parameter> to your &smb.conf; file <parameter>[globals]</parameter> section.
863 Never use both <parameter>wins support = yes</parameter> together
864 with <parameter>wins server = a.b.c.d</parameter>
865 particularly not using it's own IP address.
866 Specifying both will cause &nmbd; to refuse to start!
870 <title>Setting up a WINS server</title>
873 Either a Samba machine or a Windows NT Server machine may be set up
874 as a WINS server. To set a Samba machine to be a WINS server you must
875 add the following option to the &smb.conf; file on the selected machine :
876 in the <parameter>[globals]</parameter> section add the line
886 Versions of Samba prior to 1.9.17 had this parameter default to
887 yes. If you have any older versions of Samba on your network it is
888 strongly suggested you upgrade to a recent version, or at the very
889 least set the parameter to 'no' on all these machines.
893 Machines with <parameter>wins support = yes</parameter> will keep a list of
894 all NetBIOS names registered with them, acting as a DNS for NetBIOS names.
898 You should set up only ONE WINS server. Do NOT set the
899 <parameter>wins support = yes</parameter> option on more than one Samba
904 To set up a Windows NT Server as a WINS server you need to set up
905 the WINS service - see your NT documentation for details. Note that
906 Windows NT WINS Servers can replicate to each other, allowing more
907 than one to be set up in a complex subnet environment. As Microsoft
908 refuses to document these replication protocols, Samba cannot currently
909 participate in these replications. It is possible in the future that
910 a Samba->Samba WINS replication protocol may be defined, in which
911 case more than one Samba machine could be set up as a WINS server
912 but currently only one Samba server should have the
913 <parameter>wins support = yes</parameter> parameter set.
917 After the WINS server has been configured you must ensure that all
918 machines participating on the network are configured with the address
919 of this WINS server. If your WINS server is a Samba machine, fill in
920 the Samba machine IP address in the <guilabel>Primary WINS Server</guilabel> field of
921 the <guilabel>Control Panel->Network->Protocols->TCP->WINS Server</guilabel> dialogs
922 in Windows 95 or Windows NT. To tell a Samba server the IP address
923 of the WINS server add the following line to the <parameter>[global]</parameter> section of
924 all &smb.conf; files :
929 wins server = <name or IP address>
934 where <name or IP address> is either the DNS name of the WINS server
935 machine or its IP address.
939 Note that this line MUST NOT BE SET in the &smb.conf; file of the Samba
940 server acting as the WINS server itself. If you set both the
941 <parameter>wins support = yes</parameter> option and the
942 <parameter>wins server = <name></parameter> option then
943 nmbd will fail to start.
947 There are two possible scenarios for setting up cross subnet browsing.
948 The first details setting up cross subnet browsing on a network containing
949 Windows 95, Samba and Windows NT machines that are not configured as
950 part of a Windows NT Domain. The second details setting up cross subnet
951 browsing on networks that contain NT Domains.
957 <title>WINS Replication</title>
960 Samba-3 permits WINS replication through the use of the <filename>wrepld</filename> utility.
961 This tool is not currently capable of being used as it is still in active development.
962 As soon as this tool becomes moderately functional we will prepare man pages and enhance this
963 section of the documentation to provide usage and technical details.
968 <title>Static WINS Entries</title>
971 Adding static entries to your Samba-3 WINS server is actually fairly easy.
972 All you have to do is add a line to <filename>wins.dat</filename>, typically
973 located in <filename class="directory">/usr/local/samba/var/locks</filename>.
977 Entries in <filename>wins.dat</filename> take the form of
980 "NAME#TYPE" TTL ADDRESS+ FLAGS
983 where NAME is the NetBIOS name, TYPE is the NetBIOS type, TTL is the
984 time-to-live as an absolute time in seconds, ADDRESS+ is one or more
985 addresses corresponding to the registration and FLAGS are the NetBIOS
986 flags for the registration.
990 A typical dynamic entry looks like:
992 "MADMAN#03" 1055298378 192.168.1.2 66R
995 To make it static, all that has to be done is set the TTL to 0:
998 "MADMAN#03" 0 192.168.1.2 66R
1003 Though this method works with early Samba-3 versions, there's a
1004 possibility that it may change in future versions if WINS replication
1012 <title>Helpful Hints</title>
1015 The following hints should be carefully considered as they are stumbling points
1016 for many new network administrators.
1020 <title>Windows Networking Protocols</title>
1023 Do NOT use more than one (1) protocol on MS Windows machines
1027 A very common cause of browsing problems results from installing more than
1028 one protocol on an MS Windows machine.
1032 Every NetBIOS machine takes part in a process of electing the LMB (and DMB)
1033 every 15 minutes. A set of election criteria is used to determine the order
1034 of precedence for winning this election process. A machine running Samba or
1035 Windows NT will be biased so that the most suitable machine will predictably
1036 win and thus retain it's role.
1040 The election process is "fought out" so to speak over every NetBIOS network
1041 interface. In the case of a Windows 9x machine that has both TCP/IP and IPX
1042 installed and has NetBIOS enabled over both protocols the election will be
1043 decided over both protocols. As often happens, if the Windows 9x machine is
1044 the only one with both protocols then the LMB may be won on the NetBIOS
1045 interface over the IPX protocol. Samba will then lose the LMB role as Windows
1046 9x will insist it knows who the LMB is. Samba will then cease to function
1047 as an LMB and thus browse list operation on all TCP/IP only machines will
1052 Windows 95, 98, 98se, Me are referred to generically as Windows 9x.
1053 The Windows NT4, 2000, XP and 2003 use common protocols. These are roughly
1054 referred to as the WinNT family, but it should be recognised that 2000 and
1055 XP/2003 introduce new protocol extensions that cause them to behave
1056 differently from MS Windows NT4. Generally, where a server does NOT support
1057 the newer or extended protocol, these will fall back to the NT4 protocols.
1061 The safest rule of all to follow it this - USE ONLY ONE PROTOCOL!
1067 <title>Name Resolution Order</title>
1070 Resolution of NetBIOS names to IP addresses can take place using a number
1071 of methods. The only ones that can provide NetBIOS name_type information
1076 <member>WINS: the best tool!</member>
1077 <member>LMHOSTS: is static and hard to maintain.</member>
1078 <member>Broadcast: uses UDP and can not resolve names across remote segments.</member>
1082 Alternative means of name resolution includes:
1085 <member><filename>/etc/hosts</filename>: is static, hard to maintain, and lacks name_type info</member>
1086 <member>DNS: is a good choice but lacks essential name_type info.</member>
1090 Many sites want to restrict DNS lookups and want to avoid broadcast name
1091 resolution traffic. The <parameter>name resolve order</parameter> parameter is
1092 of great help here. The syntax of the <parameter>name resolve order</parameter>
1095 name resolve order = wins lmhosts bcast host
1097 <emphasis>or</emphasis>
1099 name resolve order = wins lmhosts (eliminates bcast and host)
1103 name resolve order = host lmhost wins bcast
1105 where "host" refers the the native methods used by the Unix system
1106 to implement the gethostbyname() function call. This is normally
1107 controlled by <filename>/etc/host.conf</filename>, <filename>/etc/nsswitch.conf</filename> and <filename>/etc/resolv.conf</filename>.
1113 <title>Technical Overview of browsing</title>
1116 SMB networking provides a mechanism by which clients can access a list
1117 of machines in a network, a so-called <parameter>browse list</parameter>. This list
1118 contains machines that are ready to offer file and/or print services
1119 to other machines within the network. Thus it does not include
1120 machines which aren't currently able to do server tasks. The browse
1121 list is heavily used by all SMB clients. Configuration of SMB
1122 browsing has been problematic for some Samba users, hence this
1127 MS Windows 2000 and later, as with Samba 3 and later, can be
1128 configured to not use NetBIOS over TCP/IP. When configured this way,
1129 it is imperative that name resolution (using DNS/LDAP/ADS) be correctly
1130 configured and operative. Browsing will NOT work if name resolution
1131 from SMB machine names to IP addresses does not function correctly.
1135 Where NetBIOS over TCP/IP is enabled use of a WINS server is highly
1136 recommended to aid the resolution of NetBIOS (SMB) names to IP addresses.
1137 WINS allows remote segment clients to obtain NetBIOS name_type information
1138 that can NOT be provided by any other means of name resolution.
1142 <title>Browsing support in Samba</title>
1145 Samba facilitates browsing. The browsing is supported by &nmbd;
1146 and is also controlled by options in the &smb.conf; file.
1147 Samba can act as a local browse master for a workgroup and the ability
1148 to support domain logons and scripts is now available.
1152 Samba can also act as a domain master browser for a workgroup. This
1153 means that it will collate lists from local browse masters into a
1154 wide area network server list. In order for browse clients to
1155 resolve the names they may find in this list, it is recommended that
1156 both Samba and your clients use a WINS server.
1160 Note that you should NOT set Samba to be the domain master for a
1161 workgroup that has the same name as an NT Domain: on each wide area
1162 network, you must only ever have one domain master browser per workgroup,
1163 regardless of whether it is NT, Samba or any other type of domain master
1164 that is providing this service.
1168 Nmbd can be configured as a WINS server, but it is not
1169 necessary to specifically use Samba as your WINS server. MS Windows
1170 NT4, Server or Advanced Server 2000 or 2003 can be configured as
1171 your WINS server. In a mixed NT/2000/2003 server and Samba environment on
1172 a Wide Area Network, it is recommended that you use the Microsoft
1173 WINS server capabilities. In a Samba-only environment, it is
1174 recommended that you use one and only one Samba server as your WINS server.
1178 To get browsing to work you need to run nmbd as usual, but will need
1179 to use the <parameter>workgroup</parameter> option in &smb.conf;
1180 to control what workgroup Samba becomes a part of.
1184 Samba also has a useful option for a Samba server to offer itself for
1185 browsing on another subnet. It is recommended that this option is only
1186 used for 'unusual' purposes: announcements over the internet, for
1187 example. See <parameter>remote announce</parameter> in the
1188 &smb.conf; man page.
1193 <title>Problem resolution</title>
1196 If something doesn't work then hopefully the log.nmbd file will help
1197 you track down the problem. Try a debug level of 2 or 3 for finding
1198 problems. Also note that the current browse list usually gets stored
1199 in text form in a file called <filename>browse.dat</filename>.
1203 Note that if it doesn't work for you, then you should still be able to
1204 type the server name as <filename>\\SERVER</filename> in filemanager then
1205 hit enter and filemanager should display the list of available shares.
1209 Some people find browsing fails because they don't have the global
1210 <parameter>guest account</parameter> set to a valid account. Remember that the
1211 IPC$ connection that lists the shares is done as guest, and thus you must
1212 have a valid guest account.
1216 MS Windows 2000 and upwards (as with Samba) can be configured to disallow
1217 anonymous (ie: Guest account) access to the IPC$ share. In that case, the
1218 MS Windows 2000/XP/2003 machine acting as an SMB/CIFS client will use the
1219 name of the currently logged in user to query the IPC$ share. MS Windows
1220 9X clients are not able to do this and thus will NOT be able to browse
1225 The other big problem people have is that their broadcast address,
1226 netmask or IP address is wrong (specified with the "interfaces" option
1232 <title>Browsing across subnets</title>
1234 Since the release of Samba 1.9.17(alpha1), Samba has supported the
1235 replication of browse lists across subnet boundaries. This section
1236 describes how to set this feature up in different settings.
1240 To see browse lists that span TCP/IP subnets (ie. networks separated
1241 by routers that don't pass broadcast traffic), you must set up at least
1242 one WINS server. The WINS server acts as a DNS for NetBIOS names, allowing
1243 NetBIOS name to IP address translation to be done by doing a direct
1244 query of the WINS server. This is done via a directed UDP packet on
1245 port 137 to the WINS server machine. The reason for a WINS server is
1246 that by default, all NetBIOS name to IP address translation is done
1247 by broadcasts from the querying machine. This means that machines
1248 on one subnet will not be able to resolve the names of machines on
1249 another subnet without using a WINS server.
1253 Remember, for browsing across subnets to work correctly, all machines,
1254 be they Windows 95, Windows NT, or Samba servers must have the IP address
1255 of a WINS server given to them by a DHCP server, or by manual configuration
1256 (for Win95 and WinNT, this is in the TCP/IP Properties, under Network
1257 settings) for Samba this is in the &smb.conf; file.
1261 <title>How does cross subnet browsing work ?</title>
1264 Cross subnet browsing is a complicated dance, containing multiple
1265 moving parts. It has taken Microsoft several years to get the code
1266 that achieves this correct, and Samba lags behind in some areas.
1267 Samba is capable of cross subnet browsing when configured correctly.
1271 Consider a network set up as follows :
1275 <!-- FIXME: Convert this to diagram -->
1278 N1_A N1_B N1_C N1_D N1_E
1280 -------------------------------------------------------
1283 |R1 | Router 1 Router 2 |R2 |
1286 | subnet 2 subnet 3 |
1287 -------------------------- ------------------------------------
1289 N2_A N2_B N2_C N2_D N3_A N3_B N3_C N3_D
1295 Consisting of 3 subnets (1, 2, 3) connected by two routers
1296 (R1, R2) - these do not pass broadcasts. Subnet 1 has 5 machines
1297 on it, subnet 2 has 4 machines, subnet 3 has 4 machines. Assume
1298 for the moment that all these machines are configured to be in the
1299 same workgroup (for simplicity's sake). Machine N1_C on subnet 1
1300 is configured as Domain Master Browser (ie. it will collate the
1301 browse lists for the workgroup). Machine N2_D is configured as
1302 WINS server and all the other machines are configured to register
1303 their NetBIOS names with it.
1307 As all these machines are booted up, elections for master browsers
1308 will take place on each of the three subnets. Assume that machine
1309 N1_C wins on subnet 1, N2_B wins on subnet 2, and N3_D wins on
1310 subnet 3 - these machines are known as local master browsers for
1311 their particular subnet. N1_C has an advantage in winning as the
1312 local master browser on subnet 1 as it is set up as Domain Master
1317 On each of the three networks, machines that are configured to
1318 offer sharing services will broadcast that they are offering
1319 these services. The local master browser on each subnet will
1320 receive these broadcasts and keep a record of the fact that
1321 the machine is offering a service. This list of records is
1322 the basis of the browse list. For this case, assume that
1323 all the machines are configured to offer services so all machines
1324 will be on the browse list.
1328 For each network, the local master browser on that network is
1329 considered 'authoritative' for all the names it receives via
1330 local broadcast. This is because a machine seen by the local
1331 master browser via a local broadcast must be on the same
1332 network as the local master browser and thus is a 'trusted'
1333 and 'verifiable' resource. Machines on other networks that
1334 the local master browsers learn about when collating their
1335 browse lists have not been directly seen - these records are
1336 called 'non-authoritative'.
1340 At this point the browse lists look as follows (these are
1341 the machines you would see in your network neighborhood if
1342 you looked in it on a particular network right now).
1347 <title>Browse subnet example 1</title>
1348 <tgroup align="left" cols="3">
1350 <row><entry>Subnet</entry><entry>Browse Master</entry><entry>List</entry></row>
1354 <row><entry>Subnet1</entry><entry>N1_C</entry><entry>N1_A, N1_B, N1_C, N1_D, N1_E</entry></row>
1355 <row><entry>Subnet2</entry><entry>N2_B</entry><entry>N2_A, N2_B, N2_C, N2_D</entry></row>
1356 <row><entry>Subnet3</entry><entry>N3_D</entry><entry>N3_A, N3_B, N3_C, N3_D</entry></row>
1363 Note that at this point all the subnets are separate, no
1364 machine is seen across any of the subnets.
1368 Now examine subnet 2. As soon as N2_B has become the local
1369 master browser it looks for a Domain master browser to synchronize
1370 its browse list with. It does this by querying the WINS server
1371 (N2_D) for the IP address associated with the NetBIOS name
1372 WORKGROUP<1B>. This name was registered by the Domain master
1373 browser (N1_C) with the WINS server as soon as it was booted.
1377 Once N2_B knows the address of the Domain master browser it
1378 tells it that is the local master browser for subnet 2 by
1379 sending a MasterAnnouncement packet as a UDP port 138 packet.
1380 It then synchronizes with it by doing a NetServerEnum2 call. This
1381 tells the Domain Master Browser to send it all the server
1382 names it knows about. Once the domain master browser receives
1383 the MasterAnnouncement packet it schedules a synchronization
1384 request to the sender of that packet. After both synchronizations
1385 are done the browse lists look like :
1390 <title>Browse subnet example 2</title>
1391 <tgroup align="left" cols="3">
1393 <row><entry>Subnet</entry><entry>Browse Master</entry><entry>List</entry></row>
1397 <row><entry>Subnet1</entry><entry>N1_C</entry><entry>N1_A, N1_B, N1_C, N1_D, N1_E, N2_A(*), N2_B(*), N2_C(*), N2_D(*)</entry></row>
1398 <row><entry>Subnet2</entry><entry>N2_B</entry><entry>N2_A, N2_B, N2_C, N2_D, N1_A(*), N1_B(*), N1_C(*), N1_D(*), N1_E(*)</entry></row>
1399 <row><entry>Subnet3</entry><entry>N3_D</entry><entry>N3_A, N3_B, N3_C, N3_D</entry></row>
1404 Servers with a (*) after them are non-authoritative names.
1408 At this point users looking in their network neighborhood on
1409 subnets 1 or 2 will see all the servers on both, users on
1410 subnet 3 will still only see the servers on their own subnet.
1414 The same sequence of events that occured for N2_B now occurs
1415 for the local master browser on subnet 3 (N3_D). When it
1416 synchronizes browse lists with the domain master browser (N1_A)
1417 it gets both the server entries on subnet 1, and those on
1418 subnet 2. After N3_D has synchronized with N1_C and vica-versa
1419 the browse lists look like.
1424 <title>Browse subnet example 3</title>
1425 <tgroup cols="3" align="left">
1427 <row><entry>Subnet</entry><entry>Browse Master</entry><entry>List</entry></row>
1431 <row><entry>Subnet1</entry><entry>N1_C</entry><entry>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(*)</entry></row>
1432 <row><entry>Subnet2</entry><entry>N2_B</entry><entry>N2_A, N2_B, N2_C, N2_D, N1_A(*), N1_B(*), N1_C(*), N1_D(*), N1_E(*)</entry></row>
1433 <row><entry>Subnet3</entry><entry>N3_D</entry><entry>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(*)</entry></row>
1438 Servers with a (*) after them are non-authoritative names.
1442 At this point users looking in their network neighborhood on
1443 subnets 1 or 3 will see all the servers on all subnets, users on
1444 subnet 2 will still only see the servers on subnets 1 and 2, but not 3.
1448 Finally, the local master browser for subnet 2 (N2_B) will sync again
1449 with the domain master browser (N1_C) and will receive the missing
1450 server entries. Finally - and as a steady state (if no machines
1451 are removed or shut off) the browse lists will look like :
1456 <title>Browse subnet example 4</title>
1457 <tgroup cols="3" align="left">
1459 <row><entry>Subnet</entry><entry>Browse Master</entry><entry>List</entry></row>
1463 <row><entry>Subnet1</entry><entry>N1_C</entry><entry>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(*)</entry></row>
1464 <row><entry>Subnet2</entry><entry>N2_B</entry><entry>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(*)</entry></row>
1465 <row><entry>Subnet3</entry><entry>N3_D</entry><entry>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(*)</entry></row>
1470 Servers with a (*) after them are non-authoritative names.
1474 Synchronizations between the domain master browser and local
1475 master browsers will continue to occur, but this should be a
1476 steady state situation.
1480 If either router R1 or R2 fails the following will occur:
1486 Names of computers on each side of the inaccessible network fragments
1487 will be maintained for as long as 36 minutes, in the network neighbourhood
1494 Attempts to connect to these inaccessible computers will fail, but the
1495 names will not be removed from the network neighbourhood lists.
1501 If one of the fragments is cut off from the WINS server, it will only
1502 be able to access servers on its local subnet, by using subnet-isolated
1503 broadcast NetBIOS name resolution. The effects are similar to that of
1504 losing access to a DNS server.
1513 <title>Common Errors</title>
1516 Many questions are asked on the mailing lists regarding browsing. The majority of browsing
1517 problems originate out of incorrect configuration of NetBIOS name resolution. Some are of
1522 <title>How can one flush the Samba NetBIOS name cache without restarting Samba?</title>
1525 Samba's nmbd process controls all browse list handling. Under normal circumstances it is
1526 safe to restart nmbd. This will effectively flush the Samba NetBIOS name cache and cause it
1527 to be rebuilt. Note that this does NOT make certain that a rogue machine name will not re-appear
1528 in the browse list. When nmbd is taken out of service another machine on the network will
1529 become the browse master. This new list may still have the rogue entry in it. If you really
1530 want to clear a rogue machine from the list then every machine on the network will need to be
1531 shut down and restarted at after all machines are down. Failing a complete restart, the only
1532 other thing you can do is wait until the entry times out and is then flushed from the list.
1533 This may take a long time on some networks (months).
1539 <title>My client reports "This server is not configured to list shared resources"</title>
1542 Your guest account is probably invalid for some reason. Samba uses the
1543 guest account for browsing in smbd. Check that your guest account is
1547 <para>See also <parameter>guest account</parameter> in the &smb.conf; man page.</para>