Using Samba

If everything is properly configured, we should be able to see the Samba server, hydra, through the Network Neighborhood of the phoenix Windows desktop. In fact, Figure 1.2 shows the Network Neighborhood of the phoenix computer, including hydra and each of the computers that reside in the SIMPLE workgroup. Note the Entire Network icon at the top of the list. As we just mentioned, there can be more than one workgroup on an SMB network at any given time. If a user clicks on the Entire Network icon, he or she will see a list of all the workgroups that currently exist on the network.

Figure 1.2. The Network Neighborhood directory

We can take a closer look at the hydra server by double-clicking on its icon. This contacts hydra itself and requests a list of its shares—the file and printer resources—that the machine provides. In this case, there is a printer entitled lp and a disk share entitled network on the server, as shown in Figure 1.3. Note that the Windows display shows hostnames in mixed case (Hydra). Case is irrelevant in hostnames, so you may see hydra, Hydra, and HYDRA in various displays or command output, but they all refer to a single system. Thanks to Samba, Windows 98 sees the Unix server as a valid SMB server, and can access the network folder as if it were just another system folder.

Figure 1.3. Shares available on the hydra sever as viewed from phoenix

One popular feature of Windows 95/98/NT is that you can map a letter-drive to a known network directory using the Map Network Drive option in the Windows Explorer.^[3] Once you do so, your applications can access the folder across the network with a standard drive letter. Hence, you can store data on it, install and run programs from it, and even password-protect it against unwanted visitors. See Figure 1.4 for an example of mapping a letter-drive to a network directory.

Figure 1.4. Mapping a network drive to a Windows letter-drive

Take a look at the Path: entry in the dialog box of Figure 1.4. An equivalent way to represent a directory on a network machine is by using two backslashes, followed by the name of the networked machine, another backslash, and the networked directory of the machine, as shown below:

\\network-machine\directory

This is known as the UNC (Universal Naming Convention) in the Windows world. For example, the dialog box in Figure 1.4 represents the network directory on the hydra server as:

\\HYDRA\network

If this looks somewhat familiar to you, you're probably thinking of uniform resource locators (URLs), which are addresses that web browsers such as Netscape Navigator and Internet Explorer use to resolve machines across the Internet. Be sure not to confuse the two: web browsers typically use forward slashes instead of back slashes, and they precede the initial slashes with the data transfer protocol (i.e., ftp, http) and a colon (:). In reality, URLs and UNCs are two completely separate things.

Once the network drive is set up, Windows and its programs will behave as if the networked directory was a fixed disk. If you have any applications that support multiuser functionality on a network, you can install those programs on the network drive.^[4] Figure 1.5 shows the resulting network drive as it would appear with other storage devices in the Windows 98 client. Note the pipeline attachment in the icon for the G: drive; this indicates that it is a network drive instead of a fixed drive.

Figure 1.5. The Network directory mapped to the client letter-drive G

From our Windows NT Workstation machine, chimaera, Samba looks almost identical to Windows 98. Figure 1.6 shows the same view of the hydra server from the Windows NT 4.0 Network Neighborhood. Setting up the network drive using the Map Network Drive option in Windows NT Workstation 4.0 would have identical results as well.

Figure 1.6. Shares available on hydra (viewed from chimaera)

You probably noticed that the printer lp appeared under the available shares for hydra in Figure 1.3. This indicates that the Unix server has a printer that can be shared by the various SMB clients in the workgroup. Data sent to the printer from any of the clients will be spooled on the Unix server and printed in the order it is received.

Setting up a Samba-enabled printer on the Windows side is even easier than setting up a disk share. By double-clicking on the printer and identifying the manufacturer and model, you can install a driver for this printer on the Windows client. Windows can then properly format any information sent to the network printer and access it as if it were a local printer (we show you how to do this later in the chapter). Figure 1.7 shows the resulting network printer in the Printers window of Windows 98. Again, note the pipeline attachment below the printer, which identifies it as being on a network.

Figure 1.7. A network printer available on hydra (viewed from chimaera)

# smbstatus
Samba version 2.0.4
Service      uid      gid      pid     machine
----------------------------------------------
network      davecb   davecb   7470   phoenix  (192.168.220.101) Sun May 16
network      davecb   davecb   7589   chimaera (192.168.220.102) Sun May 16

Locked files:
Pid    DenyMode   R/W        Oplock          Name
--------------------------------------------------
7589   DENY_NONE  RDONLY     EXCLUSIVE+BATCH /home/samba/quicken/inet/common/system/help.bmp   Sun May 16 21:23:40 1999
7470   DENY_WRITE RDONLY     NONE            /home/samba/word/office/findfast.exe
Sun May 16 20:51:08 1999
7589   DENY_WRITE RDONLY     EXCLUSIVE+BATCH /home/samba/quicken/lfbmp70n.dll   Sun May 16 21:23:39 1999
7589   DENY_WRITE RDWR       EXCLUSIVE+BATCH /home/samba/quicken/inet/qdata/runtime.dat   Sun May 16 21:23:41 1999
7470   DENY_WRITE RDONLY     EXCLUSIVE+BATCH /home/samba/word/office/osa.exe
Sun May 16 20:51:09 1999
7589   DENY_WRITE RDONLY     NONE            /home/samba/quicken/qversion.dll   Sun May 16 21:20:33 1999
7470   DENY_WRITE RDONLY     NONE                             /home/samba/quicken/qversion.dll   Sun May 16 20:51:11 1999

Share mode memory usage (bytes):
   1043432(99%) free + 4312(0%) used + 832(0%) overhead = 1048576(100%) total

To begin, let's step back in time. In 1984, IBM authored a simple application programming interface (API) for networking its computers called the Network Basic Input/Output System (NetBIOS). The NetBIOS API provided a rudimentary design for an application to connect and share data with other computers.

It's helpful to think of the NetBIOS API as networking extensions to the standard BIOS API calls. With BIOS, each low-level call is confined to the hardware of the local machine and doesn't need any help traveling to its destination. NetBIOS, however, originally had to exchange instructions with computers across IBM PC or Token Ring networks. It therefore required a low-level transport protocol to carry its requests from one computer to the next.

In late 1985, IBM released one such protocol, which it merged with the NetBIOS API to become the NetBIOS Extended User Interface (NetBEUI). NetBEUI was designed for small local area networks (LANs), and it let each machine claim a name (up to 15 characters) that wasn't already in use on the network. By a "small LAN," we mean fewer than 255 nodes on the network—which was considered a practical restriction in 1985!

The NetBEUI protocol was very popular with networking applications, including those running under Windows for Workgroups. Later, implementations of NetBIOS over Novell's IPX networking protocols also emerged, which competed with NetBEUI. However, the networking protocols of choice for the burgeoning Internet community were TCP/IP and UDP/IP, and implementing the NetBIOS APIs over those protocols soon became a necessity.

Recall that TCP/IP uses numbers to represent computer addresses, such as 192.168.220.100, while NetBIOS uses only names. This was a major issue when trying to mesh the two protocols together. In 1987, the Internet Engineering Task Force (IETF) published a series of standardization documents, titled RFC 1001 and 1002, that outlined how NetBIOS would work over a TCP/UDP network. This set of documents still governs each of the implementations that exist today, including those provided by Microsoft with their Windows operating systems as well as the Samba suite.

Since then, the standard this document governs has become known as NetBIOS over TCP/IP , or NBT for short. The NBT standard (RFC 1001/1002) currently outlines a trio of services on a network:

The name service solves the name-to-address problem mentioned earlier; it allows each computer to declare a specific name on the network that can be translated to a machine-readable IP address, much like today's DNS on the Internet. The datagram and session services are both secondary communication protocols used to transmit data back and forth from NetBIOS machines across the network.

For a human being, getting a name is easy. However, for a machine on a NetBIOS network, it can be a little more complicated. Let's look at a few of the issues.

In the NetBIOS world, when each machine comes online, it wants to claim a name for itself; this is called name registration . However, no two machines in the same workgroup should be able to claim the same name; this would cause endless confusion for any machine that wanted to communicate with either machine. There are two different approaches to ensuring that this doesn't happen:

Figure 1.8 illustrates a (failed) name registration, with and without a NetBIOS Name Server.

Figure 1.8. NBNS versus non-NBNS name registration

In addition, there must be a way to resolve a NetBIOS name to a specific IP address as mentioned earlier; this is known as name resolution . There are two different approaches with NBT here as well:

Figure 1.9 illustrates the two types of name resolution.

Figure 1.9. NBNS versus non-NBNS name resolution

As you might expect, having an NBNS on your network can help out tremendously. To see exactly why, let's look at the non-NBNS method.

Here, when a client machine boots, it will broadcast a message declaring that it wishes to register a specified NetBIOS name as its own. If nobody objects to the use of the name after multiple registration attempts, it keeps the name. On the other hand, if another machine on the local subnet is currently using the requested name, it will send a message back to the requesting client that the name is already taken. This is known as defending the hostname. This type of system comes in handy when one client has unexpectedly dropped off the network—another can take its name unchallenged—but it does incur an inordinate amount of traffic on the network for something as simple as name registration.

With an NBNS, the same thing occurs, except that the communication is confined to the requesting machine and the NBNS server. No broadcasting occurs when the machine wishes to register the name; the registration message is simply sent directly from the client to NBNS server and the NBNS server replies whether or not the name is already taken. This is known as point-to-point communication , and is often beneficial on networks with more than one subnet. This is because routers are often preconfigured to block incoming packets that are broadcast to all machines in the subnet.

The same principles apply to name resolution. Without an NBNS, NetBIOS name resolution would also be done with a broadcast mechanism. All request packets would be sent to each computer in the network, with the hope that one machine that might be affected will respond directly back to the machine that asked. At this point, it's clear that using an NBNS server and point-to-point communication for this purpose is far less taxing on the network than flooding the network with broadcasts for every name resolution request.

How can you tell what strategy each client on your network will use when performing name registration and resolution? Each machine on an NBT network earns one of the following designations, depending on how it handles name registration and resolution: b-node, p-node, m-node, and h-node. The behaviors of each type of node are summarized in Table 1.1.

In the case of Windows clients, you will usually find them listed as h-nodes or hybrid nodes. Incidentally, h-nodes were invented later by Microsoft, as a more fault-tolerant route, and do not appear in RFC 1001/1002.

