Gentoo Logo

Disclaimer : 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

1.  Compiling, installing, and configuring Samba for your environment

Downloading Samba

OK, it's time to download Samba 2.0.7 or greater from the Web site (see Resources later in this article).

Note: 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, type:

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

$ make

After compilation completes, type the following as root to install the software:

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 smb.conf file:

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

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

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

Security options

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 following lines:

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 testparm utility:

Code Listing 1.14: Using testparm

$ 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 test run.

Creating users

In order for the "myuser" user with the "mypass" password to be able to use Samba, the following things must exist:

  1. 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.
  2. 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 The FQDN of your machine should map to the primary IP address used on your LAN. For example:

Code Listing 1.16: /etc/hosts

/etc/hosts excerpt       localhost   mybox

Starting Samba

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 root:

Code Listing 1.17: Starting Samba

# smbd
# nmbd

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:

  1. Your Windows machine can ping your Unix machine by name. (Type ping myserver at the C:\> prompt.)
  2. 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.
  3. 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 resource.

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 to check:

  1. Run testparm. Is your smb.conf OK? If not, fix the problem and restart Samba.
  2. Are smbd and nmbd running? If not, check the log files for possible errors, correct any issues, and restart smbd and nmbd.
  3. 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 your network.
  4. 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 again.

Next time

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!



Page updated October 6, 2005

Summary: In his previous article, Daniel introduced you to what Samba can do. Now it's time to get it running on your system. In this article, he'll walk you through the process of compiling, installing, and initially configuring Samba (version 2.0.7) so that it works in your environment.

Daniel Robbins

Donate to support our development efforts.

Copyright 2001-2017 Gentoo Foundation, Inc. Questions, Comments? Contact us.