Using Samba | O'Reilly Media

Content preview·Buy reprint rights for this chapter

If you are a typical system administrator, then you know what it means to be swamped with work. Your daily routine is filled with endless hardware incompatibility issues, system outages, data backup problems, and a steady stream of angry users. So adding another program to the mix of tools that you have to maintain may sound a bit perplexing. However, if you're determined to reduce the complexity of your work environment, as well as the workload of keeping it running smoothly, Samba may be the tool you've been waiting for.

A case in point: one of the authors of this book used to look after 70 Unix developers sharing 5 Unix servers. His neighbor administered 20 Windows 3.1 users and 5 OS/2 and Windows NT servers. To put it mildly, the Windows 3.1 administrator was swamped. When he finally left—and the domain controller melted—Samba was brought to the rescue. Our author quickly replaced the Windows NT and OS/2 servers with Samba running on a Unix server, and eventually bought PCs for most of the company developers. However, he did the latter without hiring a new PC administrator; the administrator now manages one centralized Unix application instead of fifty distributed PCs.

If you know you're facing a problem with your network and you're sure there is a better way, we encourage you to start reading this book. Or, if you've heard about Samba and you want to see what it can do for you, this is also the place to start. We'll get you started on the path to understanding Samba and its potential. Before long, you can provide Unix services to all your Windows machines—all without spending tons of extra time or money. Sound enticing? Great, then let's get started.

Samba is a suite of Unix applications that speak the SMB (Server Message Block) protocol. Many operating systems, including Windows and OS/2, use SMB to perform client-server networking. By supporting this protocol, Samba allows Unix servers to get in on the action, communicating with the same networking protocol as Microsoft Windows products. Thus, a Samba-enabled Unix machine can masquerade as a server on your Microsoft network and offer the following services:

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

Samba is a suite of Unix applications that speak the SMB (Server Message Block) protocol. Many operating systems, including Windows and OS/2, use SMB to perform client-server networking. By supporting this protocol, Samba allows Unix servers to get in on the action, communicating with the same networking protocol as Microsoft Windows products. Thus, a Samba-enabled Unix machine can masquerade as a server on your Microsoft network and offer the following services:

Share one or more filesystems
Share printers installed on both the server and its clients
Assist clients with Network Neighborhood browsing
Authenticate clients logging onto a Windows domain
Provide or assist with WINS name server resolution

Samba is the brainchild of Andrew Tridgell, who currently heads the Samba development team from his home of Canberra, Australia. The project was born in 1991 when Andrew created a fileserver program for his local network that supported an odd DEC protocol from Digital Pathworks. Although he didn't know it at the time, that protocol later turned out to be SMB. A few years later, he expanded upon his custom-made SMB server and began distributing it as a product on the Internet under the name SMB Server. However, Andrew couldn't keep that name—it already belonged to another company's product—so he tried the following Unix renaming approach:

grep -i 's.*m.*b' /usr/dict/words

And the response was:

salmonberry samba sawtimber scramble

Thus, the name "Samba" was born.

Today, the Samba suite revolves around a pair of Unix daemons that provide shared resources—or shares—to SMB clients on the network. (Shares are sometimes called services as well.) These daemons are:

smbd

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

As explained earlier, Samba can help Windows and Unix machines coexist in the same network. However, there are some specific reasons why you might want to set up a Samba server on your network:

You don't want to pay for—or can't afford—a full-fledged Windows NT server, yet you still need the functionality that one provides.
You want to provide a common area for data or user directories in order to transition from a Windows server to a Unix one, or vice versa.
You want to be able to share printers across both Windows and Unix workstations.
You want to be able to access NT files from a Unix server.

Let's take a quick tour of Samba in action. Assume that we have the following basic network configuration: a Samba-enabled Unix machine, to which we will assign the name hydra, and a pair of Windows clients, to which we will assign the names phoenix and chimaera, all connected via a local area network (LAN). Let's also assume that hydra also has a local inkjet printer connected to it, lp, and a disk share named network—both of which it can offer to the other two machines. A graphic of this network is shown in Figure 1.1.