You can find out the node type of any Windows machine by typing the command ipconfig /all and searching for the line that says Node Type.

C:\>ipconfig /all
Windows 98 IP Configuration
...
  Node Type .  .  .  .  .  .  .  .  .  .  : Hybrid
...

The names NetBIOS uses are quite different from the DNS hostnames you might be familiar with. First, NetBIOS names exist in a flat namespace. In other words, there are no qualifiers such as ora.com or samba.org to section off hostnames; there is only a single unique name to represent each computer. Second, NetBIOS names are allowed to be only 15 characters, may not begin with an asterisk (*), and can consist only of standard alphanumeric characters (a-z, A-Z, 0-9) and the following:

! @ # $ % ^ & ( ) - ' { } . ~

Although you are allowed to use a period (.) in a NetBIOS name, we recommend against it because those names are not guaranteed to work in future versions of NetBIOS over TCP/IP.

It's not a coincidence that all valid DNS names are also valid NetBIOS names. In fact, the DNS name for a Samba server is often reused as its NetBIOS name. For example, if you had a machine phoenix.ora.com , its NetBIOS name would likely be PHOENIX (followed by 8 blanks).

Resource names and types

With NetBIOS, a machine not only advertises its presence, but also tells others what types of services it offers. For example, phoenix can indicate that it's not just a workstation, but is also a file server and can receive WinPopup messages. This is done by adding a 16th byte to the end of the machine (resource) name, called the resource type, and registering the name more than once. See Figure 1.10.

Figure 1.10. The structure of NetBIOS names

The one-byte resource type indicates a unique service the named machine provides. In this book, you will often see the resource type shown in angled brackets (<>) after the NetBIOS name, such as:

PHOENIX<00>

You can see which names are registered for a particular NBT machine using the Windows command-line NBTSTAT utility. Because these services are unique (i.e., there cannot be more than one registered), you will see them listed as type UNIQUE in the output. For example, the following partial output describes the hydra server:

D:\>NBTSTAT -a hydra

       NetBIOS Remote Machine Name Table
   Name               Type         Status
---------------------------------------------
HYDRA          <00>  UNIQUE      Registered
HYDRA          <03>  UNIQUE      Registered
HYDRA          <20>  UNIQUE      Registered
...

This says the server has registered the NetBIOS name hydra as a machine (workstation) name, a recipient of WinPopup messages, and a file server. Some possible attributes a name can have are listed in Table 1.2.

Table 1.2. NetBIOS Unique Resource Types

Named Resource	Hexidecimal Byte Value
Standard Workstation Service	00
Messenger Service (WinPopup)	03
RAS Server Service	06
Domain Master Browser Service (associated with primary domain controller)	1B
Master Browser name	1D
NetDDE Service	1F
Fileserver (including printer server)	20
RAS Client Service	21
Network Monitor Agent	BE
Network Monitor Utility	BF

Note that because DNS names don't have resource types, the designers intentionally made hexidecimal value 20 (an ASCII space) default to the type for a file server.

       NetBIOS Remote Machine Name Table, continued
   Name               Type         Status
---------------------------------------------
SIMPLE           <00>  GROUP       Registered
SIMPLE           <1E>  GROUP       Registered
.._ _MSBROWSE_ _.<01>  GROUP       Registered

At this point, let's digress to introduce another responsibility of NBT: to provide connection services between two NetBIOS machines. There are actually two services offered by NetBIOS over TCP/IP: the session service and the datagram service. Understanding how these two services work is not essential to using Samba, but it does give you an idea of how NBT works and how to troubleshoot Samba when it doesn't work.

The datagram service has no stable connection between one machine and another. Packets of data are simply sent or broadcast from one machine to another, without regard for the order that they arrive at the destination, or even if they arrive at all. The use of datagrams is not as network intensive as sessions, although they can bog down a network if used unwisely (remember broadcast name resolution earlier?) Datagrams, therefore, are used for quickly sending simple blocks of data to one or more machines. The datagram service communicates using the simple primitives shown in Table 1.4.

The session service is more complex. Sessions are a communication method that, in theory, offers the ability to detect problematic or inoperable connections between two NetBIOS applications. It helps to think of an NBT session in terms of a telephone call.^[5] A full-duplex connection is opened between a caller machine and a called machine, and it must remain open throughout the duration of their conversation. Each side knows who the caller and the called machine is, and can communicate with the simple primitives shown in Table 1.5.

Sessions are the backbone of resource sharing on an NBT network. They are typically used for establishing stable connections from client machines to disk or printer shares on a server. The client "calls" the server and starts trading information such as which files it wishes to open, which data it wishes to exchange, etc. These calls can last a long time—hours, even days—and all of this occurs within the context of a single connection. If there is an error, the session software (TCP) will retransmit until the data is received properly, unlike the "punt-and-pray" approach of the datagram service (UDP).

In truth, while sessions are supposed to be able to handle problematic communications, they often don't. As you've probably already discovered when using Windows networks, this is a serious detriment to using NBT sessions. If the connection is interrupted for some reason, session information that is open between the two computers can easily become invalidated. If that happens, the only way to regain the session information is for the same two computers to call each other again and start over.

If you want more information on each of these services, we recommend you look at RFC 1001. However, there are two important things to remember here:

Recall that a workgroup is a collection of SMB computers that all reside on a subnet and subscribe to the same SMB group. A Windows domain goes a step further. It is a workgroup of SMB machines that has one addition: a server acting as a domain controller. You must have a domain controller in order to have a Windows domain.^[6] Otherwise, it is only a workgroup. See Figure 1.11.

Figure 1.11. A simple Windows domain

There are currently two separate protocols used by a domain controller (logon server): one for communicating with Windows 95/98 machines and one for communicating with Windows NT machines. While Samba currently implements the domain controller protocol for Windows 95/98 (which allows it to act as a domain controller for Windows 9x machines), it still does not fully support the protocol for Windows NT computers. However, the Samba team promises that support for the Windows NT domain controller protocol is forthcoming in Samba 2.1.

Domain controllers

The domain controller is the nerve center of a Windows domain, much like an NIS server is the nerve center of the Unix network information service. Domain controllers have a variety of responsibilities. One responsibility that you need to be concerned with is authentication . Authentication is the process of granting or denying a user access to a shared resource on another network machine, typically through the use of a password.

Each domain controller uses a security account manager (SAM) to maintain a list of username-password combinations. The domain controller then forms a central repository of passwords that are tied to usernames (one password per user), which is more efficient than each client machine maintaining hundreds of passwords for every network resource available.

On a Windows domain, when a non-authenticated client requests access to a server's shares, the server will turn around and ask the domain controller whether that user is authenticated. If it is, the server will establish a session connection with the access rights it has for that service and user. If not, the connection is denied. Once a user is authenticated by the domain controller, a special authenticated token will be returned to the client so that the user will not need to relogin to other resources on that domain. At this point, the user is considered "logged in" to the domain itself. See Figure 1.12.

Figure 1.12. Using a domain controller for authentication

Browsing is a high-level answer to the user question: "What machines are out there on the Windows network?" Note that there is no connection with a World Wide Web browser, apart from the general idea of "discovering what's there." And, like the Web, what's out there can change without warning.

Before browsing, users had to know the name of the specific computer they wanted to connect to on the network, and then manually enter a UNC such as the following into an application or file manager to access resources:

\\HYDRA\network\

With browsing, however, you can examine the contents of a machine using a standard point-and-click GUI—in this case, the Network Neighborhood window in a Windows client.

Levels of browsing

As we hinted at the beginning of the chapter, there are actually two types of browsing that you will encounter in an SMB/CIFS network:

• Browsing a list of machines (with shared resources)

• Browsing the shared resources of a specific machine

Let's look at the first one. On each Windows workgroup (or domain) subnet, one computer has the responsibility of maintaining a list of the machines that are currently accessible through the network. This computer is called the local master browser , and the list that it maintains is called the browse list. Machines on a subnet use the browse list in order to cut down on the amount of network traffic generated while browsing. Instead of each computer dynamically polling to determine a list of the currently available machines, the computer can simply query the local master browser to obtain a complete, up-to-date list.

To browse the actual resources on a machine, a user must connect to the specific machine; this information cannot be obtained from the browse list. Browsing the list of resources on a machine can be done by clicking on the machine's icon when it is presented in the Network Neighborhood in Windows 95/98 or NT. As you saw at the opening of the chapter, the machine will respond with a list of shared resources that can be accessed if that user is successfully authenticated.

Each of the servers on a Windows workgroup is required to announce its presence to the local master browser after it has registered a NetBIOS name, and (theoretically) announce that it is leaving the workgroup when it is shut down. It is the local master browser's responsibility to record what the servers have announced. Note that the local master browser is not necessarily the same machine as a NetBIOS name server (NBNS), which we discussed earlier.

Warning

The Windows Network Neighborhood can behave oddly: until you select a particular machine to browse, the Network Neighborhood window may contain data that is not up-to-date. That means that the Network Neighborhood window can be showing machines that have crashed, or can be missing machines that haven't been noticed yet. Put succinctly, once you've selected a server and connected to it, you can be a lot more confident that the shares and printers really exist on the network.

Unlike the roles you've seen earlier, almost any Windows machine (NT Server, NT Workstation, 98, 95, or Windows 3.1 for Workgroups) can act as a local master browser. As with the domain controller, the local master browser can have one or more backup browsers on the local subnet that will take over in the event that the local master browser fails or becomes inaccessible. To ensure fluid operation, the local backup browsers will frequently synchronize their browse list with the local master browser. Let's update our Windows domain diagram to include both a local master and local backup browser. The result is shown in Figure 1.13.

Figure 1.13. A Windows domain with a local master and local backup browser

Here is how to calculate the minimum number of backup browsers that will be allocated on a workgroup:

• If there are between 1 and 32 Windows NT workstations on the network, or between 1 and 16 Windows 95/98 machines on the network, the local master browser allocates one backup browser in addition to the local master browser.

• If the number of Windows NT workstations falls between 33 and 64, or the number of Windows 95/98 workstations falls between 17 and 32, the local master browser allocates two backup browsers.

• For each group of 32 NT workstations or 16 Windows 95/98 machines beyond this, the local master browser allocates another backup browser.

There is currently no upper limit on the number of backup browsers that can be allocated by the local master browser.

