Uh-oh, it looks like your Internet Explorer is out of date.

For a better shopping experience, please upgrade now.

Sams Teach Yourself Samba in 24 Hours

Sams Teach Yourself Samba in 24 Hours

by Gerald Carter, Jeremy Allison (Foreword by), John Traenkenschuh (Editor)

See All Formats & Editions

Sams Teach Yourself Samba in 24 Hours is a tutorial designed to help you integrate Linux/UNIX-based systems with Windows-based systems. It has all the information and tools necessary for you to be up and running with Samba in 24 short lessons. Learn how to use Samba to its fullest potential. Topics range from introducing Samba and Samba installation


Sams Teach Yourself Samba in 24 Hours is a tutorial designed to help you integrate Linux/UNIX-based systems with Windows-based systems. It has all the information and tools necessary for you to be up and running with Samba in 24 short lessons. Learn how to use Samba to its fullest potential. Topics range from introducing Samba and Samba installation to configuration and problem solving. This book provides complete, step-by step instruction. A tear card featuring Samba's options and share examples is included.

  • Learn to share your files with Windows systems without laborious steps traditionally used in integrating systems
  • Offers a step-by-step, easy-to-follow guide to using Samba, teaching the fundamentals and then showing how to apply that knowledge to solve your problems
  • CD-ROM contains Samba 2.0, as well as many other tools of interest

Product Details

Pearson Education
Publication date:
Sams Teach Yourself Series
Product dimensions:
7.46(w) x 9.16(h) x 1.04(d)

Read an Excerpt

Chapter 3: Obtaining the Latest Source

Every once and a while I see a message posted to one of the Samba mailing lists or a newsgroup saying something such as, "I'm running Samba version 1.0 and I can't get ____ to work." Invariably the answer comes back, "Upgrade to the latest version and if it still doesn't work, post your question again." Now I might be exaggerating about the version (for reference sake, the latest distributed version is 2.0 at the time I'm writing this), but it is important to realize the rate at which code develops and changes, especially in an open source software project such as Samba. The problem the person was experiencing might have been due to a known bug that was already fixed.

Maybe you are installing Samba for the first time, or maybe the person who maintained the Samba server left to make five times as much money. For whatever reason, sooner or later you need to obtain a copy of the latest source code and compile it yourself. In fact, you might find that it's something you look forward to.

This hour provides the information necessary to download the latest source and set any specific compile-time options. You'll also take a look at the binary distributions that are available (in case you don't feel like compiling things on your own).

Finding Out What Version of Samba You Currently Have

If you already have Samba running and want to determine whether you have the latest version, read on! If you are installing Samba for the first time, feel free to save this section for later use.

There are two simple ways to determine the version of Samba that is installed on your system. The first method uses the log files that the smbd and nmbd daemons create and leave behind, whereas the second involves obtaining information from the processes themselves.

First, look at the log files. A Samba server comprises two daemon processes: smbd and nmbd, which create logs that are located in /usr/local/samba/var by default and are usually named log.smb and log.nmb, respectively. It is possible to override where Samba places these by specifying a value in the configuration file. If you find that the log files are not located in /usr/local/samba/var, the next step is to find the configuration file, which is normally named smb.conf.

Normally the configuration file is located in /usr/local/samba/lib. As with most other values and locations in Samba, it is possible to override the location and name of smb.conf by passing a command-line argument to smbd and nmbd using the -s switch. Samba can be started either from the inetd metadaemon or as a daemon itself. To determine the methods that your systems uses, first look in /etc/inetd.conf by

grep smbd /etc/inetd.conf

If your system uses System V init scripts, such as Solaris 2.x or RedHat Linux, you can go to the startup script directory which is normally similar /etc/init.d or /etc/rc.d and run the command

grep smbd *

If you notice that a filename follows an -l switch when starting smbd, this is your debug log file. Otherwise, run the following command:

grep "log file" smb.conf

The resulting output should give an absolute path to a file. Look in this directory for the Samba logs.

After you find the correct log files, you should be able to determine the version of the Samba daemon that created them by searching the file:

root# grep "smbd version" log.smb | tail -1 smbd version
   2.1.0-prealpha started.

