Using Samba

Chapter 4. Disk Shares

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.

Learning the Samba Configuration File

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.

Configuration File Structure

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:

               option = value

Options in the smb.conf file are set by assigning a value to them. We should warn you up front that some of the option names in Samba are poorly chosen. For example, read only is self-explanatory, and is typical of many recent Samba options. public is an older option, and is vague; it now has a less-confusing synonym guest ok (may be accessed by guests). We describe some of the more common historical names in this chapter in sections that highlight each major task. In addition, Appendix C, contains an alphabetical index of all the configuration options and their meanings.

Whitespaces, quotes, and commas

An important item to remember about configuration options is that all whitespaces in the value are significant. For example, consider the following option:

volume = The Big Bad Hard Drive Number 3543

Samba strips away the spaces between the final e in volume and the first T in The. These whitespaces are insignificant. The rest of the whitespaces are significant and will be recognized and preserved by Samba when reading in the file. Space is not significant in option names (such as guest ok), but we recommend you follow convention and keep spaces between the words of options.

If you feel safer including quotation marks at the beginning and ending of a configuration option’s value, you may do so. Samba will ignore these quotation marks when it encounters them. Never use quotation marks around an option itself; Samba will treat this as an error.

Finally, you can use whitespaces to separate a series of values in a list, or you can use commas. These two options are equivalent:

netbios aliases = sales, accounting, payroll
netbios aliases = sales accounting payroll

In some values, however, you must use one form of separation—spaces in some cases, commas in others.

Capitalization

Capitalization is not important in the Samba configuration file except in locations where it would confuse the underlying operating system. For example, let’s assume that you included the following option in a share that pointed to /export/samba/simple :

PATH = /EXPORT/SAMBA/SIMPLE

Samba would have no problem with the path configuration option appearing entirely in capital letters. However, when it tries to connect to the given directory, it would be unsuccessful because the Unix filesystem in the underlying operating system is case sensitive. Consequently, the path listed would not be found and clients would be unable to connect to the share.

Line continuation

You can continue a line in the Samba configuration file using the backslash, as follows:

comment = The first share that has the primary copies \
          of the new Teamworks software product.

Because of the backslash, these two lines will be treated as one line by Samba. The second line begins at the first non-whitespace character that Samba encounters; in this case, the o in of.

Comments

You can insert comments in the smb.conf configuration file by preceding a line with either a hash mark (#) or a semicolon ( ; ). Both characters are equivalent. For example, the first three lines in the following example would be considered comments:

#  This is the printers section. We have given a minimum print 
;  space of 2000 to prevent some errors that we've seen when
;  the spooler runs out of space.

[printers] 
	public = yes
	min print space = 2000

Samba will ignore all comment lines in its configuration file; there are no limitations to what can be placed on a comment line after the initial hash mark or semicolon. Note that the line continuation character (\) will not be honored on a commented line. Like the rest of the line, it is ignored.

Changes at runtime

You can modify the smb.conf configuration file and any of its options at any time while the Samba daemons are running. By default, Samba checks the configuration file every 60 seconds for changes. If it finds any, the changes are immediately put into effect. If you don’t wish to wait that long, you can force a reload by either sending a SIGHUP signal to the smbd and nmbd processes, or simply restarting the daemons.

For example, if the smbd process was 893, you could force it to reread the configuration file with the following command:

# kill -SIGHUP 893

Not all changes will be immediately recognized by clients. For example, changes to a share that is currently in use will not be registered until the client disconnects and reconnects to that share. In addition, server-specific parameters such as the workgroup or NetBIOS name of the server will not register immediately either. This keeps active clients from being suddenly disconnected or encountering unexpected access problems while a session is open.

Variables

Samba includes a complete set of variables for determining characteristics of the Samba server and the clients to which it connects. Each of these variables begins with a percent sign, followed by a single uppercase or lowercase letter, and can be used only on the right side of a configuration option (e.g., after the equal sign):

[pub]
    path = /home/ftp/pub/%a

The %a stands for the client machine’s architecture (e.g., WinNT for Windows NT, Win95 for Windows 95 or 98, or WfWg for Windows for Workgroups). Because of this, Samba will assign a unique path for the [pub] share to client machines running Windows NT, a different path for client machines running Windows 95, and another path for Windows for Workgroups. In other words, the paths that each client would see as its share differ according to the client’s architecture, as follows:

/home/ftp/pub/WinNT
/home/ftp/pub/Win95
/home/ftp/pub/WfWg

Using variables in this manner comes in handy if you wish to have different users run custom configurations based on their own unique characteristics or conditions. Samba has 19 variables, as shown in Table 4.1.

Table 4-1. Samba Variables

Variable	Definition
Client variables
%a	Client’s architecture (e.g., Samba, WfWg, WinNT, Win95, or UNKNOWN)
%I	Client’s IP address (e.g., 192.168.220.100)
%m	Client’s NetBIOS name
%M	Client’s DNS name
User variables
%g	Primary group of %u
%G	Primary group of %U
%H	Home directory of %u
%u	Current Unix username
%U	Requested client username (not always used by Samba)
Share variables
%p	Automounter’s path to the share’s root directory, if different from %P
%P	Current share’s root directory
%S	Current share’s name
Server variables
%d	Current server process ID
%h	Samba server’s DNS hostname
%L	Samba server’s NetBIOS name
%N	Home directory server, from the automount map
%v	Samba version
Miscellaneous variables
%R	The SMB protocol level that was negotiated
%T	The current date and time

Here’s another example of using variables: let’s say that there are five clients on your network, but one client, fred, requires a slightly different [homes] configuration loaded when it connects to the Samba server. With Samba, it’s simple to attack such a problem:

[homes] 
	...
	include = /usr/local/samba/lib/smb.conf.%m
	...

The include option here causes a separate configuration file for each particular NetBIOS machine (%m) to be read in addition to the current file. If the hostname of the client machine is fred, and if a smb.conf.fred file exists in the samba_dir /lib/ directory (or whatever directory you’ve specified for your configuration files), Samba will insert that configuration file into the default one. If any configuration options are restated in smb.conf.fred, those values will override any options previously encountered in that share. Note that we say “previously.” If any options are restated in the main configuration file after the include option, Samba will honor those restated values for the share in which they are defined.

Here’s the important part: if there is no such file, Samba will not generate an error. In fact, it won’t do anything at all. This allows you to create only one extra configuration file for fred when using this strategy, instead of one for each NetBIOS machine that is on the network.

Machine-specific configuration files can be used both to customize particular clients and to make debugging Samba easier. Consider the latter; if we have one client with a problem, we can use this approach to give it a private log file with a more verbose logging level. This allows us to see what Samba is doing without slowing down all the other clients or overflowing the disk with useless logs. Remember, with large networks you may not always have the option to restart the Samba server to perform debugging!

You can use each of the variables in Table 4.1 to give custom values to a variety of Samba options. We will highlight several of these options as we move through the next few chapters.