Yes, but most people who have done it have had their share of headaches. Spanning multiple subnets was not part of the initial design of Windows NT 3.5 or Windows for Workgroups. As a result, a Windows domain that spans two or more subnets is, in reality, the "gluing" together of two or more workgroups that share an identical name. The good news is that you can still use a primary domain controller to control authentication across each of the subnets. The bad news is that things are not as simple with browsing.

As mentioned previously, each subnet must have its own local master browser. When a Windows domain spans multiple subnets, a system administrator will have to assign one of the machines as the domain master browser. The domain master browser will keep a browse list for the entire Windows domain. This browse list is created by periodically synchronizing the browse lists of each of the local master browsers with the browse list of the domain master browser. After the synchronization, the local master browser and the domain master browser should contain identical entries. See Figure 1.14 for an illustration.

Figure 1.14. A workgroup that spans more than one subnet

Sound good? Well, it's not quite nirvana for the following reasons:

Each subnet's local master browser continues to maintain the browse list for its subnet, for which it becomes authoritative. So if a computer wants to see a list of servers within its own subnet, the local master browser of that subnet will be queried. If a computer wants to see a list of servers outside the subnet, it can still go only as far as the local master browser. This works because, at appointed intervals, the authoritative browse list of a subnet's local master browser is synchronized with the domain master browser, which is synchronized with the local master browser of the other subnets in the domain. This is called browse list propagation .

Samba can act as a domain master browser on a Windows domain if required. In addition, it can also act as a local master browser for a Windows subnet, synchronizing its browse list with the domain master browser.

The Windows Internet Name Service (WINS) is Microsoft's implementation of a NetBIOS name server (NBNS). As such, WINS inherits much of NetBIOS's characteristics. First, WINS is flat; you can only have machines named fred or workgroups like CANADA or USA. In addition, WINS is dynamic: when a client first comes online, it is required to report its hostname, its address, and its workgroup to the local WINS server. This WINS server will retain the information so long as the client periodically refreshes its WINS registration, which indicates that it's still connected to the network. Note that WINS servers are not domain or workgroup specific; they can appear anywhere and serve anyone.

Multiple WINS servers can be set to synchronize with each other after a specified amount of time. This allows entries for machines that come online and offline on the network to propagate from one WINS server to another. While in theory this seems efficient, it can quickly become cumbersome if there are several WINS servers covering a network. Because WINS services can cross multiple subnets (you'll either hardcode the address of a WINS server in each of your clients or obtain it via DHCP), it is often more efficient to have each Windows client, no matter how many Windows domains there are, point themselves to the same WINS server. That way, there will only be one authoritative WINS server with the correct information, instead of several WINS servers continually struggling to synchronize themselves with the most recent changes.

The currently active WINS server is known as the primary WINS server . You can also install a secondary WINS server, which will take over in the event that the primary WINS server fails or becomes inaccessible. Note that there is no election to determine which machine becomes a primary or backup WINS server—the choice of WINS servers is static and must be predetermined by the system administrator. Both the primary and any backup WINS servers will synchronize their address databases on a periodic basis.

In the Windows family of operating systems, only an NT Workstation or an NT server can serve as a WINS server. Samba can also function as a primary WINS server, but not a secondary WINS server.

Whew! Bet you never thought Microsoft networks would be that complex, did you? Now, let's wrap up by showing where Samba can help out. Table 1.6 summarizes which roles Samba can and cannot play in a Windows NT Domain or Windows workgroup. As you can see, because many of the NT domain protocols are proprietary and have not been documented by Microsoft, Samba cannot properly synchronize its data with a Microsoft server and cannot act as a backup in most roles. However, with version 2.0.x, Samba does have limited support for the primary domain controller's authentication protocols and is gaining more functionality every day.

Samba's support for NT Domains (starting with version 2.0.x) produced a big improvement: it allows SMB servers to use its authentication mechanisms, which is essential for future NT compatibility, and to support NT domain logons . Domain logons allow a user to log in to a Windows NT domain and use all the computers in the domain without logging into them individually. Previous to version 2.0.0, Samba supported Windows 95/98 logon services, but not NT domain logons. Although domain logons support is not complete is Samba 2.0, it is partially implemented.

SWAT, the Samba Web Administration Tool, makes it easy to set up a server and change its configuration, without giving up the simple text-based configuration file. SWAT provides a graphical interface to the resources that Samba shares with its clients. In addition, SWAT saves considerable experimentation and memory work in setting up or changing configurations across the network. You can even create an initial setup with SWAT and then modify the file later by hand, or vice versa. Samba will not complain.

On the compilation side, GNU autoconf is now used to make the task of initial compilation and setup easier so you can get to SWAT quicker.

There are major performance and scalability increases in Samba: the code has been reorganized and nmbd (the Samba name service daemon) heavily rewritten:

There are several additional features in Samba 2.0. You can now have multiple Samba aliases on the same machine, each pretending to be a different server, a feature similar to virtual hosts in modern web servers. This allows a host to serve multiple departments and groups, or provide disk shares with normal username/password security while also providing printers to everyone without any security. Printing has been changed to make it easier for Unix System V owners: Samba can now find the available printers automatically, just as it does with Berkeley-style printing. In addition, Samba now has the capability to use multiple code pages, so it can be used with non-European languages, and to use the Secure Sockets Layer protocol (SSL) to encrypt all the data it sends across the Internet, instead of just passwords.^[7]

At the same time as it's becoming more capable, Samba is also becoming more compatible with Windows NT. Samba has always supported Microsoft-style password encryption. It now provides tools and options for changing over to Microsoft encryption, and for keeping the Unix and Microsoft password files synchronized while doing so. Finally, a Samba master browser can be instructed to hunt down and synchronize itself with other SMB servers on different LANs, allowing SMB to work seamlessly across multiple networks. Samba uses a different method of accomplishing this from the Microsoft method, which is undocumented.

Finally, there is an entirely new version of the Unix client called smbwrapper . Instead of a kernel module that allows Linux to act as a Samba client, there is now a command-line entry to load the library that provides a complete SMB filesystem on some brands of Unix. Once loaded, the command ls /smb will list all the machines in your workgroup, and cd /smb/server_name/share_name will take you to a particular share (shared directory), similar to the Network File System (NFS). As of this writing, smbwrapper currently runs on Linux, Solaris, SunOS 4, IRIX, and OSF/1, and is expected to run on several more operating systems in the near future.

Precompiled packages are also available for a large number of Unix platforms. These packages contain binaries for each of the Samba executables as well as the standard Samba documentation. Note that while installing a binary distribution can save you a fair amount of trouble and time, there are a couple of issues that you should keep in mind when deciding whether to use the binary or compile the source yourself:

$ ldd smbd
libreadline.so.3 => /usr/lib/libreadline.so.3
libdl.so.2 => /lib/libdl.so.2
libcrypt.so.1 => /lib/libcrypt.so.1
libc.so.6 => /lib/libc.so.6
libtermcap.so.2 => /lib/libtermcap.so.2
/lib/ld-linux.so.2 => /lib/ld-linux.so.2

One point worth mentioning is that the Samba source requires an ANSI C compiler. If you are on a platform with a non-ANSI compiler, such as the cc compiler on SunOS version 4, you'll have to install an ANSI-compliant compiler such as gcc before you do anything else.^[3] If installing a compiler isn't something you want to wrestle with, you can start off with a binary package. However, for the most flexibility and compatibility on your system, we always recommend compiling from the latest source.

This sounds like an obvious thing to say, but there have probably been times where you have uncompressed a package, blindly typed configure, make, and make install, and walked away to get another cup of coffee. We'll be the first to admit that we do that, many more times than we should. It's a bad idea—especially when planning a network with Samba.

Samba 2.0 automatically configures itself prior to compilation. This reduces the likelihood of a machine-specific problem, but there may be an option mentioned in the README file that you end up wishing for after Samba's been installed. With both source and binary packages you'll find a large number of documents in the docs directory, in a variety of formats. The most important files to look at in the distribution are:

WHATSNEW.txt
docs/textdocs/UNIX_INSTALL.txt

These files tell you what features you can expect in your Samba distribution, and will highlight common installation problems that you're likely to face. Be sure to look over both of them before you start the compilation process.

There are a couple of final steps to perform. Specifically, add the Samba Web Administration Tool (SWAT) to the /etc/services and /etc/inetd.conf configuration files. SWAT runs as a daemon under inetd and provides a forms-based editor in your web browser for creating and modifying SMB configuration files.

And that's pretty much it for the installation. Before you can start up Samba, however, you need to create a configuration file for it.

With Samba 2.0, creating a configuration file is even easier than writing a configuration file by hand. You can use your browser to connect to http://localhost:901, and log on as the root account, as shown in Figure 2.1.

Figure 2.1. SWAT login

After logging in, press the GLOBALS button at the top of the screen. You should see the Global Variables page shown in Figure 2.2.

Figure 2.2. SWAT Global Variables page

In this example, set the workgroup field to SIMPLE and the security field to USER. The only other option you need to change from the menu is one determining which system on the LAN resolves NetBIOS addresses; this system is called the WINS server . At the very bottom of the page, set the wins support field to Yes, unless you already have a WINS server on your network. If you do, put the WINS server's IP address in the wins server field instead. Then return to the top and press the Commit Changes button to write the changes out to the smb.conf file.

Figure 2.3. SWAT Share Creation screen

Next, press the Shares icon. You should see a page similar to Figure 2.3. Choose Test in the field beside the Choose Share button. You will see the Share Parameters screen, as shown in Figure 2.4. We added a comment to remind us that this is a test share in the smb.conf file. SWAT has copies of all that information here.

Figure 2.4. SWAT Share Parameters screen

If you press the View button, SWAT shows you the following smb.conf file:

# Samba config file created using SWAT
# from localhost (127.0.0.1)
# Date: 1998/11/27 15:42:40

# Global parameters
        workgroup = SIMPLE
[test]
        comment = For testing only, please
        path = /export/samba/test
        read only = no
        guest ok = yes

Once this configuration file is completed, you can skip the next step because the output of SWAT is guaranteed to be syntactically correct.

If you didn't use SWAT to create your configuration file, you should probably test it to ensure that it is syntactically correct. It may seem silly to run a test program against an eight-line configuration file, but it's good practice for the real ones that we'll be writing later on.

The test parser, testparm , examines an smb.conf file for syntax errors and reports any it finds along with a list of the services enabled on your machine. An example follows; you'll notice that in our haste to get the server running we mistyped workgroup as workgrp (the output is often lengthy, so we recommend capturing the last parts with the tee command):

Load smb config files from smb.conf
Unknown parameter encountered: "workgrp"
Ignoring unknown parameter "workgrp"
Processing section "[test]"
Loaded services file OK.
Press enter to see a dump of your service definitions
# Global parameters
[global]
        workgroup = WORKGROUP
        netbios name =
        netbios aliases =
        server string = Samba 2.0.5a
        interfaces =
        bind interfaces only = No

...(content omitted)...

[test]
        comment = For testing only, please
    path = /export/samba/test
        read only = No
        guest ok = Yes

The interesting parts are at the top and bottom. The top of the output will flag any syntax errors that you may have made, and the bottom lists the services that the server thinks it should offer. A word of advice: make sure that you and the server have the same expectations.

If everything looks good, then you are ready to fire up the server daemons!

If you're in a hurry, you can start the Samba daemons by hand. As root, simply enter the following commands:

# /usr/local/samba/bin/smbd -D
# /usr/local/samba/bin/nmbd -D

At this point, Samba will be running on your system and will be ready to accept connections.

To run the Samba processes as stand-alone daemons, you need to add the commands listed in the previous section to your standard Unix startup scripts. This varies depending on whether you have a BSD-style Unix system or a System V Unix.

if [ -x /usr/local/samba/bin/smbd]; then
	echo "Starting smbd..."
	/usr/local/samba/bin/smbd -D
	echo "Starting nmbd..."
	/usr/local/samba/bin/nmbd -D
fi

#!/bin/sh

# Contains the "killproc" function on Red Hat Linux
./etc/rc.d/init.d/functions

PATH="/usr/local/samba/bin:$PATH"

case $1 in
	'start')
		echo "Starting smbd..."
		smbd -D
		echo "Starting nmbd..."
		nmbd -D
		;;
	'stop')
		echo "Stopping smbd and nmbd..."
		killproc smbd
		killproc nmbd
		rm -f /usr/local/samba/var/locks/smbd.pid
		rm -f /usr/local/samba/var/locks/nmbd.pid
		;;
	*)
		echo "usage: smb {start|stop}"
		;;
