The original version of this article was first published on IBM
developerWorks, and is property of Westtech Information Services. This
document is an updated version of the original article, and contains
various improvements made by the Gentoo Linux Documentation team.
This document is not actively maintained.
Introduction to Samba, Part 2
Compiling, installing, and configuring Samba for your environment
OK, it's time to download Samba 2.0.7 or greater from the Samba.org Web site
(see Resources later in this article).
While I'll be compiling Samba from scratch, you may choose to install Samba from
a binary package (such as RPM that came with your Linux distribution). This is
perfectly OK. But, as I mentioned in my last article, if you do this, your file
locations may be slightly different than what I refer to here.
After you've downloaded Samba 2.0.7 or greater, it's time to decompress it to a
directory location of your choice. From the command prompt, type:
Code Listing 1.1: Unpacking the source files
$ tar -xzvf samba-2.0.7.tar.gz
A samba-2.0.7 directory will be created. cd into it, and
we'll take a look around. First, notice the docs directory. Inside it you'll
see another directory called textdocs. texdocs
contains a whole bunch of Samba documentation. One of the most important files
in the textdocs directory is called DIAGNOSIS.txt. It walks you
through a step-by-step process of diagnosing problems you may have with proper
Samba operation. We'll be covering some, but not all, of the diagnosis
procedures mentioned in this file.
Compiling and installing Samba
You'll also notice the sources directory in the main
samba-2.0.7 directory. Inside sources you'll find a
well designed configure script designed to set up all the makefiles properly. As
with any other configure script, to get a list of the configuration options,
Code Listing 1.2: Investigating options
$ ./configure --help
You will probably want to pipe the output to more so that you can view
all the options:
Code Listing 1.3: Even more options
$ ./configure --help | more
Note the directory and file name options. Notice where everything gets
installed, and that the default install path is /usr/local/samba.
You will probably want to change this to /usr/local by passing the
--prefix=/usr/local option when you configure Samba. For this example,
I'm going to use the following path settings:
Code Listing 1.4: Configuring the directory options
$ ./configure --prefix=/usr/local --localstatedir=/var/log --sysconfdir=/etc
The above configuration options will cause Samba's default tree to be in
/usr/local, with the exception of the configuration files. Samba
will expect to find these in /etc and log files, which will end up
in /var/log. If you omit those configure options, you'll find
everything in the /usr/local/samba directory tree
(/usr/local/samba/var, /usr/local/samba/etc, etc.).
It's now time to start the compilation. After running configure, type:
Code Listing 1.5: Compiling Samba
After compilation completes, type the following as root to install the
Code Listing 1.6: Installing Samba
# make install
Configuring the server
For the most part, configuring Samba begins and ends with the
smb.conf file. This is Samba's main configuration file. It has
many different configuration options. To avoid confusion, we're going to start
only with those options essential to the proper operation of Samba. First,
you'll need to find out where smb.conf should be. If you used the
configuration options I specified above, you should place smb.conf
in /etc. If you used the default paths, Samba will look for it in
/usr/local/samba/etc. To get started, cd to the appropriate
directory, fire up your favorite text editor, and type in the following lines.
I'll intersperse commentary along the way to provide you with a good
understanding of what each option does. Add these lines to your
Code Listing 1.7: smb.conf
workgroup = YOURWORKGROUP
security = user
encrypt passwords = yes
guest account = guest
The first line tells Samba that we are placing options in the "global" section.
There are many options that are intended to be defined only in this section.
These options control the global behavior of Samba.
The second line tells Samba the name of the Windows workgroup that Samba will
create. Replace YOURWORKGROUP with an appropriate name for your workgroup.
On the third line, we tell Samba to run in user-level security mode. This
option will cause Samba to tell all connecting Windows clients that they need to
provide a valid username/password combination to gain access to any network
resource. This is definitely a good thing. User-level security is Samba's most
often used security level because it's an excellent match for the majority of
file sharing situations. However, there are other security levels available.
One handy mode tells Samba to authenticate all users against the security
database of an existing Windows NT or 2000 Server. We won't be covering that
particular mode in this article. If you want more information about it, take a
look at the "security" option in the smb.conf main page.
Now, on to the fourth line. Here we tell Samba to exchange passwords with Samba
in encrypted mode. You will always want to run Samba in encrypted mode, unless
all your client machines are extremely ancient (like Windows for Workgroups-era
machines). Enabling encrypted passwords does cause Samba to need its own
password file, in addition to the standard Unix password database. If you are
thinking that it may be nice to turn encrypted passwords off, so that you can
avoid having to maintain two password files, don't do it! Turning encrypted
passwords off will cause sharing problems with even moderately old versions of
Windows NT 4.0 in addition to Windows 2000. If you really want to avoid
maintaining two separate databases, Samba provides several ways to synchronize
both databases, which is a better approach.
The next line specifies a valid Unix user account that will be used
for guest access. While people often use "guest account=nobody", it's
recommended that you add a literal "guest" user to your system if one
doesn't exist already. The new "guest" account does not need a
password set and does not need to be able to log in interactively.
(It's fine if you do choose to configure guest with a password and a
valid default shell.)
Now we're ready to add WINS support options to smb.conf. You'll
want to add one of the following two lines to the global section:
Code Listing 1.8: WINS support
wins support = yes
Code Listing 1.9: WINS server IP address
wins server = IP address of WINS server
If you already have a WINS server on your current subnet (a Windows NT Server
running WINS, for example), you'll want to use the second option and specify the
name of the WINS server on the right side of the equals sign. Samba's internal
WINS services will then be disabled, and it will use the WINS server you
If you don't have a WINS server running on your subnet, or you're setting Samba
up at home and you don't know exactly what a WINS server is, you'll want to use
the first option. This will tell Samba to become a WINS server for your LAN.
You may be wondering what WINS does. Basically, you can think of WINS as a local
dynamic DNS database. When Samba is running as a WINS server, every
Windows-compatible machine on the same subnet will register its IP address and
NetBIOS name (a.k.a. "computer name") with Samba. This enables Windows machines
to use Samba's WINS database to request an IP address for a particular NetBIOS
name. WINS is a key component of network browsing, which is what you are doing
when you poke around inside the Network Neighborhood on a Windows machine.
Now we're ready to add several more options to the global section:
Code Listing 1.10: Network browsing setup
local master = yes
os level = 99
domain master = yes
preferred master = yes
Now for an explanation. All these options are related to network browsing. I've
already mentioned that WINS is a key component of network browsing, but there's
another element required for browsing to work properly. A local master browser
must exist. Sound strange? Some further explanation is required.
For browsing to work properly, there must be some central location that keeps
track of what machines and workgroups exist on the local subnet. This
particular list is called the browse list. The browse list is used to construct
the list of workgroups, domains, and machines you see when you first click on
the Network Neighborhood. Any modern Windows machine can become the local master
browser. Ideally, we'd like Samba to be the local master browser on the network.
How is this accomplished? Basically, several beefy Windows-compatible machines
on your subnet will regularly duke it out by flinging packets back and forth
across your LAN in an attempt to determine who will become the local master
browser. This process is called a "browser election."
Be a good sport. Please don't use Samba's ability to beat Windows in all
browser elections as an excuse to tease Microsoft administrators in your
organization. Remember, it's important to be a good winner.
In the end the "winner" of this broadcast packet war gets to become the local
master browser. We can cause Samba to win the battle by using the os level =
99 option, which causes it to beat every other machine on the LAN. This
happens because every version of Windows (from Windows 95 to NT to 2000) has a
hard-coded OS level that was intended to cause the most advanced version of
Windows to become the local master browser (later versions of Windows have a
bigger number). Setting Samba to 99 will cause it to beat all Microsoft
products, allowing it to become the local master browser every time.
Before we leave the global section, here are a few security options that you may
be interested in. The host's allow option lets you limit the IP addresses
that can connect to Samba:
Code Listing 1.11: Allowed IP addresses
hosts allow = 192.168.1. 127.
This option allows only machines in the 192.168.1 network to connect to
Samba, in addition to 127, the localhost. Always make sure there is a
127. at the end of your hosts allow line.
The interfaces option is very useful if your machine happens to have multiple
network interfaces. It allows you to specify the network interfaces on which
Samba is available. It is used as follows:
Code Listing 1.12: Specifying interfaces
interfaces = eth1
This is an easy way to limit Samba to the necessary interfaces. And limiting
the interfaces prevents possible hacking attempts from unwanted users.
A test share
Now that we've configured Samba's global options, it's time to create a test
share that will allow us to access the /tmp directory. Add the
Code Listing 1.13: Setting the /tmp directory
When Samba is started, these settings will make a share available called
tmp. This share will contain the contents of your /tmp
directory on your Samba server. Also, if a particular user has write permission
in /tmp, as almost all do, that user will be able to create and
modify files in that directory.
Now that we've added all these entries to smb.conf, it's time to
verify that our configuration is correct. To do this, we'll use the
Code Listing 1.14: Using testparm
A list of all your configuration options will be listed to the screen after you
hit Enter. Any errors in smb.conf will also be noted and commented
upon at this point. If there are any errors, follow the instructions on-screen
to fix them. Now we're ready to configure Samba users and fire up Samba for the
In order for the "myuser" user with the "mypass" password to be able to use
Samba, the following things must exist:
A valid myuser Unix account. myuser does not need to be able
to log in, and myuser's Unix password is not used by Samba, so you
can set to a dummy value if you like. If myuser also logs in
interactively to your Samba server, that's OK, too.
A valid myuser entry in the smbpasswd file. The
smbpasswd file is found in the directory called
private that resides in the default Samba install prefix
(/usr/local/private in this example). myuser can be
added to the smbpasswd file by using the smbpasswd
command and by typing the following as root:
Code Listing 1.15: Adding users
# smbpasswd -a myuser
New SMB password: <enter "mypass" here>
Retype new SMB password: <enter "mypass" again>
Added user myuser.
These steps must be repeated for every new Samba user. If you are Samba-enabling
an existing Unix account, remember to add the username and password to the
smbpasswd file. If you're adding a Windows-only user, remember that
in addition to adding the user to the smbpasswd file you'll also
need to create a valid Unix account with an identical username. In fact, you'll
need to create the Unix account first since smbpasswd won't add a
user unless the Unix account already exists.
Both accounts are needed because Samba uses the Unix account to set the proper
permissions on disk, while the smbpasswd file is used for
authentication purposes. If you are going to connect from Windows NT, you'll
want to create a Samba "administrator" user.
Final server configuration
We're almost ready to start Samba and configure the client machines. But you
must first make sure that your Samba box can ping every Windows client machine
on your network, by name. If this doesn't work, you'll need to add some entries
to /etc/hosts or update your DNS so that your Samba box can
properly find your Windows machines.
It is also helpful to note that Samba works best when /etc/hosts is
set up so that only the "localhost" name maps to 127.0.0.1. The FQDN of your
machine should map to the primary IP address used on your LAN. For example:
Code Listing 1.16: /etc/hosts
192.168.1.1 mybox mybox.mydomain.com
Samba is now configured and ready to go. We'll start Samba and then focus on
configuring the Windows machines properly. To start Samba, type the following as
Code Listing 1.17: Starting Samba
This will start Samba's two main server processes, smbd and nmbd.
They will log any informational and error messages to
/var/log/log.smb and /var/log/log.nmb, respectively.
Now that the Unix side is up and running, it's time to turn to the client
machines and get them set up properly.
Configuring client machines
To configure a Windows machine so that it can participate in your Samba
Workgroup, you'll need to make sure the TCP/IP protocol is properly configured.
You must also make sure that:
Your Windows machine can ping your Unix machine by name. (Type ping
myserver at the C:\> prompt.)
Your Windows machine is configured to use a WINS server. If Samba is
providing WINS services, this should be set to the IP of your Samba box. If
not, it should be set to the IP of a valid WINS server. This setting is
normally found inside the TCP/IP settings dialog.
- Your Windows machine is a member of YOURWORKGROUP.
Testing it out
Now is the moment of truth. After your Windows machines have finished rebooting,
you'll need to log on to Windows using a username/password that will be accepted
by Samba. If you're using Windows 95/98, this username/password combo will be
simply stored in a file and used later when you try to connect to any network
If you are using Windows NT Workstation, this username/password combo must also
be in the NT's local security database (otherwise you won't be able to initially
log in to NT). To do this, log on to NT as administrator and create the account
using User Manager. Afterwards, log out and log in as the new user.
After you've properly logged in, double-click on the Network Neighborhood and
take a look at the YOURWORKGROUP workgroup. Look inside. See if your Samba
server is listed. Double-click on it and see if the /tmp share is
listed. If so, congratulations! Samba is working! If not, here are some things
Run testparm. Is your smb.conf OK? If not, fix the
problem and restart Samba.
Are smbd and nmbd running? If not, check the log files for
possible errors, correct any issues, and restart smbd and
Did you configure your Windows client machines to use a proper WINS server?
If not, they will have problems looking up the IP addresses of machines on
Can you ping the Unix machine from Windows and vice-versa? If not, you'll
need to configure your /etc/hosts file or DNS so that name
resolution is working properly.
If all these things check out and Samba is still not working, carefully follow
each step in the DIAGNOSIS.txt file found in the docs/textdocs
directory. You should be able to pinpoint and fix your configuration or network
problem within minutes. If you change smb.conf in any way, you'll
need to send smbd and nmbd a HUP signal to force them to reread
smb.conf. This is done as follows:
Code Listing 1.18: Troubleshooting
# kill -hup <pid of smbd>
# kill -hup <pid of nmbd>
Alternately, you can simply kill smbd and nmbd and restart them
In my next Samba article I'll
familiarize you with Samba's more advanced options. Then you'll be able to set
up shares that function exactly the way you want them to. We'll also look at
several advanced features of Samba, like Samba printing. I'll see you then!