Compiling from Source

Compiling from Source

A typical Samba installation takes about an hour to complete, including downloading the source files and compiling them, setting up the configuration files, and testing the server. Conventionally installing from source is called the ./configure && make && make install process. Here is a complete list of the individual steps:

  1. Download the source or binary files.

  2. Read the installation documentation.

  3. Run the autoconf script that generates the Makefile appropriate for your system.

  4. Compile the server and utility programs.

  5. Install the server files.

  6. Create a Samba configuration file.

  7. Test the configuration file.

  8. Start the Samba daemons.

  9. Test the Samba daemons.

Downloading the Source Distribution

If you would like to download the latest version of the Samba software, the primary web site is Once you connect to this page, you should see a drop-down list of world-wide mirrors. Choose a site that is closest to your own geographic location. The link to the download area is located on the lefthand tool bar that appears on every page on the Samba web site.

The Samba site includes online documentation, links to mailing list archives, and the latest Samba news,[*] as well as source and binary distributions of Samba. 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, which for the 3.0.22 release is a 16 MB file.

[*] A recent addition to the Samba web site is a news portal ( This site is a collection of all things Samba, from release announcements to advocacy stories and new developer announcements.

It is also a good idea to verify the digital signature on the uncompressed tarball to ensure that the version you are downloading is one actually released by the Samba Team. To do this you will need either GnuPG ( or some other pgp-compatible utility installed on a system. You can verify the tarball's signature on any machine. It does not have to be done on the server used for compiling Samba.

First, download the current Samba public GPG key. Look for a file named samba-pubkey.asc residing in the same directory as the Samba source release tarball. This key should be imported into your pgp keyring by executing:

$ gpg --import samba-pubkey.asc
gpg: key F17F9772: public key "Samba Distribution Verification Key
<[email protected]>" imported
gpg: Total number processed: 1
gpg:               imported: 1

The key ID (F17F9772) will change from year to year as the old key expires and a new one is issued by the Samba developers. The latest key will always be available at

Now you can verify the integrity of the source tarball by uncompressing it and asking gpg to verify the signature file (samba-latest.tar.asc).

$ gunzip samba-latest.tar.gz
$ gpg --verify samba-latest.tar.asc
gpg: Signature made Thu 14 Apr 2005 01:23:58 AM CDT using DSA key ID F17F9772
gpg: Good signature from "Samba Distribution Verification Key <[email protected]>"

Now you are ready to extract the files from the tar archive. While the following tar command runs, it prints out a list of the files it installs:

$ tar xvf samba-latest.tar

The archive creates a single directory named samba-VERSION (where VERSION is the current release number, such as 3.0.22). This directory contains all of the source files, documentation, packaging files, and examples included in the distribution.

Read the Documentation

In the top-level directory that you just created, a file named WHATSNEW.txt contains the latest news about the release. If you are upgrading, you can find important information in this file about bug fixes or configuration parameters that have been added or are no longer supported.

With both source and binary packages, you'll find a large number of documents in the docs directory, in a variety of formats. Samba documentation has improved substancially over the years. There are currently three full-length books, one of which is the one you are currently reading, included in this directory. You'll have plenty of time to browse this collection while Samba is compiling.

Configuring Samba

The source distribution of Samba 3.0 doesn't initially have a makefile. Instead, one is generated through a GNU Autoconf script, which is located in the samba-3.0.x/source/ directory. The configure script takes care of the machine-specific issues of building Samba, such as which libraries are needed, what's the maximum value that can be stored in a integer, and how to automatically determine the available network interfaces on a system. The configure script also allows you to enable or disable specific features in Samba (more on this task shortly).

When configure runs, it prints messages telling what it is doing, and error messages might be mixed in. To make sure that you see those very important error messages, it is helpful to run configure with its standard output passed through some filter to capture the output and keep it from scrolling out of sight. For example:

$ ./configure | more

Although executing configure with no options generates a working set of binaries, you might want to add support for extra features by passing options on the command line. Each option enables or disables various features. You typically enable a feature by specifying the --with-feature option, which causes the feature to be compiled and installed. Likewise, if you specify a --without-feature option, the feature will be disabled. Note that options to the configure script start with two hyphens.

The following command instructs configure to test for Pluggable Authentication Module (PAM) support on the build host:

$ ./conFigurewith-pam

We'll discuss Samba PAM integration when we examine users and passwords in Chapter 5.

If you would like a complete list of options, type the following:

$ ./conFigurehelp

The full list of configuration options is reproduced in Appendix C. Here is a brief list of some of the most popular features, which are covered later in this book:


Include support for integrating with filesystem POSIX ACLs. Samba acts as a thin layer of glue for many features by mapping what a Windows client requests to what a Unix/Linux server can provide. Samba does not implement filesystem ACLs internally, but instead provides an interface to the ACL implementation provided by the host's filesystem. ACLs will be discussed in more detail in Chapter 6.


Include support for integration with Active Directory services using the Kerberos 5 and LDAP protocols. This is one of the major advances in Samba 3.0, but it also introduces dependencies on third-party software components. Compiling Samba to include ADS support is covered in more detail later in this chapter, while the steps for configuring Samba as a domain member server will be presented in Chapter 10.


Require that Samba enable its support for the CUPS. If the necessary CUPS development files are not found, the configure script will fail. See Chapter 7 for more information on integrating Samba and CUPS.


Integrate Samba's debug logs with the system logs via the syslogd service. Logging and syslog are covered in Chapter 4.


Include the userspace tools for managing the smbfs filesystem on Linux clients. Be aware that smbfs is different from the newer CIFS filesystem included in the Linux 2.6 kernel. Both Linux filesystem modules are discussed in Chapter 11.


Instruct the compiler to enable debug symbols in the resulting binaries for use by a symbolic debugger such as gdb. Troubleshooting and debugging Samba are covered in Chapter 12.

Each option is set to a default that is appropriate for most systems, and none of the features are essential to basic Samba installations. However, you may want to include them in your configuration (as we will in our example) at least to be able to try out the options in later chapters.

In addition, Figure shows some other parameters that you can give the configure script if you wish to store parts of the Samba distribution in different places, perhaps to make use of multiple disks or partitions. Note that the defaults sometimes refer to a prefix specified earlier in the table. In other words, if you set the --prefix option to /opt/samba, the default bindir becomes /opt/samb/bin.

Additional configure options





Install architecture-independent files at the base directory specified.



Install user executables in the directory specified.


--sbindir= directory

Install administrator executables in the directory specified.


--datadir= directory

Install read-only architecture-independent data in the directory specified.


--libdir= directory

Install program libraries in the directory specified.



Runtime state information.


--mandir= directory

Install manual pages in the directory specified.



Directory to use for Samba's private files, such as smbpasswd and secrets.tdb



Directory that Samba daemons will use for storing the main parent pid files.



Directory that Samba daemons will use for locating configuration files.



Directory that Samba will use for storing database and runtime state files.



Directory that Samba daemons will use for storing logfiles.



Use a directory structure below ${prefix} that adheres to the Linux Filesystem Hierarchy Standard.


Here is one example of a possible directory layout when building Samba from scratch:

$ ./conFigureprefix=/opt/samba \
        --localstatedir=/var/lib/samba \
        --with-piddir=/var/run \
        --with-logfilebase=/var/log/samba \
        --with-privatedir=/etc/samba/private \
        --with-configdir=/etc/samba \

This layout results in the following set of directories after installing the binaries and files created from the compilation process:


The base installation directory for Samba client and server binaries, manpages and other documentation, libraries and header files


Samba configuration files


User accounts and other security-sensitive data


Logfiles created by Samba daemons


Samba's repository of Trivial Database (tdb) files used to maintain configuration and state information, such as open file locks held by clients and printer attributes


Pid files created by smbd, nmbd, and winbindd

This type of installation makes it easy to share a build via NFS while storing the local configuration information on a local filesystem. Feel free to add on any additional feature flags (e.g., --with-acl-support) that you think would be useful.

Samba tdb files must always reside on a filesystem that provides locking and a coherent mmap( ) implementation. For most systems, this rule implies that you must use a local native filesystem.

Here is a sample execution of the configure script, which creates a Samba 3.0.22 makefile for the Linux platform:

$ cd samba-3.0.22/source/
$ ./conFigureprefix=/usr/samba --with-smbmount \
    --with-syslog 2>&1 | more
checking for gcc... gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
...(content omitted)...
Using libraries:
    LIBS = -lcrypt -lresolv -lnsl -ldl
    KRB5_LIBS = -lgssapi_krb5 -lkrb5 -lk5crypto -lcom_err
    LDAP_LIBS = -lldap -llber
    AUTH_LIBS = -lcrypt

In general, any message from configure that doesn't begin with the words checking or creating is an error. If there was an error during configuration, more detailed information about it can be found in the config.log file, which is written to the local directory by the configure script. If the configuration works, you'll see a checking configure summary message in the output on the screen followed by a yes message and four or five file-creation messages:

checking configure summary... yes
configure: creating ./config.status
config.status: creating include/stamp-h
config.status: creating Makefile
config.status: creating script/findsmb
config.status: creating smbadduser
config.status: creating script/
config.status: creating include/config.h

So far, so good.

Kerberos and LDAP

In order to integrate with Active Directory using the Kerberos and LDAP protocols, Samba relies upon third-party libraries such as those provided by MIT, Heimdal, and OpenLDAP. However, the introduction of these build dependencies can complicate the previous simple ./configure && make && make install steps.

Microsoft introduced a new Kerberos encryption type when initially creating Active Directory. The reason for this new algorithm (RC4-HMAC-MD5) was to enable smooth upgrades from Windows NT 4.0 domains by using existing account passwords as the basis for generating the new long-term secrets keys in the AD Kerberos realm. However, earlier versions of both the MIT and Heimdal Kerberos libraries did not support this new encryption type (type 23) and were forced to rely on DES keys.

Things have since improved, and both the major open source Kerberos players have RC4-HMAC (sometimes called ARCFOUR-HMAC) support now. Samba's configure script will attempt to locate a working set of Kerberos client libraries. Be aware that just because Kerberos is included with the operating system (e.g., Solaris) does not necessarily mean it is a usable installation. The script will ignore any unusable Kerberos libraries. Thus, unless you are paying attention, it is quite possible to end up with a set of binaries that don't allow you to run the Samba's newer ADS security mode.

To decide whether you have to install a Kerberos client distribution, consider the following to be the bare minimum for interoperating with Active Directory:

It is possible to use releases older than these, but things get slightly more complicated when it comes time to configure Samba (as you will see in Chapter 10). A good source of information (compilation, installation, and management) covering both Kerberos distributions as well as Active Directory is Kerberos: The Definitive Guide, by Jason Garman (O'Reilly).

Once the Kerberos piece is set, we have to deal with the LDAP dependency as well. Currently, Samba supports only the OpenLDAP distribution for AD integration. Any OpenLDAP 2.x release should work, but experience has shown that the latest stable release is generally best. Note that Samba requires only the client libraries, so there is no need to compile or install the OpenLDAP server or server related tools. More information on OpenLDAP can be found at or in LDAP System Administration, by Gerald Carter (O'Reilly).

One final note is that when using third-party libraries such as the Kerberos or LDAP ones mentioned here, you should also ensure that once installed, the libraries can be located by dependent applications such as Samba. There are two primary means of achieving this.

One method is to add the directory (e.g., /opt/openldap/lib) to the global library search path. On some platforms, this can be done at run time by appending the new directory to the LD_LIBRARY_PATH search list.

# export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/opt/openldap/lib

Other, more permanent solutions, differ from platform to platform. For example, Linux's /etc/ file and Solaris' crle tool have already been mentioned.

The other solution is to encode the library search path in the binary itself during the compilation process, usually done by instructing the compiler to pass additional flags onto the linker. The following script shows how this would be done if Heimdal Kerberos were installed in /opt/heimdal and OpenLDAP were installed in /opt/openldap:



DIRPATH="/opt/heimdal /opt/openldap"
for dir in $DIRPATH ; do
        CPPFLAGS="$CPPFLAGS -I$dir/include"
        CFLAGS="$CFLAGS -Wl,-rpath,$dir/lib"
        LDFLAGS="$LDFLAGS -L$dir/lib"


The resulting $CPPFLAGS variable (used by the C preprocessor) would be:

-I/opt/heimdal/include -I/opt/openldap/include

The $CFLAGS variable (used by the compiler) would appear as:

-Wl,-rpath,/opt/heimdal/lib -Wl,-rpath,/opt/openldap/lib

and the linker flags ($LDFLAGS) would be:

-L/opt/heimdal/lib -L/opt/openldap/lib

Other compilers and linkers besides gcc (e.g., the Sun C compiler), may use the -Rdir flag for encoding library search paths rather than -Wl,-rpath,dir. Check the compiler documention to be sure.

Once these variables are set, we can run configure followed by make and we should end up with an AD-enabled version of Samba. If you want to verify that the resulting smbd binary does in fact include AD support, use the -b flag again and this time grep for WITH_ADS :

$ smbd -b | grep ADS

Unicode and the iconv Library

Internally, Samba uses Unicode when communicating with Unicode-aware clients such as Windows NT and later clients. There are times when these Unicode strings must be converted to a locale encoding (a non-Unicode collection of language, country, and cultural information), such as when writing a filename to disk or displaying a username. When possible, Samba utilizes the GNU iconv library, available from, to handle these translations.

Some Unix variants, such as FreeBSD and Linux, come with a suitable iconv library installed. But some variantsSolaris being the most notabledo not have sufficient support in the included iconv implementation for Samba's purposes. There are two codepages that can be handled independently of iconv: the European CP850 and CP437 character sets. Therefore, these character sets work on systems that lack the necessary iconv.

However, if your server will be supporting characters outside the standard English ASCII character set, it is best to verify that your server has a working iconv installation.

 Python   SQL   Java   php   Perl 
 game development   web development   internet   *nix   graphics   hardware 
 telecommunications   C++ 
 Flash   Active Directory   Windows