esac

# /etc/rc.local/smb start
Starting smbd...
Starting nmbd...
# /etc/rc.local/smb stop
Stopping smbd and nmbd...

The inetd daemon is a Unix system's Internet "super daemon." It listens on TCP ports defined in /etc/services and executes the appropriate program for each port, which is defined in /etc/inetd.conf . The advantage of this scheme is that you can have a large number of daemons ready to answer queries, but they don't all have to be running. Instead, the inetd daemon listens in places of all the others. The penalty is a small overhead cost of creating a new daemon process, and the fact that you need to edit two files rather than one to set things up. This is handy if you have only one or two users or your machine has too many daemons already. It's also easier to perform an upgrade without disturbing an existing connection.

If you wish to start from inetd, first open /etc/services in your text editor. If you don't already have them defined, add the following two lines:

netbios-ssn     139/tcp
netbios-ns      137/udp

Next, edit /etc/inetd.conf. Look for the following two lines and add them if they don't exist. If you already have smbd and nmbd lines in the file, edit them to point at the new smbd and nmbd you've installed. Your brand of Unix may use a slightly different syntax in this file; use the existing entries and the inetd.conf manual page as a guide:

netbios-ssn stream tcp nowait root /usr/local/samba/bin/smbd smbd
netbios-ns  dgram  udp wait   root /usr/local/samba/bin/nmbd nmbd

Finally, kill any smbd or nmbd processes and send the inetd process a hangup (HUP) signal. (The inetd daemon rereads its configuration file on a HUP signal.) To do this, use the ps command to find its process ID, then signal it with the following command:

# kill -HUP process_id

After that, Samba should be up and running.

The first thing we need to do is to tell Windows to keep user profiles separate, and to collect usernames and passwords to authenticate anyone trying to access a Samba share. We do so via the Password settings in the Control Panel. If you are not familiar with the Windows Control Panel, you can access it by choosing the Settings menu item from the pop-up menu of the Start button in the lower-left corner of the screen. Alternatively, you'll find it as a folder under the icon in the upper-left corner that represents your computer and is typically labeled My Computer.

After selecting the Passwords icon in the Control Panel, click on the User Profiles tab on the far right. You should see the dialog box shown in Figure 3.1. Then click the lower of the two radio buttons that starts "Users can customize their preferences...." This causes Windows to store a separate profile for each user, and saves the username and password you provide, which it will use later when it connects to an SMB/CIFS server. Finally, check both the options under the User Profile Settings border, as shown in the figure.

Figure 3.1. The Passwords Properties panel

The next step is to select the Change Passwords tab on the left side of the dialog box. In order for Samba to allow you access to its shares, the username and password you give to Windows must match the account and password on the Samba server. If you don't have this tab in your dialog box, don't worry; it's probably because you haven't given yourself a Windows username and password yet. Simply click the OK button at the bottom and respond Yes when Windows asks to reboot. Then, skip down to Section 3.1.1.2.

Changing the Windows password

After selecting the Change Passwords tab, the dialog box in Figure 3.2 will appear.

Figure 3.2. The Change Passwords tab

Select the Change Windows Password button. The Change Windows Password dialog box should appear, as shown in Figure 3.3. From here, you can change your password to match the password of the account on the Samba server through which you intend to log in.

Figure 3.3. The Change Windows Password dialog box

Logging in for the first time

If you didn't have a Change Passwords tab in the Passwords Properties window, then after Windows has finished rebooting, it will ask you to log in with a username and a password. Give yourself the same username and password that you have on the Samba server. After confirming your new username and password, or if you already have one, Windows should ask you if you want to have a profile, using the dialog shown in Figure 3.4.

Figure 3.4. Windows Networking profiles

Answer Yes, upon which Windows will create a separate profile and password file for you and save a copy of your password in the file. Now when you connect to Samba, Windows will send its password, which will be used to authenticate you for each share. We won't worry about profiles for the moment; we'll cover them in Chapter 6. We should point out, however, that there is a small security risk: someone can steal the password file and decrypt the passwords because it's weakly encrypted. Unfortunately, there isn't a solution to this with Windows 95/98. In Windows 2000 (NT 5.0), the password encryption should be replaced with a much better algorithm.

The next thing we need to do is make sure we have the TCP/IP networking protocol set up correctly. To do this, double-click on the Network icon in the Control Panel. You should see the network configuration dialog box, as shown in Figure 3.5.

Figure 3.5. The Windows 95/98 Network panel

Microsoft networking works by binding specific protocols, such as IPX or TCP/IP, to a specific hardware device, such as an Ethernet card or a dialup connection. By routing a protocol through a hardware device, the machine can act as a client or server for a particular type of network. For Samba, we are interested in binding the TCP/IP protocol through a networking device, making the machine a client for Microsoft networks. Thus, when the dialog box appears, you should see at least the Client for Microsoft Networks component installed on the machine, and hopefully a networking device (preferably an Ethernet card) bound to the TCP/IP protocol. If there is only one networking hardware device, you'll see the TCP/IP protocol listed below that device. If it appears similar to Figure 3.5, the protocol is bound to the device.

You may also see "File and printer sharing for Microsoft Networks," which is useful. In addition, you might see NetBEUI or Novell Networking, which are standard with Windows installations but undesirable when TCP/IP is running. Remove NetBEUI if you possibly can—it's unnecessary and makes debugging Windows browsing difficult. If you don't have any Novell servers on your network, you can remove Novell (IPX/SPX) as well.

Adding TCP/IP

If you don't see TCP/IP listed at all, you'll need to install the protocol. If you already have TCP/IP, skip this section, and continue with Section 3.1.3, later in this chapter.

Installing TCP/IP isn't difficult since Microsoft distributes its own version of TCP/IP for free on their installation CD-ROM. You can add the protocol by clicking on the Add button below the component window. Indicate that you wish to add a specific protocol by selecting Protocol and clicking Add... on the following dialog box, which should look similar to Figure 3.6.

Figure 3.6. Selecting a protocol to install

After that, select the protocol TCP/IP from manufacturer Microsoft, as shown in Figure 3.7, then click OK. After doing so, you will be returned to the network dialog. Click OK there to close the dialog box, upon which Windows will install the necessary components from disk and reboot the machine.

Figure 3.7. Selecting a protocol to install

Configuring TCP/IP

If you have more than one networking device (for example, both an Ethernet card and a dialup networking modem), each appropriate hardware device should be "linked" to the TCP/IP protocol with an arrow, as shown in Figure 3.8. Select the TCP/IP protocol linked to the networking device that will be accessing the Samba network. When it is highlighted, click the Properties button.

Figure 3.8. Selecting the correct TCP/IP protocol

After doing so, the TCP/IP Properties panel for that device is displayed, as shown in Figure 3.9.

Figure 3.9. STCP/IP Properties panel

There are seven tabs near the top of this panel, and you will need to configure four of them:

• IP address

• DNS configuration

• WINS configuration

• Bindings

DNS Configuration tab

Domain Name Service ( DNS) is responsible for translating Internet computer names such as hobbes.example.com into machine-readable IP addresses such as 192.168.236.10. There are two ways to accomplish this on a Windows 98 machine: you can specify a server to do the translation for you or you can keep a local list of name/address pairs to refer to.

Networks that are connected to the Internet typically use a server, since the hosts files required would otherwise be huge. For an unconnected LAN, the list of possible hosts is small and well-known and might be kept on a Unix machine in the /etc/hosts file. If you are in doubt as to whether a DNS server is being used, or what its address might be, look at the file /etc/resolv.conf on your Unix servers. Any machine using DNS will have this file, which looks like:

#resolv.conf
domain example.com
nameserver 127.0.0.1
nameserver 192.168.236.20

In the example shown, the second nameserver line in the list contains the IP address of another machine on the local network: 192.168.236.20. It's a good candidate for a DNS server.^[1]

You must type the correct IP address of one or more DNS servers (note that you cannot use its Internet name, such as dns.oreilly.com) into the appropriate field in Figure 3.10. Be sure not to use 127.0.0.1—that will never be the correct DNS server address!

