A NetBIOS name is similar to a computer’s DNS hostname (without the domain name component). It’s a string of up to 15 characters that can contain letters, numbers, and various punctuation marks. (Using punctuation can be confusing, though, and so is usually best avoided.) NetBIOS names are case-insensitive, although I generally present them in all-uppercase in this book to distinguish them from DNS hostnames, which I present in lowercase.

You set your computer’s NetBIOS name with the global netbios name parameter:

netbios name = MANDRAKE

If you don’t include this parameter in the smb.conf file, the default is to use your computer’s DNS hostname, minus the domain component. For instance, if your computer is called mandrake.greenhouse.example.com, Samba registers the NetBIOS name MANDRAKE. This default is usually reasonable, assuming your DNS hostname is set correctly; however, you may want to set the NetBIOS name explicitly just to be sure. (When you do so, this setting overrides the DNS hostname for NetBIOS purposes but not for other TCP/IP protocols.) In most cases, you shouldn’t try to use different NetBIOS and DNS names on a single computer because it will most likely confuse your users.

Occasionally, you may want to give a computer multiple NetBIOS names. Samba supports this option via the global netbios aliases parameter, which enables you to specify names to be registered in addition to the name provided with netbios name (or the DNS hostname, if you omit netbios name from your smb.conf file). For instance, suppose that MANDRAKE should also be known as MANDRAGORA and MANDRAGORIN>. You can do so by using the following line in addition to the netbios name line shown earlier:

netbios aliases = MANDRAGORA MANDRAGORIN

You can use this parameter to give a system multiple NetBIOS names if it also has multiple DNS hostnames. You can also use it to consolidate several servers in one. For instance, if you replace two old file server computers with one new server, you can have the new server appear under both names by assigning one name with netbios name and the second with netbios aliases. You’ll need to define file or printer shares to match those found on both original servers, though.

NetBIOS name resolution can work in any of several ways. The most common methods are broadcast name resolution and a NetBIOS Name Server (NBNS) computer, a.k.a. a Windows Internet Name Service (WINS) system. In broadcast name resolution, a client sends a broadcast that contains the name of the system it wants to contact, and that system responds to the broadcasts. Broadcast name resolution is easy to configure (no special Samba parameters are required), but it doesn’t work well in networks with multiple subnets.

If your network includes an NBNS system, you should point Samba at it with the global wins server parameter, which requires the IP address (or DNS hostname, if you also set hostname lookups = Yes) of the NBNS system:

wins server = 172.24.21.1

Samba 3.0 and later supports multiple NBNS systems (separated by spaces or commas on the wins server line).

Conceptually, you can consider an NBNS system to be much like a DNS server; clients contact it to turn names into IP addresses. Unlike a DNS server, though, an NBNS system requires no explicit configuration to add hostnames to it. Instead, clients contact the NBNS system when they start up and at various times thereafter in order to register their configured names. The wins server parameter has the dual effect of telling Samba (or nmbd, to be more precise) to register with the NBNS system and to use that system for NBNS lookups, when they’re required.

While you’re setting the wins server option, you should check to be sure that wins support is set to No. If this value is Yes, Samba attempts to operate as an NBNS system. This is likely to cause confusion if your network has an existing NBNS system. Of course, if you really want your computer to take on these duties, you should set wins support = Yes, but, in this case, you should omit the wins server parameter; Samba knows to refer to itself for this function when it’s configured as an NBNS system.

You can tell Samba which name lookup methods to use with the name resolve order parameter, which takes an ordered list of one to four values:

The default name resolution order is lmhosts host wins bcast, but you can remove options or change their order by specifying them with name resolve order:

name resolve order = wins bcast lmhosts

This example causes NBNS lookups to be tried first, followed by broadcasts, followed by lmhosts lookups. In this example, ordinary TCP/IP hostname lookups are not attempted by Samba.

The NetBIOS naming system is basically flat; all computers on a network have names in the same namespace, with no hierarchical structure. This contrasts with DNS names, which provide for an arbitrary number of domains and subdomains. NetBIOS avoids name conflicts primarily by restricting the scope of the network; NetBIOS name broadcasts don’t normally pass over routers, and NBNS computers typically serve just one organization’s computers.

NetBIOS does provide the illusion of a two-tiered structure, though, through the use of workgroups and NT domains. On a conceptual level, a workgroup is a collection of computers that are related in some way, such as those in a single department. On a technical level, workgroups are implemented by having members of the workgroup register NetBIOS names based on the workgroup name and using particular service type codes.

In any event, you must tell Samba the name of the workgroup to which it belongs. You do this with the global workgroup parameter, which takes a workgroup name as its value. These names follow the same naming rules as NetBIOS machine names, but because the computer’s DNS domain name is less likely to be a suitable substitute, it’s not used as the default value. Instead, the default if you omit the workgroup parameter is a compile-time option, but it’s usually WORKGROUP.

If you fail to set the computer’s workgroup correctly, you may not be able to browse to the server from Windows clients, or the server may appear under its own unique workgroup in the clients’ browsers. Thus, it’s important that you set this option appropriately for your network. If you’re configuring a new network, select a workgroup name as you see fit. Perhaps your organization’s domain name will work, or maybe a subdomain name will be more appropriate. In some cases, you might even use something unrelated, but to avoid confusion, it’s usually best to employ a DNS domain or subdomain name as the workgroup name.

In addition to setting the NetBIOS name, workgroup name, and related options, you may need to attend to a few miscellaneous identification parameters. These can affect how other systems interact with your Samba server:

Chances are you’ll only want to set the server string parameter, which has a direct effect on clients. This is shown in Figure 3-1, which depicts a Windows XP computer’s view of the servers on a network using the My Network Places browsing tool. In most cases, the NetBIOS name appears in parentheses after the value of the server string variable. (HALRLOPRILLALAR Figure 3-1 is an exception because it lacks the server string value, or rather, it lacks its equivalent because this computer is the Windows computer used to take the screen shot.) Many default smb.conf files place the %v variable in the server string parameter, which has the effect of displaying the Samba version number to clients, as in the TEELA server in Figure 3-1. This information, though, can be useful to miscreants wanting to break into the computer. To be sure, they can discover the version in some other way, but there’s no point in making it easy for them; I recommend not using %v in your server string parameter.

Figure 3-1. Windows displays the value of the server string variable alongside the NetBIOS name in its network browser