If you do not see something similar to the output listed previously, most likely what happened was that the logs either were written over by a cron job on the system or were rotated out by Samba itself because of their size. In order to get Samba to reprint the information, you can remove the logs and restart the smbd and nmbd processes.

It's impossible to describe how to restart Samba on every system on which it runs. This example from a Slackware 3.5 Linux system should give you a general idea:

[root@bilbo /etc] killall smbd
[root@bilbo /etc] killall nmbd

[root@bilbo /etc] /etc/rc.d/rc.samba

If you forget to remove the logs, Samba simply appends the new entries to the existing logs.

CAUTION: In Samba versions prior to 2.0, the default behavior for nmbd is to overwrite the old log.nmb file whereas smbd appends log entries. In version 2.0, both smbd and nmbd append log entries by default.

Another possible way to determine the version of Samba that is currently running is by using the smbclient utility that comes with the Samba distribution. Although this method is a lot simpler, it does require that smbclient be installed and that Samba is currently running. Locate the smbclient binary (usually in /usr/local/samba/bin) and run the following command:

smbclient -L localhost

As a result you should see something similar to the following (possibly mixed in with other text):

Added interface ip=aaa.bbb.ccc.ddd bcast=aaa.bbb.ccc.255 

Domain=[CHIPSNDIPS] OS=[Unix] Server=[Samba 2.1.0-prealpha]

Sharename      Type      Comment

---------      ----      -------


The version information on the machine to which you are connected (the local machine) is printed in the brackets ([ ]) following the Server= label. This version in the previous example is "2.1.0-prealpha" (test code).

Download Sites and Methods

Now that you've determined that you need to get that latest Samba distribution, where do you go? The first place to start is to point your Web browser to http://samba.org (see Figure 3.1). This page contains links to all the Samba mirror Web sites and the FTP mirrors as well.

FIGURE 3.1 List of mirrors for http://samba.org .

If you are using HTTP to download the Samba distribution, first select the mirror closest to you. When you arrive at the mirror site home page, select the download link. The resulting page, which is shown in Figure 3.2, should have a link to download a file named samba-latest.tar.gz.

If you prefer to browse and see what is available, you can obtain a directory listing of files that can be downloaded (see Figure 3.3). Again you should see a file named samba-latest.tar.gz. If not, simply look for the samba-#####.tar.gz with the highest version number. The process of finding the latest distribution archive via FTP is similar to browsing the directory listing through HTTP.

FIGURE 3.2 Samba download page.

FIGURE 3.3 Folder listing of download archives from the Samba Web site.

After you have downloaded the distribution, change to a good temporary directory where you won't overwrite anything when you extract the source files. I use a directory named ~/src as a working directory for compiling source code. If I want to save anything after I'm finished, I move the files to a more permanent location. To extract the files, you need a working version of GNU gzip and tar. If the file you download is named, for example, samba-latest.tar.gz, the following command will extract the files for you:

gzip -dc samba-latest.tar.gz | tar xvf -

Although the directory tree might change from time to time, three directories are common to all versions thus far:

  • docs/  This directory contains various documentation such as man pages, HTML-formatted files, and ASCII HOWTO files.

  • examples/  This directory contains various examples for many operating systems describing different setup possibilities. Mostly contains sample smb.conf files.
  • source/  This directory contains the Samba source code tree for the distribution.

Compiling Samba

After you have the source code distribution of Samba, the next actions for compiling depend on what version of Samba you are installing. Things are done very differently in versions prior to 2.0 as compared to 2.0 and above. The reason is that 2.0 was reworked to use the GNU autoconf tests.


For some reason, you might not be able to upgrade to the latest version. Perhaps you have to support an inherited system and need to change one of the compile-time defaults. As I said before, the compiling versions prior to 2.0 are very different than the current method. To give you a frame of reference, the last version released prior to 2.0 was 1.9.18p10.

In the pre-2.0 code tree, all the source files are located in one directory with a make file that you have to slightly modify before compiling:

# The base directory for all samba files
BASEDIR = /usr/local/samba