Try to select addresses on your own network. Any name servers listed in /etc/resolv.conf should work, but you'll get better performance by using a server nearby. (If you don't find /etc/resolv.conf files on your Unix machines, just disable DNS until you can find the address of at least one DNS server.) Let's assume you only have one DNS server, and its address is 192.168.236.20. Click the Enable DNS radio button, as shown in Figure 3.10, and add the server's address to the top DNS Server Search Order field.

Figure 3.10. The DNS Configuration tab

Also, provide the name of the Windows 95/98 machine and the Internet domain you're in. You can safely ignore the Domain Suffix Search Order field for anything related to Samba.

WINS Configuration tab

WINS is the Windows Internet Name Service, its version of a NetBIOS name server. If you've enabled WINS on Samba, you must tell Windows the Samba server's address. If you are using WINS servers that are entirely Windows NT, enter each of them here as well. The dialog box shown after selecting the WINS Configuration tab is shown in Figure 3.11.

Figure 3.11. The WINS Configuration tab

Warning

Do not mix a Samba WINS server and a Windows NT server as a primary/backup combination in the WINS dialog. Because the two cannot replicate their databases, this will cause name resolution to perform incorrectly.

From here, select Enable WINS Resolution and enter the WINS server's address in the space provided, then press Add. Do not enter anything in the Scope ID field.

# 127.0.0.1             localhost
192.168.236.1       escrime.example.com 	escrime
192.168.236.2      riposte.example.com 	riposte
192.168.236.3       wizzin.example.com 	wizzin
192.168.236.4       touche.example.com 	touche
192.168.236.10     hobbes.example.com 	hobbes

Check the bindings

The final tab to look at is Bindings, as shown in Figure 3.12.

Figure 3.12. The Bindings tab

You should have a check beside Client for Microsoft Networks, indicating that it's using TCP/IP. If you have "File and printer sharing for Microsoft Networks" in the dialog, it should also be checked, as shown in the figure.

Finally, press the OK button in the TCP/IP configuration panel, and you'll be taken back to the Network Configuration screen. Then select the Identification tab, which will take you to the dialog box shown in Figure 3.13.

Figure 3.13. The Identification tab

Here, for the second time, set your machine's name. This time, instead of your DNS hostname and domain, you're setting your NetBIOS name. However, it is best to make this the same as your hostname. Try not to make a spelling mistake: it can be very confusing to configure a machine if TCP thinks it's fred and SMB thinks its ferd !

You also set your workgroup name here. In our case, it's SIMPLE, but if you used a different one in Chapter 2, when creating the Samba configuration file, use that here as well. Try to avoid calling it WORKGROUP or you'll be in the same workgroup as every unconfigured (or ill-configured) machine in the world.

Click on the OK button to complete the configuration; you will need to reboot in order for your changes to take effect.

Now for the big moment. Your Samba server is running, and you have set up your Windows 95/98 client to communicate with it. After rebooting, log in and double-click the Network Neighborhood icon on the desktop. You should see your Samba server listed as a member of the workgroup, as shown in Figure 3.14.

Figure 3.14. Windows Network Neighborhood

Double-clicking the server name will show the resources that the server is offering to the network, as shown in Figure 3.15 (in this case a printer and the test directory).

Figure 3.15. Shares on Server

If you don't see the server listed, start Windows Explorer (not Internet Explorer!) and select Map Network Drive from the Tools menu. This will give you a dialog box into which you can type the name of your server and the share test in the Windows UNC format: \\server\test, like we did in the first chapter. This should attempt to contact the Samba server and its temporary share. If things still aren't right, go to Chapter 9, for troubleshooting assistance.

This section presents an outline of the steps to follow for getting Windows NT to cooperate with Samba. If you need more details on Windows NT network administration, refer to Craig Hunt and Robert Bruce Thompsom's Windows NT TCP/IP Network Administration (O'Reilly), an excellent guide. You should perform these steps as the "Administrator" user.

Name the machine

The first thing you need to do is to give the machine a NetBIOS name. From the Control Panel, double click on the Network icon. This will take you to the Network dialog box for the machine. The first tab in this dialog box should be the Identification tab, as illustrated in Figure 3.16.

Figure 3.16. Network panel Identification tab

Here, you need to identify your machine with a name (we use the name Artish here) and change the default workgroup to the one you specified in the smb.conf file of your Samba server. In this case, the workgroup name is SIMPLE. However, you cannot edit either name here (as you could in Windows 95/98), but instead must use the Change button below the two text fields. Pressing this button raises an Identification Changes dialog box, where you can reset the workgroup and the machine name, as shown in Figure 3.17.

Figure 3.17. Changing the identification

A word of warning: you will have to set the machine name again later while configuring TCP/IP, so be sure that the two names match. The name you set here is the NetBIOS name. You're allowed to make it different from the TCP/IP hostname, but doing so is usually not a good thing. Don't worry that Windows NT forces the computer name and the workgroup to be all capital letters; it's smart enough to figure out what you mean when it connects to the network.

Installing the TCP/IP protocol

Next, select the Protocols tab in the Network dialog box, and look to see if you have the TCP/IP protocol installed, as shown in Figure 3.18.

Figure 3.18. The Protocols tab

If the protocol is not installed, you need to add it. Press the Add button, which will display the Select Network Protocol dialog box shown in Figure 3.19. Unlike Windows 95/98, you should immediately see the TCP/IP protocol as one of the last protocols listed.

Figure 3.19. Select Network Protocol dialog box

Select TCP/IP as the protocol and confirm it. If possible, install only the TCP/IP protocol. You usually do not want NetBEUI installed because this causes the machine to look for services under two different protocols, only one of which is likely in use.^[2]

Installing the Workstation service

After installing TCP/IP, press the Services tab in the Network panel and check that you have a Workstation service, as shown at the end of the list in Figure 3.20.

Figure 3.20. Network Services panel dialog box

This service is actually the Microsoft Networking Client, which allows the machine to access SMB services. The Workstation service is mandatory. The service is installed by default on both Windows NT Workstation 4.0 and Server 4.0. If it's not there, you can install it much like TCP/IP. In this case you need to press the Add button and then select Workstation Service, as shown in Figure 3.21.

Figure 3.21. Select Network Service dialog box

After you've installed the Workstation service, return to the Protocols tab and select the TCP/IP Protocol entry in the window. Then click the Properties button below the window. The Microsoft TCP/IP Protocol panel will be displayed. There are five tabs on the Windows NT panel, and (like Windows 95/98) you will need to work on three of them:

IP Address tab

The IP Address tab is shown in Figure 3.22.

Figure 3.22. Microsoft TCP/IP Properties for Windows NT

Select the "Specify an IP address" radio button and enter the computer's address and subnet mask in the space provided for the proper adapter (Ethernet card). You or your network manager should have selected an address for the client on the same subnet (LAN) as the Samba server. For example, if the server's address is 192.168.236.86 and its network mask 255.255.255.0, you might use the address 192.168.236.10, if it is available, for the NT workstation, along with the same netmask. If you use DHCP on your network, select the "Obtain an IP Address from a DHCP server" button.

Tip

If you don't have an IP address to use, and you are on a network by yourself, steal ours, as the 192.168.x.x subnet is specifically reserved by the Internic for LANs. If you're not by yourself, see your system administrator for some available addresses on your network.

The gateway field refers to a machine typically known as a router . If you have routers connecting multiple networks, you should put in the IP address of the one on your subnet.

DNS tab

Next we go to the tab for DNS, as shown in Figure 3.23. This brings up the DNS panel.

Figure 3.23. The DNS panel

The Domain Name System (DNS) is responsible for translating human-readable computer names such as atrish.example.com into IP addresses such as 192.168.236.10. There are two ways to accomplish this on a NT machine. First, you can specify a DNS server to do the translation for you, or you can keep a local list of name/address pairs for your workstation to refer to.

For a LAN that's not on the Internet, the list of possible hosts is typically small and well known, and may be kept in a file locally. Networks that are connected to the Internet typically use DNS service since it isn't possible to guess ahead of time what addresses you might be accessing out on the net. If you are in doubt as to whether a DNS server is being used, or what its address might be, look at the file /etc/resolv.conf on your Samba server: any machine using DNS will have this file. It looks like the following:

#resolv.conf
domain example.com
nameserver 127.0.0.1
nameserver 192.168.236.20

In this example, the first nameserver in the list is 127.0.0.1, which indicates that the Samba server is also a DNS server for this LAN.^[3] In that case, you would use its network IP address (not 127.0.0.1, its localhost address) when filling in the DNS Configuration dialog box. Otherwise, use the other addresses you find in the lines beginning with nameserver. Try to select ones on your own network. Any name servers listed in /etc/resolv.conf should work, but you'll get better performance by using a server nearby.

Finally, enter the machine name once more, making sure that it's the same one listed in the Identification tab of the Network dialog box (before the NetBIOS name). Also, enter the DNS domain on which this machine resides. For example, if your workstation has a domain name such as example.com, enter it here. You can safely ignore the other options.

WINS Address tab

If you are not using a DNS server, you still need a way of translating NetBIOS names to addresses and back again. We recommend that you configure both DNS and WINS; NT has a preference for WINS and WINS can use DNS as a fallback if it cannot resolve any machine address. The WINS Address tab is shown in Figure 3.24.

Figure 3.24. The WINS Address tab

If you have a WINS server, enter its address in the space marked Primary WINS Server. If your Samba server is providing WINS service (in other words, you have the line wins service = yes in the smb.conf file of your Samba server), provide the Samba server's IP address here. Otherwise, provide the address of another WINS server on your network.

You probably noticed that there is a field here for the adaptor; this field must specify the Ethernet adaptor that you're running TCP/IP on so that WINS will provide name service on the correct network. If you have both a LAN and a dialup adaptor, make sure you have the LAN's adaptor here.

Finally, select the "Enable DNS for Windows Resolution" checkbox, so WINS will try DNS as a fallback if it can't find a name. You can safely ignore the other options.

127.0.0.1       localhost
192.168.236.1    escrime    escrime.example.com
192.168.236.2    riposte    riposte.example.com
192.168.236.3    wizzin     wizzin.example.com
192.168.236.4    touche     touche.example.com
192.168.236.5    gurgi      gurgi.example.com
192.168.236.6    jessiac    jessiac.example.com
192.168.236.7    skyline    skyline.example.com