Figure 1.1: A simple network setup with a Samba server

In this network, each of the computers listed share the same workgroup . A workgroup is simply a group nametag that identifies an arbitrary collection of computers and their resources on an SMB network. There can be several workgroups on the network at any time, but for our basic network example, we'll have only one: the SIMPLE workgroup.

If everything is properly configured, we should be able to see the Samba server, hydra, through the Network Neighborhood of the phoenix

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

Now that you have had a brief tour of Samba, let's take some time to get familiar with Samba's adopted environment: an SMB/CIFS network. Networking with SMB is significantly different from working with a Unix TCP/IP network, because there are several new concepts to learn and a lot of information to cover. First, we will discuss the basic concepts behind an SMB network, followed by some Microsoft implementations of it, and finally we will show you where a Samba server can and cannot fit into the picture.

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.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

With that amount of background, we can now talk about some of Microsoft's implementations of the preceding concepts in the CIFS/SMB networking world. And, as you might expect, there are some complex extensions to introduce as well.

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. 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.

Why all the difficulty? The protocol that Windows domain controllers use to communicate with their clients and other domain controllers is proprietary and has not been released by Microsoft. This has forced the Samba development team to reverse-engineer the domain controller protocol to see which codes perform specific tasks.

Section 1.4.1.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

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

As mentioned earlier, Samba actually contains several programs that serve different but related purposes. Let's introduce each of them briefly, and show how they work together. The majority of the programs that come with the Samba distribution center on its two daemons. Let's take a refined look at the responsibilities of each daemon:

smbd: The smbd daemon is responsible for managing the shared resources between the Samba server machine and its clients. It provides file, print, and browser services to SMB clients across one or more networks. smdb handles all notifications between the Samba server and the network clients. In addition, it is responsible for user authentication, resource locking, and data sharing through the SMB protocol.
nmbd: The nmbd daemon is a simple nameserver that mimics the WINS and NetBIOS name server functionality, as you might expect to encounter with the LAN Manager package. This daemon listens for nameserver requests and provides the appropriate information when called upon. It also provides browse lists for the Network Neighborhood and participates in browsing elections.

The Samba distribution also comes with a small set of Unix command-line tools:

smbclient: An FTP-like Unix client that can be used to connect to Samba shares
smbtar: A program for backing up data in shares, similar to the Unix tar command
nmblookup: A program that provides NetBIOS over TCP/IP name lookups
smbpasswd: A program that allows an administrator to change the encrypted passwords used by Samba

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

Samba is available in both binary and source format from a set of mirror sites across the Internet. The primary home site for Samba is located at http://www.samba.org/.

However, if you don't want to wait for packets to arrive all the way from Australia, mirror sites for Samba can be found at any of several locations on the Internet. A list of mirrors is given at the primary Samba home page.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

Samba 2.0 was an eagerly-awaited package. The big additions to Samba 2.0 are more concrete support for NT Domains and the new Samba Web Administration Tool (SWAT), a browser-based utility for configuring Samba. However, there are dozens of other improvements that were introduced in the summer and fall of 1998.

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:

Name/browsing service now supports approximately 35,000 simultaneous clients.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

Samba is a wonderful tool with potential for even the smallest SMB/CIFS network. This chapter presented you with a thorough introduction to what Samba is, and more importantly, how it fits into a Windows network. The next series of chapters will help you set up Samba on both the Unix server side, where its two daemons reside, as well as configure the Windows 95, 98, and NT clients to work with Samba. Before long, the aches and pains of your heterogeneous network may seem like a thing of the past. Welcome to the wonderful world of Samba!

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

Now that you know what Samba can do for you and your users, it's time to get your own network set up. Let's start with the installation of Samba itself on a Unix system. When dancing the samba, one learns by taking small steps. It's just the same when installing Samba; we need to teach it step by step. This chapter will help you to start off on the right foot.