One of the most common options to change is the base directory for the Samba binary tree after it's installed. The contents of this directory are discussed later in this hour. For now, think of it as the default location where Samba looks for and writes information. Most of these locations can be overridden using smb.conf options or command-line parameters. I prefer to explicitly tell Samba where things are at run time and not make assumptions, but that is my personal preference:

# The directories to put things in. If you use multiple
# architectures or share the samba binaries across NFS 

# you will probably want to change this layout.

# Note: The SBINDIR is for files you do not want users to access

#       normally applies only to nmbd and smbd

#       SBINDIR implies a secure binary directory





If you want to distribute the individual Samba directories outside of one tree, you can change the values of ${BINDIR}, ${SBINDIR}$, ${LIBDIR}, and {VARDIR}.

You can also override the default locations of individual files by changing any of the following make file variables. If you are unsure of exactly what the various files are, you can safely leave the defaults.

# set these to where to find various files
# These can be overridden by command line switches (see smbd(8))

# or in smb.conf (see smb.conf(5))



Before continuing, I want to point out the convention of defining the section of the man pages where an entry occurs by adding (number). In the make file excerpt listed here, the smbd(8) reference means that the smbd man page is located in section 8. Assuming the default install directories, the smbd man page is physically located in /usr/local/samba/mab/man8.

The log files are where the smbd and nmbd daemons write their logging information:


The smb.conf file has been mentioned already. The lmhosts file is the NetBIOS equivalent of an /etc/hosts file:

DRIVERFILE = $(LIBDIR)/printers.def

The printer.def file contains information about printer drivers which can be downloaded and installed by Windows 95 and 98 clients on-the-fly when connecting to the printers:

SMB_PASSWD = $(BINDIR)/smbpasswd
SMB_PASSWD_FILE = $(BASEDIR)/private/smbpasswd

These files are the Samba passwd utility and the passwd file respectively. They are discussed more in Hour 6, "Security Levels and Passwords."

# the directory where lock files go

The lock directory is where Samba places things such as its current browse list (see Hours 19, "Local Subnet Browsing," and 20, "Routed Networks and Browsing"), file lock information, and WINS database (see Hour 18, "Resolving NetBIOS Names Without Using Broadcasts").

One of the major advantages of the autoconf support is that it insulates you from having to specify many details about your operating system. In a pre-2.0 make file, you need to uncomment the flags in the section of the make file which refers to your OS. For example, the following section is for Linux installations that use shadow password but not PAM. The FLAGSM and LIBSM variables were previously commented out by a preceding # as are all the OS-specific sections:

# Use this for Linux with shadow passwords but not using PAM!
# contributed by Andrew.Tridgell@anu.edu.au

# add -DLINUX_BIGCRYPT is you have shadow passwords but don't have

# the right libraries and includes


LIBSM = -lshadow

One last flag that is often useful to set is the CC variable. The default value for CC is to use the cc compiler. If you want to use the gcc compiler instead, you must uncomment the line that says CC = gcc.

Besides setting the make file variables, you might need to set some site-specific values in the local.h header, which is located in the source/ directory. The file itself and the macros are fairly self explanatory. Unless you are sure you need to change something in this file, it is generally better to leave it alone.

However, one macro that I have regularly had to change was MAX_OPEN_FILES. The default value for this in pre-2.0 releases is 100. Due to some code writes, the new Samba code has been made immensely more efficient with respect to file handles. The default in the 2.0 release is 10,000.

One office I had to support used a shared database and the front end needed to open about 150 files simultaneously. Increasing the maximum to around 200 fixed my problem. Obviously this problem does not plague me with 2.0! Also a note of difference is that, in the 2.0 source code, this setting can also be set using a run time parameter in the smb.conf file.

After you have made the necessary changes to the make file and local.h (if any), you can create the binaries by typing make. If all goes well, the smbd, nmbd, and other utilities should be located in the same directory as the source files.

2.0's autoconf Support

In contrast to pre-2.0 makes, Samba 2.0 is very simple. There is a configure script located in the source/ directory. To enable support for your operating system, simply change to the source directory and run the following command:


The script runs and creates the appropriate make file for you.