Bindings

The term bindings is a way of saying "connected together at configuration time." It means that the TCP/IP protocol will channel through the Ethernet card (instead of, say, a dialup connection), and is actually connected properly. If you return to the Network dialog box and set the Show field to "all services" and click on all the + buttons in the tree, you should see a display similar to Figure 3.25.

Figure 3.25. Service bindings

This means that the Workstation, Server, and NetBIOS interface services are connected to the WINS client. This is the correct binding for Microsoft TCP/IP.

You can safely leave the default values for the remainder of the tabs in the Network dialog box. Click on the OK button to complete the configuration. Once the proper files are loaded (if any), you will need to reboot in order for your changes to take effect.

Now for the big moment. Your Samba server is running and you have set up your NT client to communicate with it. After the machine reboots, login and double-click the Network Neighborhood icon on the desktop, and you should see your Samba server listed as a member of the workgroup, as shown in Figure 3.26.

Figure 3.26. Windows NT Network Neighborhood

Double-clicking the server name will show the resources that the server is offering to the network, as shown in Figure 3.27. In this case, the test and the default printer are offered to the Window NT workstation. For more information, see the warning under Section 3.1.4 earlier in this chapter.

Figure 3.27. Server's shares

If you don't see the server listed, don't panic. Start the Windows NT Explorer (not Internet Explorer!) and select Map Network Drive from the Tools menu. A dialog box appears that allows you to type the name of your server and its share directory in Windows format. For example, you would enter \\server\temp if your server happened to be named "server." If things still aren't right, go directly to Section 9.2 in Chapter 9, to see if you can troubleshoot what is wrong with the network.

If it works, congratulations! Try writing to the server and sending data to the network printer. You will be pleasantly surprised how seamlessly everything works! Now that you've finished setting up the Samba server and its clients, we can starting talking about how Samba works and how to configure it to your liking.

Richard Sharpe of the Samba team defines SMB as a "request-response" protocol.^[4] In effect, this means that a client sends an SMB request to a server, and the server sends an SMB response back to the client. Rarely does a server send a message that is not in response to a client.

An SMB message is not as complex as you might think. Let's take a closer look at the internal structure of such a message. It can be broken down into two parts: the header , which is a fixed size, and the command string, whose size can vary dramatically based on the contents of the message.

As mentioned earlier, SMB is a client/server protocol. In the purest sense, this means that a client sends a request to a server, which acts on the request and returns a reply. However, the client/server roles can often be reversed, sometimes within the context of a single SMB session. For example, consider the two Windows 95/98 computers in Figure 3.28. The computer named WIZZIN shares a printer to the network, and the computer named ESCRIME shares a disk directory. WIZZIN is in the client role when accessing ESCRIME's network drive, and in the server role when printing a job for ESCRIME.

Figure 3.28. Two computers that both have resources to share

This brings out an important point in Samba terminology:

Note that there are no implications as to the amount of resources that make up a server, or whether it has a large disk space or fast processor. A server could be an old 486 with a printer attached to it, or it could be an UltraSparc station with a 10 gigabyte disk service.

Microsoft Windows products have both the SMB client and server built in to the operating system. Wndows NT 4.0 uses a newer SMB protocol than Windows for Workgroups, and it offers an enhanced form of network security which will be discussed in Chapter 6. In addition, there are a large number of commercial SMB server products available from companies such as Sun, Compaq, SCO, Hewlett-Packard, Syntax, and IBM. Unfortunately, on the client side there are far fewer offerings, limited mainly to Digital Equipment's Pathworks product, and of course, Samba.

Before we close this chapter, let's take a look at a simple SMB connection. This is some pretty technical data—which isn't really necessary to administer Samba—so you can skip over it if you like. We present this information largely as a way to help you get familiar with how the SMB protocol negotiates connections with other computers on the network.

There are four steps that the client and server must complete in order to establish a connection to a resource:

We will examine each of these steps through the eyes of a useful tool that we mentioned earlier: the modified tcpdump that is available from the Samba web site.

>>> NBT Packet
NBT Session Request
Flags=0x81000044
Destination=ESCRIME      NameType=0x20 (Server)
Source=WIZZIN            NameType=0x00 (Workstation)

>>> NBT Packet
NBT Session Granted
Flags=0x82000000

At this point, there is an open channel between the client and server. Next, the client sends a message to the server to negotiate an SMB protocol. As mentioned earlier, the client sets its tree identifier (TID) field to zero, since it does not yet know what TID to use. A tree identifier is a number that represents a connection to a share on a server.

The command in the message is SMBnegprot, a request to negotiate a protocol variant that will be used for the entire session. Note that the client sends to the server a list of all of the variants that it can speak, not vice versa.

The server responds to the SMBnegprot request with an index into the list of variants that the client offered, starting with index 0, or with the value 0xFF if none of the protocol variants are acceptable. Continuing this example, the server responds with the value 5, which indicates that the NT LM 0.12 dialect will be used for the remainder of the session:

>>> NBT Packet
NBT Session Packet
Flags=0x0
Length=154

SMB PACKET: SMBnegprot (REQUEST)
SMB Command   =  0x72
Error class   =  0x0
Error code    =  0
Flags1        =  0x0
Flags2        =  0x0
Tree ID       =  0
Proc ID       =  5371
UID           =  0
MID           =  385
Word Count    =  0
Dialect=PC NETWORK PROGRAM 1.0
Dialect=MICROSOFT NETWORKS 3.0
Dialect=DOS LM1.2X002
Dialect=DOS LANMAN2.1
Dialect=Windows for Workgroups 3.1a
Dialect=NT LM 0.12

>>> NBT Packet
NBT Session Packet
Flags=0x0
Length=69

SMB PACKET: SMBnegprot (REPLY)
SMB Command   =  0x72
Error class   =  0x0
Error code    =  0
Flags1        =  0x0
Flags2        =  0x1
Tree ID       =  0
Proc ID       =  5371
UID           =  0
MID           =  385
Word Count    =  02
[000] 05 00

The next step is to transmit session and login parameters for the session. This includes the account name and password (if there is one), the workgroup name, the maximum size of data that can be transferred, and the number of pending requests that may be in the queue at any one time.

In the following example, the Session Setup command presented allows for an additional SMB command to be piggybacked onto it. The letter X at the end of the command name indicates this, and the hexadecimal code of the second command is given in the Com2 field. In this case the command is 0x75, which is the Tree Connect and X command. The SMBtconX message looks for the name of the resource in the smb_buf buffer. (This is the last field listed in the following request.) In this example, smb_buf contains the string \\ESCRIME\PUBLIC, which is the full pathname to a shared directory on node ESCRIME. Using the "and X" commands like this speeds up each transaction, since the server doesn't have to wait on the client to make a second request.

Note that the TID is still zero. The server will provide a TID to the client once the session has been established and a connection has been made to the requested resource. In addition, note that the password is sent in the open. We can change this later using encrypted passwords:

>>> NBT Packet
NBT Session Packet
Flags=0x0
Length=139

SMB PACKET: SMBsesssetupX (REQUEST)
SMB Command   =  0x73
Error class   =  0x0
Error code    =  0
Flags1        =  0x10
Flags2        =  0x0
Tree ID       =  0
Proc ID       =  5371
UID           =  1
MID           =  385
Word Count    =  13
Com2=0x75
Res1=0x0
Off2=106
MaxBuffer=2920
MaxMpx=2
VcNumber=0
SessionKey=0x1FF2
CaseInsensitivePasswordLength=1
CaseSensitivePasswordLength=1
Res=0x0
Capabilities=0x1
Pass1&Pass2&Account&Domain&OS&LanMan=
  KRISTIN PARKSTR Windows 4.0 Windows 4.0
PassLen=2
Passwd&Path&Device=
smb_bcc=22
smb_buf[]=\\ESCRIME\PUBLIC

For the final step, the server returns a TID to the client, indicating that the user has been authorized access and that the resource is ready to be used. It also sets the ServiceType field to "A" to indicate that this is a file service. Available service types are:

The output is:

>>> NBT Packet
NBT Session Packet
Flags=0x0
Length=78

SMB PACKET: SMBsesssetupX (REPLY)
SMB Command   =  0x73
Error class   =  0x0
Error code    =  0
Flags1        =  0x80
Flags2        =  0x1
Tree ID       =  121
Proc ID       =  5371
UID           =  1
MID           =  385
Word Count    =  3
Com2=0x75
Off2=68
Action=0x1
[000] Unix Samba 1.9.1
[010] PARKSTR

SMB PACKET: SMBtconX (REPLY) (CHAINED)
smbvwv[]=
Com2=0xFF
Off2=78
smbbuf[]=
ServiceType=A:

Now that a TID has been assigned, the client may issue any sort of command that it would use on a local disk drive. It can open files, read and write to them, delete them, create new files, search for filenames, and so on.

Let's take another look at this configuration file, this time from a higher level:

[global]
	...
[homes]
	...
[printers]
	...
[test]
	...

The names inside the square brackets delineate unique sections of the smb.conf file; each section names the share (or service) that the section refers to. For example, the [test] and [homes] sections are each unique disk shares; they contain options that map to specific directories on the Samba server. The [printers] share contains options that map to various printers on the server. All the sections defined in the smb.conf file, with the exception of the [global] section, will be available as a disk or printer share to clients connecting to the Samba server.

The remaining lines are individual configuration options unique to that share. These options will continue until a new bracketed section is encountered, or until the end of the file is reached. Each configuration option follows a simple format:

option = value

Options in the smb.conf file are set by assigning a value to them. We should warn you up front that some of the option names in Samba are poorly chosen. For example, read only is self-explanatory, and is typical of many recent Samba options. public is an older option, and is vague; it now has a less-confusing synonym guest ok (may be accessed by guests). We describe some of the more common historical names in this chapter in sections that highlight each major task. In addition, Appendix C, contains an alphabetical index of all the configuration options and their meanings.

volume = The Big Bad Hard Drive Number 3543

netbios aliases = sales, accounting, payroll
netbios aliases = sales accounting payroll

PATH = /EXPORT/SAMBA/SIMPLE

comment = The first share that has the primary copies \
          of the new Teamworks software product.

#  This is the printers section. We have given a minimum print
;  space of 2000 to prevent some errors that we've seen when
;  the spooler runs out of space.