For illustrative purposes, we will be installing the 2.0.4 version of the Samba server on a Linux system running version 2.0.31 of the kernel. However, the installation steps are the same for all of the platforms that Samba supports. A typical installation will take about an hour to complete, including downloading the source files and compiling them, setting up the configuration files, and testing the server.

Here is an overview of the steps:

Download the source or binary files.
Read the installation documentation.
Configure a makefile.
Compile the server code.
Install the server files.
Create a Samba configuration file.
Test the configuration file.
Start the Samba daemons.
Test the Samba daemons.

If you want to download the latest version, the primary web site for the Samba software is http://www.samba.org. Once connected to this page, you'll see links to several Samba mirror sites across the world, both for the standard Samba web pages and sites devoted exclusively to downloading Samba. For the best performance, choose a site that is closest to your own geographic location.

The standard Samba web sites have Samba documentation and tutorials, mailing list archives, and the latest Samba news, as well as source and binary distributions of Samba. The download sites (sometimes called

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

If you want to download the latest version, the primary web site for the Samba software is http://www.samba.org. Once connected to this page, you'll see links to several Samba mirror sites across the world, both for the standard Samba web pages and sites devoted exclusively to downloading Samba. For the best performance, choose a site that is closest to your own geographic location.

The standard Samba web sites have Samba documentation and tutorials, mailing list archives, and the latest Samba news, as well as source and binary distributions of Samba. The download sites (sometimes called FTP sites) have only the source and binary distributions. Unless you specifically want an older version of the Samba server or are going to install a binary distribution, download the latest source distribution from the closest mirror site. This distribution is always named:

samba-latest.tar.gz

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:

The binary packages can lag behind the latest version of the software by one or two (maybe more) minor releases, especially after a series of small changes and for less popular platforms. Compare the release notes for the source and binary packages to make sure that there aren't any new features that you need on your platform.
If you use a precompiled binary, you will need to ensure that you have the correct libraries required by the executables. On some platforms the executables are statically linked so this isn't an issue, but on modern Unix operating systems (e.g., Linux, SGI Irix, Solaris, HP-UX, etc.), libraries are often dynamically linked. This means that the binary looks for the right version of each library on your system, so you may have to install a new version of a library. The

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

The source distribution of Samba 2.0 and above doesn't initially have a makefile. Instead, one is generated through a GNU configure script, which is located in the samba-2.0.x /source/ directory. The configure script, which must be run as root, takes care of the machine-specific issues of building Samba. However, you still may want to decide on some global options. Global options can be set by passing options on the command-line:

# ./configure --with-ssl

For example, this will configure the Samba makefile with support for the Secure Sockets Layer (SSL) encryption protocol. If you would like a complete list of options, type the following:

#./configure --help

Each of these options enable or disable various features. You typically enable a feature by specifying the --with- feature option, which will cause the feature to be compiled and installed. Likewise, if you specify a --without- feature option, the feature will be disabled. As of Samba 2.0.5, each of the following features is disabled by default:

--with-smbwrapper: Include SMB wrapper support, which allows executables on the Unix side to access SMB/CIFS filesystems as if they were regular Unix filesystems. We recommend using this option. However, at this time this book went to press, there were several incompatibilities between the smbwrapper package and the GNU libc version 2.1, and it would not compile on Red Hat 6.0. Look for more information on these incompatibilities on the Samba home page.
--with-afs: Include support of the Andrew Filesystem from Carnegie Mellon University. If you're going to serve AFS files via Samba, we recommend compiling Samba once first without enabling this feature to ensure that everything runs smoothly. Once that version is working smoothly, recompile Samba with this feature enabled and compare any errors you might receive against the previous setup.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

At this point you should be ready to build the Samba executables. Compiling is also easy: in the source directory, type make on the command line. The make utility will produce a stream of explanatory and success messages, beginning with:

Using FLAGS = -O -Iinclude ...

This build includes compiles for both smbd and nmbd, and ends in a linking command for bin/make_ printerdef. For example, here is a sample make of Samba version 2.0.4 on a Linux server:

# make
Using FLAGS =  -O -Iinclude -I./include -I./ubiqx -I./smbwrapper -DSMBLOGFILE="/
usr/local/samba/var/log.smb" -DNMBLOGFILE="/usr/local/samba/var/log.nmb" -
DCONFIGFILE="/usr/local/samba/lib/smb.conf" -DLMHOSTSFILE="/usr/local/samba/lib/
lmhosts"   -DSWATDIR="/usr/local/samba/swat" -DSBINDIR="/usr/local/samba/bin" -
DLOCKDIR="/usr/local/samba/var/locks" -DSMBRUN="/usr/local/samba/bin/smbrun" -
DCODEPAGEDIR="/usr/local/samba/lib/codepages" -DDRIVERFILE="/usr/local/samba/lib/
printers.def" -DBINDIR="/usr/local/samba/bin" -DHAVE_INCLUDES_H -DPASSWD_
PROGRAM="/bin/passwd" -DSMB_PASSWD_FILE="/usr/local/samba/private/smbpasswd"
Using FLAGS32 =  -O -Iinclude -I./include -I./ubiqx -I./smbwrapper  -
DSMBLOGFILE="/usr/local/samba/var/log.smb" -DNMBLOGFILE="/usr/local/samba/var/log.
nmb" -DCONFIGFILE="/usr/local/samba/lib/smb.conf" -DLMHOSTSFILE="/usr/local/samba/
lib/lmhosts"   -DSWATDIR="/usr/local/samba/swat" -DSBINDIR="/usr/local/samba/bin" 
-DLOCKDIR="/usr/local/samba/var/locks" -DSMBRUN="/usr/local/samba/bin/smbrun" -
DCODEPAGEDIR="/usr/local/samba/lib/codepages" -DDRIVERFILE="/usr/local/samba/lib/
printers.def" -DBINDIR="/usr/local/samba/bin" -DHAVE_INCLUDES_H -DPASSWD_
PROGRAM="/bin/passwd" -DSMB_PASSWD_FILE="/usr/local/samba/private/smbpasswd"
Using LIBS = -lreadline -ldl  -lcrypt -lpam
Compiling smbd/server.c
Compiling smbd/files.c
Compiling smbd/chgpasswd.c

...(content omitted)...

Compiling rpcclient/cmd_samr.c
Compiling rpcclient/cmd_reg.c
Compiling rpcclient/cmd_srvsvc.c
Compiling rpcclient/cmd_netlogon.c
Linking bin/rpcclient
Compiling utils/smbpasswd.c
Linking bin/smbpasswd
Compiling utils/make_smbcodepage.c
Linking bin/make_smbcodepage
Compiling utils/nmblookup.c
Linking bin/nmblookup
Compiling utils/make_printerdef.c
Linking bin/make_printerdef

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

The key to configuring Samba is its lone configuration file: smb.conf . This configuration file can be very simple or extremely complex, and the rest of this book is devoted to helping you get deeply personal with this file. For now, however, we'll show you how to set up a single file service, which will allow you to fire up the Samba daemons and see that everything is running as it should be. In later chapters, you will see how to configure Samba for more complicated and interesting tasks.

The installation process does not automatically create an smb.conf configuration file, although several example files are included in the Samba distribution. To test the server software, though, we'll use the following file. It should be named smb.conf and placed in the /usr/local/samba/lib directory.

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

This brief configuration file tells the Samba server to offer the directory /export/samba/test on the server as an SMB/CIFS share called test. The server also becomes part of the named workgroup SIMPLE, which each of the clients must also be a part of. (Use your own workgroup here if you already know what it is.) We'll use the [test] share in the next chapter to set up the Windows clients. For now, you can complete the setup by performing the following commands as root on your Unix server:

# mkdir /export/samba/test
# chmod 777 /export/samba/test

We should point out that in terms of system security, this is the worst setup possible. For the moment, however, we only wish to test Samba, so we'll leave security out of the picture. In addition, there are some encrypted password issues that we will encounter with Windows clients later on, so this setup will afford us the least amount of headaches.

If you are using Windows 98 or Windows NT Service Pack 3 or above, you must add the following entry to the [global]

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

There are two Samba processes, smbd and nmbd , that need to be running for Samba to work correctly. There are three ways to start:

By hand
As stand-alone daemons
From inetd

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.

Section 2.5.2.1: BSD Unix

WIth a BSD-style Unix, you need to append the following code to the rc.local file, which is typically found in the /etc or /etc/rc.d directories:

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

This code is very simple; it checks to see if the smbd file has execute permissions on it, and if it does, it starts up each of the Samba daemons on system boot.

Section 2.5.2.2: System V Unix

With System V, things can get a little more complex. System V typically uses scripts to start and stop daemons on the system. Hence, you need to instruct Samba how to operate when it starts and when it stops. You can modify the contents of the /etc/rc.local directory and add something similar to the following program entitled smb :

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

It's hard to believe, but we're nearly done with the Samba server setup. All that's left to do is to make sure that everything is working as we think it should. A convenient way to do this is to use the smbclient program to examine what the server is offering to the network. If everything is set up properly, you should be able to do the following:

            # smbclient -U% -L localhost

Added interface ip=192.168.220.100 bcast=192.168.220.255 nmask=255.255.255.0
Domain=[SIMPLE] OS=[Unix] Server=[Samba 2.0.5a]

        Sharename      Type      Comment
        ---------      ----      -------
        test           Disk      For testing only, please
        IPC$           IPC       IPC Service (Samba 2.0.5a)

        Server               	    Comment
        ---------            	    -------
        HYDRA                	    Samba 2.0.5a

        Workgroup            	    Master
        ---------            	    -------
        SIMPLE               	    HYDRA

If there is a problem, don't panic! Try to start the daemons manually, and check the system output or the debug files at /usr/local/samba/var/log.smb to see if you can determine what happened. If you think it may be a more serious problem, skip to Chapter 7, for help on troubleshooting the Samba daemons.

If it worked, congratulations! You now have successfully set up the Samba server with a disk share. It's a simple one, but we can use it to set up and test the Windows 95 and NT clients in the next chapter. Then we will start making it more interesting by adding services such as home directories, printers, and security, and seeing how to integrate the server into a larger Windows domain.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

You'll be glad to know that configuring Windows to use your new Samba server is quite simple. SMB is Microsoft's native language for resource sharing on a local area network, so much of the installation and setup on the Windows client side has been taken care of already. The primary issues that we will cover in this chapter involve communication and coordination between Windows and Unix, two completely different operating systems.

Samba uses TCP/IP to talk to its clients on the network. If you aren't already using TCP/IP on your Windows computers, this chapter will show you how to install it. Then you'll need to configure your Windows machines to operate on a TCP/IP network. Once these two requirements have been taken care of, we can show how to access a shared disk on the Samba server.

This chapter is divided into three sections. The first section covers setting up Windows 95/98 computers while the second covers Windows NT 4.0 machines. The final section provides some prerequisite information on how SMB connections are made from Windows clients and servers, which is useful as we move into the later chapters of the book.

Unfortunately, Windows 95/98 wasn't designed for a PC to have more than one user; that concept is more inherent to a Unix operating system or Windows NT. However, Windows 95/98 does have limited support for multiple users: if you tell it, the operating system will keep a separate profile (desktop layout) and password file for each user. This is a far cry from true multiuser security. In other words, Windows 95/98 won't try to keep one user from destroying the work of another on the local hard drive like Unix, but profiles are a place to start.

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.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

Unfortunately, Windows 95/98 wasn't designed for a PC to have more than one user; that concept is more inherent to a Unix operating system or Windows NT. However, Windows 95/98 does have limited support for multiple users: if you tell it, the operating system will keep a separate profile (desktop layout) and password file for each user. This is a far cry from true multiuser security. In other words, Windows 95/98 won't try to keep one user from destroying the work of another on the local hard drive like Unix, but profiles are a place to start.

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.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

Configuring Windows NT is a little different than configuring Windows 95/98. In order to use Samba with Windows NT, you will need both the Workstation service and the TCP/IP protocol. Both come standard with NT, but we'll work through installing and configuring them because they may not be configured correctly.

There are six basic steps:

Assign the machine a name.
Install the Workstation service.
Install the TCP/IP protocol.
Set the machine's name and IP address.
Configure the DNS and WINS name services.
Bind the protocol and service together.

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.

Section 3.2.1.1: 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.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

We'll wrap up this chapter with a short tutorial on SMB/CIFS. SMB/CIFS is the protocol that Windows 95/98 and NT machines use to communicate with the Samba server and each other. At a high level, the SMB protocol suite is relatively simple. It includes commands for all of the file and print operations that you might do on a local disk or printer, such as:

Opening and closing a file
Creating and deleting files and directories
Reading and writing a file
Searching for files
Queueing and dequeueing files to a print spool

Each of these operations can be encoded into an SMB message and transmitted to and from a server. The original name SMB comes from their data format: these are versions of the standard DOS system-call data structures, or Server Message Blocks, redesigned for transmitting to another machine across a network.

Richard Sharpe of the Samba team defines SMB as a "request-response" protocol. 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.

Section 3.3.1.1: SMB header format

Table 3.1 shows the format of an SMB header. SMB commands are not required to use all the fields in the SMB header. For example, when a client first attempts to connect to a server, it does not yet have a tree identifier (TID) value—one is assigned after it successfully connects—so a null TID (0xFFFF) is placed in its header field. Other fields may be padded with zeros when not used.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

In the previous three chapters, we showed you how to install Samba on a Unix server and set up Windows clients to use a simple disk share. This chapter will show you how Samba can assume more productive roles on your network.

Samba's daemons, smbd and nmbd , are controlled through a single ASCII file, smb.conf, that can contain over 200 unique options. These options define how Samba reacts to the network around it, including everything from simple permissions to encrypted connections and NT domains. The next five chapters are designed to help you get familiar with this file and its options. Some of these options you will use and change frequently; others you may never use—it all depends on how much functionality you want Samba to offer its clients.

This chapter introduces the structure of the Samba configuration file and shows you how to use these options to create and modify disk shares. Subsequent chapters will discuss browsing, how to configure users, security, domains, and printers, and a host of other myriad topics that you can implement with Samba on your network.

Here is an example of a Samba configuration file. If you have worked with a Windows .INI file, the structure of the smb.conf file should look very familiar:

[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
[test]
	browseable = yes
	read only = yes
	guest ok = yes
	path = /export/samba/test

Although you may not understand the contents yet, this is a good configuration file to grab if you're in a hurry. (If you're not, we'll create a new one from scratch shortly.) In a nutshell, this configuration file sets up basic debug logging in a default log file not to exceed 1MB, optimizes TCP/IP socket connections between the Samba server and any SMB clients, and allows Samba to create a disk share for each user that has a standard Unix account on the server. In addition, each of the printers registered on the server will be publicly available, as will a single read-only share that maps to the

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

Here is an example of a Samba configuration file. If you have worked with a Windows .INI file, the structure of the smb.conf file should look very familiar:

[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
[test]
	browseable = yes
	read only = yes
	guest ok = yes
	path = /export/samba/test

Although you may not understand the contents yet, this is a good configuration file to grab if you're in a hurry. (If you're not, we'll create a new one from scratch shortly.) In a nutshell, this configuration file sets up basic debug logging in a default log file not to exceed 1MB, optimizes TCP/IP socket connections between the Samba server and any SMB clients, and allows Samba to create a disk share for each user that has a standard Unix account on the server. In addition, each of the printers registered on the server will be publicly available, as will a single read-only share that maps to the /export/samba/test directory. The last part of this file is similar to the disk share you used to test Samba in Chapter 2.

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:

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

Now that we've gotten our feet wet with variables, there are a few special sections of the Samba configuration file that we should talk about. Again, don't worry if you do not understand each and every configuration options listed below; we'll go over each of them over the course of the upcoming 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.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

Samba has well over 200 configuration options at its disposal. So let's start off easy by introducing some of the options you can use to modify the configuration file itself.

As we hinted earlier in the chapter, configuration files are by no means static. You can instruct Samba to include or even replace configuration options as it is processing them. The options to do this are summarized in Table 4.2.

Table 4.2: Configuration File Options
Option	Parameters	Function	Default	Scope
`config file`	string (fully-qualified name)	Sets the location of a configuration file to use instead of the current one.	None	Global
`include`	string (fully-qualified name)	Specifies an additional segment of configuration options to be included at this point in the configuration file.	None	Global
`copy`	string (name of share)	Allows you to clone the configuration options of another share in the current share.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

Now it's time to begin configuring your Samba server. Let's introduce three basic configuration options that can appear in the [global] section of your smb.conf file:

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

This configuration file is pretty simple; it advertises the Samba server on a NBT network under the NetBIOS name hydra. In addition, the machine belongs to the workgroup SIMPLE and displays a description to clients that includes the Samba version number as well as the NetBIOS name of the Samba server.

If you had to enter encrypt passwords=yes in your earlier configuration file, you should do so here as well.

Go ahead and try this configuration file. Create a file named smb.conf under the /usr/local/samba/lib directory with the text listed above. Then reset the Samba server and use a Windows client to verify the results. Be sure that your Windows clients are in the SIMPLE workgroup as well. After clicking on the Network Neighborhood on a Windows client, you should see a window similar to Figure 4.2. (In this figure, phoenix and chimaera are our Windows clients.)

Figure 4.2: Network Neighborhood showing the Samba server

You can verify the server string by listing the details of the Network Neighborhood window (select the Details menu item under the View menu), at which point you should see a window similar to Figure 4.3.

Figure 4.3: Network Neighborhood details listing

If you were to click on the Hydra icon, a window should appear that shows the services that it provides. In this case, the window would be completely empty because there are no shares on the server yet.

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

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

We mentioned in the previous section that there were no disk shares on the hydra server. Let's continue with the configuration file and create an empty disk share called [data]. Here are the additions that will do it:

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

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

The [data] share is typical for a Samba disk share. The share maps to a directory on the Samba server: /export/samba/data. We've also provided a comment that describes the share as a Data Drive, as well as a volume name for the share itself.

The share is set to writeable so that users can write data to it; the default with Samba is to create a read-only share. As a result, this option needs to be explicitly set for each disk share you wish to make writeable.

You may have noticed that we set the guest ok parameter to yes. While this isn't very security-conscious, there are some password issues that we need to understand before setting up individual users and authentication. For the moment, this will sidestep those issues and let anyone connect to the share.

Go ahead and make these additions to your configuration file. In addition, create the /export/samba/data directory as root on your Samba machine with the following commands:

# mkdir /export/samba/data
# chmod 777 /export/samba/data

Now, if you connect to the hydra server again (you can do this by clicking on its icon in the Windows Network Neighborhood), you should see a single share listed entitled data, as shown in Figure 4.4. This share should also have read/write access to it. Try creating or copying a file into the share. Or, if you're really feeling adventurous, you can even try mapping a network drive to it!

Figure 4.4: The initial data share on the Samba server

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

If you're running Samba on a multi-homed machine (that is, one on multiple subnets), or even if you want to implement a security policy on your own subnet, you should take a close look at the networking configuration options:

For the purposes of this exercise, let's assume that our Samba server is connected to a network with more than one subnet. Specifically, the machine can access both the 192.168.220.* and 134.213.233.* subnets. Here are our additions to the ongoing configuration file for the networking configuration options:

Table of Contents

Section 1.4.1.1: Domain controllers

Section 2.5.2.1: BSD Unix

Section 2.5.2.2: System V Unix

Section 3.2.1.1: Name the machine

Section 3.3.1.1: SMB header format