Although it is possible to edit the created make file manually and set variables, it is easier to simply specify some of the options as command-line parameters. To find out information about what options are available, type ./configure --help.

I've included portions of the output in Listing 3.1. Where I've deleted lines for brevity, the change is noted by braces ({}).

LISTING 3.1  Sample Output from ./configure --help

01: Usage: configure [options] [host]
02: Options: [defaults in brackets after descriptions]

03: Configuration:

04: {lines deletd}

05: Directory and file names:

06:   --prefix=PREFIX         install architecture-independent files in
07:                           [/usr/local/samba]

08:   --exec-prefix=EPREFIX   install architecture-dependent files in
09:                           [same as prefix]

10: {lines deletd}

11: Host type:{lines

12:  deletd}

13: Features and packages:

14: {lines deletd}

15: --enable and --with options recognized:

16:   --enable-maintainer-mode enable some make rules for maintainers

17:   --with-smbwrapper     Include SMB wrapper support

18:   --without-smbwrapper  Don't include SMB wrapper support
19:   --with-afs     Include AFS support

20:   --without-afs  Don't include AFS support (default)

21:   --with-dfs     Include DFS support

22:   --without-dfs  Don't include DFS support (default)

23:   --with-krb4=base-dir     Include Kerberos IV support

24:   --whithout-krb4          Don't include Kerbers IV support
25:   --with-automount     Include AUTOMOUNT support

26:   --without-automount  Don't include AUTOMOUNT support (default)

27:   --with-smbmount     Include SMBMOUNT (Linux only) support

28:   --without-smbmount  Don't include SMBMOUNT support (default)

29:   --with-ldap     Include LDAP support

30:   --without-ldap  Don't include LDAP support (default)

31:   --with-nisplus     Include NISPLUS password database support

32:   --without-nisplus  Don't include NISPLUS password database support
33:   --with-nisplus-home     Include NISPLUS_HOME support

34:   --without-nisplus-home  Don't include NISPLUS_HOME support
35:   --with-ssl     Include SSL support

36:   --without-ssl  Don't include SSL support (default)

37:   --with-mmap     Include experimental MMAP support

38:   --without-mmap  Don't include MMAP support (default)

39:   --with-syslog     Include experimental SYSLOG support

40:   --without-syslog  Don't include SYSLOG support (default)

41:   --with-netatalk     Include experimental Netatalk support

42:   --without-netatalk  Don't include experimental Netatalk support
43:   --with-quotas     Include experimental disk-quota support

44:   --without-quotas  Don't include experimental disk-quota support
45:   --with-privatedir=DIR     Where to put smbpasswd
46:   --with-swatdir=DIR     Where to put SWAT files

The list of options is quite long, but in reality, many of them come in pairs: one to enable the option and one to disable it. For example, look at the options in lines 25 and 26. The first enables automount support and the second disables it. You should also notice that Listing 3.1 indicates which options are enabled and disabled by default.

If you want to override the default location of the top-level install directory (/usr/local/samba by default) and use /usr/samba instead, pass


as a parameter when you execute the configure command. To create the make file accepting all the default options (which is usually fine), simply run


The configure script creates a make file in the source/ directory. All that remains in order to build the Samba binaries is to type make.

What Goes Where When I Type Make Install?

Whatever version of Samba you compile, when the binaries are ready, you can install the files to the directory specified by the prefix (or BASEDIR) variable in the make file by typing make install. I assume here, and for the rest of this book, that Samba has been installed to the default location of /usr/local/samba/.

This creates the Samba directory tree, if necessary, and copies over the binaries and other relevant files. When completed, the following directories should exist in the Samba install directory unless you have overridden the locations in the make file:

  • bin/  This directory contains the smbd and nmbd binaries and any other utilities included with Samba.
  • lib/  This directory contains the smb.conf and lmhosts files and the codepage support files in a codepages/ subdirectory.
  • var/  This directory is empty until Samba is first run. At that time, the smbd and nmbd daemons create the lock files, shared memory files, browse list information file, and possibly the WINS databases. Under Samba 2.0, smbd.pid and nmbd.pid files are also contained along with the process ID of the currently running daemons. These are useful for easy restarting. This is also the default location for the Samba log files.
  • man/  The Samba man pages are located in various subdirectories here. If you want the pages located in your man page search path, you can either move the files to an existing man page location or add them to your MANPATH environment variable. For example, if the Samba man pages are located in /usr/local/samba/man, under the Bourne shell or bash, you can append this directory to the existing search path by setting

  • swat/  This directory contains the files for the GUI smb.conf editor SWAT, which is discussed more in Hour 9, "GUI Administration Tools."