[printers]
	public = yes
	min print space = 2000

# kill -SIGHUP 893

Samba includes a complete set of variables for determining characteristics of the Samba server and the clients to which it connects. Each of these variables begins with a percent sign, followed by a single uppercase or lowercase letter, and can be used only on the right side of a configuration option (e.g., after the equal sign):

[pub]
    path = /home/ftp/pub/%a

The %a stands for the client machine's architecture (e.g., WinNT for Windows NT, Win95 for Windows 95 or 98, or WfWg for Windows for Workgroups). Because of this, Samba will assign a unique path for the [pub] share to client machines running Windows NT, a different path for client machines running Windows 95, and another path for Windows for Workgroups. In other words, the paths that each client would see as its share differ according to the client's architecture, as follows:

/home/ftp/pub/WinNT
/home/ftp/pub/Win95
/home/ftp/pub/WfWg

Using variables in this manner comes in handy if you wish to have different users run custom configurations based on their own unique characteristics or conditions. Samba has 19 variables, as shown in Table 4.1.

Here's another example of using variables: let's say that there are five clients on your network, but one client, fred, requires a slightly different [homes] configuration loaded when it connects to the Samba server. With Samba, it's simple to attack such a problem:

[homes]
	...
	include = /usr/local/samba/lib/smb.conf.%m
	...