Binary Distribution Methods

If, for some reason, you choose not to compile the source code for yourself or are unable to on your system (say for a lack of a C compiler), now is good time to talk about availability of downloading only the binaries. In Hour 1, "Introduction to Samba," I discussed the basics of the GPL. One stipulation of the license is that the source code doesn't have to be distributed with the binaries, but it must be available on request.

The first job I ever worked as a network administrator was while working on my master's degree. I was flying by the seat of my pants and learning as I went. I had been given the responsibility of building a student-accessible PC lab. One of the things I purchased for the lab was a Sparc Ultra running Solaris 2.5.1. Imagine my surprise when I was getting ready to install software and realized that Sun didn't ship a C compiler with Solaris 2!

That said, binary distributions can be very helpful depending on what your needs are. If you do not plan to modify the compile-time defaults or don't have a particularly unique site, downloading the binaries probably saves you some time. Remember that the source is always available if you decide at a later time you need it.

TIP: There is a mailing list specifically set up for posting notices about the Samba binary packages. The address is samba-binaries@samba.org. See http://samba.org/listproc for more information about Samba mailing lists.

Obtaining a Samba binary release is very similar to obtaining a source code release. The first place to look is the Samba home page (http://samba.org); select the FTP or HTTP site closest to you. If you use HTTP to download the files, again follow the download link off the Samba mirror home page and look for information on downloading binary packages. If you use FTP, look for a directory named bin-pkgs or Binary_Packages and then select your operating system.

Binary packages are not available for all platforms that Samba compiles on, nor are they always available for the latest source code release. The reason is the packages are compiled and uploaded on a volunteer basis. If possible, the binaries and associated files, such as an sample smb.conf files, are archived using the tools for the native OS. For example, RedHat binaries are stored using RPM and Solaris binaries and distributed using in the pkgtool format. Discussing the details of using the package distribution tools for various operating systems is beyond the scope of this book. If you need more information on the binary distribution tool for your operating system (for example, Solaris 2.x uses pkgadd and RedHat Linux systems use rpm), please read the man pages for the installation tool most appropriate to your system.

Now that you have the current version of Samba that you want to use and the binaries are ready to go, Hour 4, "Installing and Testing the Configuration," helps you get a sample installation up and running.


When installing Samba, you have two options. You can either download the source code and compile it yourself, or you can obtain a binary-only release if it is available for your platform.

Preparing to compile Samba 2.0 involves executing the configure script located in the source or directory of the distribution and specifying any options that you need. Versions of Samba prior to 2.0 require manually editing the make file and enabling the appropriate support for your OS. When the correct options have been set, both 2.0 and pre-2.0 distributions can be compiled by executing the make command. When the binaries have been created, they are installed to your local system by issuing make install.


Q: I downloaded Samba 2.0. I extracted the files and typed make but the system is complaining make: Fatal error: No arguments to build.

A: You must run configure prior to executing make....

Meet the Author

Gerald Carter is a network manager at Auburn University. He has been managing Samba servers since 1995 and is an active member of the Samba Team, a group of people who develop, test, and document Samba. He is an active Usenix member, particularly involved in the LISA-NT conference, and also writes a monthly column on integrating Linux and Windows NT for the Web-based magazine, LinuxWorld.

Richard Sharpe is also a member of the Samba Team. Richard is a senior consultant at NS Computer Software and Services, a consulting firm in South Australia. He teaches TCP/IP and network security courses and has written several papers and articles on Samba-related topics.

Customer Reviews

Average Review:

Post to your social network


Most Helpful Customer Reviews

See all customer reviews