The include option here causes a separate configuration file for each particular NetBIOS machine (%m) to be read in addition to the current file. If the hostname of the client machine is fred, and if a smb.conf.fred file exists in the samba_dir/lib/ directory (or whatever directory you've specified for your configuration files), Samba will insert that configuration file into the default one. If any configuration options are restated in smb.conf.fred, those values will override any options previously encountered in that share. Note that we say "previously." If any options are restated in the main configuration file after the include option, Samba will honor those restated values for the share in which they are defined.

Here's the important part: if there is no such file, Samba will not generate an error. In fact, it won't do anything at all. This allows you to create only one extra configuration file for fred when using this strategy, instead of one for each NetBIOS machine that is on the network.

Machine-specific configuration files can be used both to customize particular clients and to make debugging Samba easier. Consider the latter; if we have one client with a problem, we can use this approach to give it a private log file with a more verbose logging level. This allows us to see what Samba is doing without slowing down all the other clients or overflowing the disk with useless logs. Remember, with large networks you may not always have the option to restart the Samba server to perform debugging!

You can use each of the variables in Table 4.1 to give custom values to a variety of Samba options. We will highlight several of these options as we move through the next few chapters.

The [globals] section appears in virtually every Samba configuration file, even though it is not mandatory to define one. Any option set in this section of the file will apply to all the other shares, as if the contents of the section were copied into the share itself. There is one catch: other sections can list the same option in their section with a new value; this has the effect of overriding the value specified in the [globals] section.

To illustrate this, let's again look at the opening example of the chapter:

[global]
	log level = 1
	max log size = 1000
	socket options = TCP_NODELAY IPTOS_LOWDELAY
	guest ok = no
[homes]
	browseable = no
	map archive = yes
[printers]
	path = /usr/tmp
	guest ok = yes
	printable = yes
	min print space = 2000
[test]
	browseable = yes
	read only = yes
	guest ok = yes
	path = /export/samba/test

In the previous example, if we were going to connect a client to the [test] share, Samba would first read in the [globals] section. At that point, it would set the option guest ok = no as the global default for each share it encounters throughout the configuration file. This includes the [homes] and [printers] shares. When it reads in the [test] share, however, it would then find the configuration option guest ok = yes, and override the default from the [globals] section with the value yes in the context of the [pub] share.

Any option that appears outside of a section (before the first marked section) is also assumed to be a global option.

If a client attempts to connect to a share that doesn't appear in the smb.conf file, Samba will search for a [homes] share in the configuration file. If one exists, the unidentified share name is assumed to be a Unix username, which is queried in the password database of the Samba server. If that username appears, Samba assumes the client is a Unix user trying to connect to his or her home directory on the server.

For example, assume a client machine is connecting to the Samba server hydra for the first time, and tries to connect to a share named [alice]. There is no [alice] share defined in the smb.conf file, but there is a [homes], so Samba searches the password database file and finds an alice user account is present on the system. Samba then checks the password provided by the client against user alice's Unix password—either with the password database file if it's using non-encrypted passwords, or Samba's smbpasswd file if encrypted passwords are in use. If the passwords match, then Samba knows it has guessed right: the user alice is trying to connect to her home directory. Samba will then create a share called [alice] for her.

The process of using the [homes] section to create users (and dealing with their passwords) is discussed in more detail in the Chapter 6.

The third special section is called [printers] and is similar to [homes]. If a client attempts to connect to a share that isn't in the smb.conf file, and its name can't be found in the password file, Samba will check to see if it is a printer share. Samba does this by reading the printer capabilities file (usually /etc/printcap) to see if the share name appears there.^[1] If it does, Samba creates a share named after the printer.

Like [homes], this means you don't have to maintain a share for each of your system printers in the smb.conf file. Instead, Samba honors the Unix printer registry if you request it to, and provides the registered printers to the client machines. There is, however, an obvious limitation: if you have an account named fred and a printer named fred, Samba will always find the user account first, even if the client really needed to connect to the printer.

The process of setting up the [printers] share is discussed in more detail in Chapter 7.

Options in the Samba configuration files fall into one of two categories: global or share. Each category dictates where an option can appear in the configuration file.

In addition, the values that a configuration option can take can be divided into four categories. They are as follows:

The global config file option specifies a replacement configuration file that will be loaded when the option is encountered. If the target file exists, the remainder of the current configuration file, as well as the options encounter so far, will be discarded; Samba will configure itself entirely with the options in the new file. The config file option takes advantage of the variables above, which is useful in the event that you want load a special configuration file based on the machine name or user of the client that it connecting.

For example, the following line instructs Samba to use a configuration file specified by the NetBIOS name of the client connecting, if such a file exists. If it does, options specified in the original configuration file are ignored. The following example attempts to lead a new configuration file based on the client's NetBIOS name:

[global]
	config file = /usr/local/samba/lib/smb.conf.%m

If the configuration file specified does not exist, the option is ignored and Samba will continue to configure itself based on the current file.

This option, discussed in greater detail earlier, copies the target file into the current configuration file at the point specified, as shown in Figure 4.1. This option also takes advantage of the variables specified earlier in the chapter, which is useful in the event that you want load configuration options based on the machine name or user of the client that it connecting. You can use this option as follows:

[global]
	include = /usr/local/samba/lib/smb.conf.%m

If the configuration file specified does not exist, the option is ignored. Remember that any option specified previously is overridden. In Figure 4.1, all three options will override their previous values.

Figure 4.1. The include option in a Samba configuration file

The include option cannot understand the variables %u (user), %p (current share's rout directory), or %s (current share) because they are not set at the time the file is read.

The copy configuration option allows you to clone the configuration options of the share name that you specify in the current share. The target share must appear earlier in the configuration file than the share that is performing the copy. For example:

[template]
	writable = yes
	browsable = yes
	valid users = andy, dave, peter

[data]
	path = /usr/local/samba
	copy = template

Note that any options in the share that invoked the copy directive will override those in the cloned share; it does not matter whether they appear before or after the copy directive.

Table 4.3 summarizes the server configuration options introduced previously. Note that all three of these options are global in scope; in other words, they must appear in the [global] section of the configuration file.

netbios name = YORKVM1

[global]
	server string = Samba %v on (%h)

server string = Samba %v

[global]
	workgroup = SIMPLE

The basic Samba configuration options for disk shares previously introduced are listed in Table 4.4.

path

This option, which has the synonym directory, indicates the pathname at the root of the file or printing share. You can choose any path on the Samba server, so long as the owner of the Samba process that is connecting has read and write access to that directory. If the path is for a printing share, it should point to a temporary directory where files can be written on the server before being spooled to the target printer ( /tmp and /var/spool are popular choices). If this path is for a disk share, the contents of the folder representing the share name on the client will match the content of the directory on the Samba server. For example, if we have the following disk share listed in our configuration file:

[network]
	path = /export/samba/network
	writable = yes
	guest ok = yes

And the contents of the directory /usr/local/network on the Unix side are:

$ ls -al /export/samba/network
drwxrwxrwx  9  root   nobody  1024  Feb 16 17:17  .
drwxr-xr-x  9  nobody nobody  1024  Feb 16 17:17  ..
drwxr-xr-x  9  nobody nobody  1024  Feb 16 17:17  quicken
drwxr-xr-x  9  nobody nobody  1024  Feb 16 17:17  tax98
drwxr-xr-x  9  nobody nobody  1024  Feb 16 17:17  taxdocuments

Then we should see the equivalent of Figure 4.5 on the client side.

Figure 4.5. Windows client view of a network filesystem specified by path

[global]
	guest account = ftp
[accounting]
	path = /usr/local/account
	guest ok = yes

comment

The comment option allows you to enter a comment that will be sent to the client when it attempts to browse the share. The user can see the comment by listing Details on the share folder under the appropriate computer in the Windows Network Neighborhood, or type the command NET VIEW at an MS-DOS prompt. For example, here is how you might insert a comment for a [network] share:

[network]
	comment = Network Drive
	path = /export/samba/network

This yields a folder similar to Figure 4.6 on the client side. Note that with the current configuration of Windows, this comment will not be shown once a share is mapped to a Windows network drive.

Figure 4.6. Windows client view of a share comment

Be sure not to confuse the comment option, which documents a Samba server's shares, with the server string option, which documents the server itself.

[network]
	comment = Network Drive
	volume = ASVP-102-RTYUIKA
	path = /home/samba/network

read only = yes
writeable = no

read only = no
writeable = yes

The networking options we introduced above are summarized in Table 4.5.

hosts allow = 192.168.220. localhost

hosts deny = ALL EXCEPT .example.com

interfaces = 192.168.220.100/255.255.255.0 192.168.210.30/255.255.255.0

interfaces = 192.168.220.100/24 192.168.210.30/24

bind interfaces only = yes

interfaces = 192.168.220.100/24 192.168.210.30/24
socket address = 192.168.210.30

The netbios aliases option can be used to give the Samba server more than one NetBIOS name. Each NetBIOS name listed as a value will be displayed in the Network Neighborhood of a browsing machine. When a connection is requested to any machine, however, it will connect to the same Samba server.

This might come in handy, for example, if you're transferring three departments' data to a single Unix server with modern large disks, and are retiring or reallocating the old NT servers. If the three servers are called sales, accounting, and admin, you can have Samba represent all three servers with the following options:

[global]
	netbios aliases = sales accounting admin
	include = /usr/local/samba/lib/smb.conf.%L

See Figure 4.7 for what the Network Neighborhood would display from a client.When a client attempts to connect to Samba, it will specify the name of the server that it's trying to connect to, which you can access through the %L variable. If the requested server is sales, Samba will include the /usr/local/samba/lib/smb.conf.sales file. This file might contain global and share declarations exclusively for the sales team, such as the following:

[global]
	workgroup = SALES
	hosts allow = 192.168.10.255

[sales1998]
	path = /usr/local/samba/sales/sales1998/
...

This particular example would set the workgroup to SALES as well, and set the IP address to allow connections only from the SALES subnet (192.168.10). In addition, it would offer shares specific to the sales department.

Figure 4.7. Using NetBIOS aliases for a Samba server

If you wish to use the system logger (syslog ) in addition to or in place of the standard Samba logging file, Samba provides options for this as well. However, to use syslog, the first thing you will have to do is make sure that Samba was built with the configure --with-syslog option. See Chapter 2 for more information on configuring and compiling Samba.

Once that is done, you will need to configure your /etc/syslog.conf to accept logging information from Samba. If there is not already a daemon.* entry in the /etc/syslog.conf file, add the following:

daemon.*        /var/log/daemon.log

This specifies that any logging information from system daemons will be stored in the /var/log/daemon.log file. This is where the Samba information will be stored as well. From there, you can specify the following global option in your configuration file:

syslog = 2

This specifies that any logging messages with a level of 1 will be sent to both the syslog and the Samba logging files. (The mappings to syslog priorities are described in the upcoming Section 4.8.2.5.) Let's assume that we set the regular log level option above to 4. Any logging messages with a level of 2, 3, or 4 will be sent to the Samba logging files, but not to the syslog. Only level 1 logging messages will be sent to both. If the syslog value exceeds the log level value, nothing will be written to the syslog.

If you want to specify that messages be sent only to syslog—and not to the standard Samba logging files—you can place this option in the configuration file:

syslog only = yes

If this is the case, any logging information above the number specified in the syslog option will be discarded, just like the log level option.

Table 4.7 lists each of the logging configuration options that Samba can use.

[global]
	log file = /usr/local/logs/samba.log

[global]
log file = /usr/local/logs/samba.log.%m
log level = 3

[global]
log file = /usr/local/logs/samba.log.%m
max log size = 1000

12/31/98 12:03:34 hydra (192.168.220.101) connect to server network as user davecb

hydra (192.168.220.101) connect to server network as user davecb

[global]
	log level = 3
	syslog = 1

[global]
	syslog only = 
yes

You can restrict a share from being in a browse list by using the browseable option. This boolean option prevents a share from being seen in the Network Neighborhood at all. For example, to prevent the [data] share from the previous chapter from being visible, we could write:

[data]
	path = /home/samba/data
	browseable = no
	guest ok = yes
	comment = Data Drive
	volume = Sample-Data-Drive
	writeable = yes

Although you typically don't want to do this to an ordinary disk share, the browseable option is useful in the event that you need to create a share with contents that you do not want others to see, such as a [netlogin] share for storing logon scripts for Windows domain control (see Chapter 6 for more information on logon scripts).

Another example is the [homes] share. This share is often marked non-browsable so that a share named [homes] won't appear when its machine's resources are browsed. However, if a user alice logs on and looks at the machine's shares, an [alice] share will appear under the machine. What if we wanted to make sure alice's share appeared to everyone before she logs in? This could be done with the global auto services option. This option preloads shares into the browse list to ensure that they are always visible:

[global]
	...
	auto services = alice
	...

In the event that a user cannot successfully connect to a share, you can specify a default share to which they can connect. Since you do not know who will default to this share at any time, you will probably want to set the guest ok option to yes for this share. Specifying a default service can be useful when sending the utterly befuddled to a directory of help files. For example:

[global]
	...
	default service = helpshare
	...

[helpshare]
	path = /home/samba/helpshare/%S
	browseable = yes
	guest ok = yes
	comment = Default Share for Unsuccessful Connections
	volume = Sample-Data-Drive
	writeable = no

Note that we used the %S variable in the path option. If you use the %S variable, it will refer to the requested nonexistent share (the original share requested by the user), not the name of the resulting default share. This allows us to create different paths with the names of each server, which can provide more customized help files for users. In addition, any underscores ( _ ) specified in the requested share will be converted to slashes ( / ) when the %S variable is used.

As mentioned in Chapter 1, one machine in each subnet always keeps a list of the currently active machines. This list is called the browse list and the server that maintains it is called the local master browser. As machines come on and off the network, the local master browser continually updates the information in the browse list and provides it to any machine that requests it.

A computer becomes a local master browser by holding a browsing election on the local subnet. Browsing elections can be called at any time. Samba can rig a browsing election for a variety of outcomes, including always becoming the local master browser of the subnet or never becoming it. For example, the following options, which we've added to the configuration file from Chapter 4, will ensure that Samba always wins the election for local master browser no matter which machines are also present:

[global]
	netbios name = HYDRA
	server string = Samba %v on (%L)
	workgroup = SIMPLE

	#  Browsing election options
	os level = 34
	local master = yes

	#  Networking configuration options
	hosts allow = 192.168.220. 134.213.233. localhost
	hosts deny = 192.168.220.102
	interfaces = 192.168.220.100/255.255.255.0 \
                         134.213.233.110/255.255.255.0

	# Debug logging information
	log level = 2
	log file = /var/log/samba.log.%m
	max log size = 50
	debug timestamp = yes

[data]
	path = /home/samba/data
	browseable = yes
	guest ok = yes
	comment = Data Drive
	volume = Sample-Data-Drive
	writable = yes

However, what if we didn't always want to win the election? What if we wanted to yield browsing to a Windows NT Server if present? In order to do that, we need to learn how browsing elections work. As you already know, each machine that takes place in the election must broadcast information about itself. This information includes the following:

Here is how the election is decided. Operating systems are assigned a binary value according to their version, as shown in Table 5.1.

Following that, each computer on the network is assigned a separate value according to its role, as shown in Table 5.2.

Elections are decided in the following order:

As a result, if you want Samba to take the role of a local master browser, but only if there isn't a Windows NT Server (4.0 or 3.51) on the network, you could change the os level parameter in the previous example to:

os level = 31

This will cause Samba to immediately lose the election to a Windows NT 4.0 or Windows NT 3.5 Server, both of which have a higher operating systems level. On the other hand, if you wanted to decide the local master browser on the basis of the network role, such as which machine is the primary domain controller, you could set the os level to match the highest type of operating system on the network and let the election protocol fall down to the next level.

How can you can tell if a machine is a local master browser? By using the nbtstat command. Place the NetBIOS name of the machine you wish to check after the -a option:

C:\>nbtstat -a hydra

       NetBIOS Remote Machine Name Table

 Name                            Type         Status
----------------------------------------------------------
 HYDRA                     <00>  UNIQUE       Registered
 HYDRA                     <03>  UNIQUE       Registered
 HYDRA                     <20>  UNIQUE       Registered
 .._ _MSBROWSE_ _.         <01>  GROUP        Registered
 SIMPLE                    <00>  GROUP        Registered
 SIMPLE                    <1D>  UNIQUE       Registered
 SIMPLE                    <1E>  GROUP        Registered

 MAC Address = 00-00-00-00-00-00

The resource entry that you're looking for is the .._ _MSBROWSE_ _.<01>. This indicates that the server is currently acting as the local master browser for the current subnet. In addition, if the machine is a Samba server, you can check the Samba nmbd log file for an entry such as:

nmbd/nmbd_become_lmb.c:become_local_master_stage2(406)
*****
Samba name server HYDRA is now a local master browser for
workgroup SIMPLE on subnet 192.168.220.100
****

Finally, Windows NT servers serving as primary domain controllers contain a sneak that allows them to assume the role of the local master browser in certain conditions; this is called the preferred master browser bit. Earlier, we mentioned that Samba could set this bit on itself as well. You can enable it with the preferred master option:

#  Browsing election options
os level = 33
local master = yes
preferred master = yes

If the preferred master bit is set, the machine will force a browsing election at startup. Of course, this is needed only if you set the os level option to match the Windows NT machine. We recommend that you don't use this option if another machine also has the role of preferred master, such as an NT server.

In the opening chapter, we mentioned that in order for a Windows workgroup or domain to extend into multiple subnets, one machine would have to take the role of the domain master browser. The domain master browser propagates browse lists across each of the subnets in the workgroup. This works because each local master browser periodically synchronizes its browse list with the domain master browser. During this synchronization, the local master browser passes on any server that the domain master browser does not have in its browse list, and vice versa. In a perfect world, each local master browser would eventually have the browse list for the entire domain.

Unlike the local master browser, there is no election to determine which machine assumes the role of the domain master browser. Instead, the administrator has to set it manually. By Microsoft design, however, the domain master browser and the primary domain controller (PDC) both register a resource type of <1B>, so the roles—and the machines—are inseparable.

If you have a Windows NT server on the network acting as a PDC, we recommend that you do not use Samba to become the domain master browser. The reverse is true as well: if Samba is taking on the responsibilities of a PDC, we recommend making it the domain master browser as well. Although it is possible to split the roles with Samba, this is not a good idea. Using two different machines to serve as the PDC and the domain master browser can cause random errors to occur on a Windows workgroup.

Samba can assume the role of a domain master browser for all subnets in the workgroup with the following option:

domain master = yes

You can verify that a Samba machine is in fact the domain master browser by checking the nmbd log file:

nmbd/nmbd_become_dmb.c:become_domain_master_stage2(118)
*****
Samba name server HYDRA is now a domain master browser for
workgroup SIMPLE on subnet 192.168.220.100
*****

Or you can use the nmblookup command that comes with the Samba distribution to query for a unique <1B> resource type in the workgroup:

# nmblookup SIMPLE#1B
Sending queries to 192.168.220.255
192.168.220.100 SIMPLE<1b>