6.1 The Samba Configuration File

   

The Samba configuration file, called smb.conf by default, uses the same format as Windows .ini files. If you have ever worked with a .ini file, you will find smb.conf easy to create and modify. Even if you haven't, you will find the format to be simple and easy to learn. Here is an example of a Samba configuration file:

 [global]     workgroup = METRAN     encrypt passwords = yes     wins support = yes     log level = 1      max log size = 1000     read only = no [homes]      browsable = no     map archive = yes [printers]      path = /var/tmp     printable = yes     min print space = 2000 [test]     browsable = yes     read only = yes     path = /usr/local/samba/tmp 

This configuration file is based on the one we created in Chapter 2 and sets up a workgroup in which Samba authenticates users using encrypted passwords and the default user -level security method. Samba is providing WINS name server support. We've configured very basic event logging to use a log file not to exceed 1MB in size. The [homes] share has been added to allow Samba to create a disk share for the home directory of each user who has a standard Unix account on the server. In addition, each printer registered on the server will be publicly available, as will a single read-only share that maps to the /usr/local/samba/tmp directory.

6.1.1 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) to which the section refers. For example, the [test] and [homes] sections are 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 for that share. These options will continue until a new 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. The public option is an older option and is vague. It now has a less-confusing synonym guest ok (meaning it can be accessed by guests). Appendix B contains an alphabetical index of all the configuration options and their meanings.

6.1.1.1 Whitespace, quotes, and commas

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

 volume = The Big Bad Hard Drive Number 3543 

Samba strips away the spaces up to 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 read only ), 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 end of a configuration option's value, you can do so. Samba will ignore these quotation marks when it encounters them. Never use quotation marks around an option name; Samba will treat this as an error.

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

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

In some cases, you must use one form of separation ”sometimes spaces are required, and sometimes commas.

6.1.1.2 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 is case-sensitive. Consequently, the path listed would not be found, and clients could not connect to the share.

6.1.1.3 Line continuation

You can continue a line in the Samba configuration file using the backslash, like this:

 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 nonwhitespace character that Samba encounters; in this case, the o in of .

6.1.1.4 Comments

You can insert comments in the smb.conf configuration file by starting a line with either a hash ( # ) or a semicolon ( ; ). For this purpose, 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.

Samba does not allow mixing of comment lines and parameters. Be careful not to put comments on the same line as anything else, such as:

 path = /d # server's data partition 

Errors such as this, where the parameter value is defined with a string, can be tricky to notice. The testparm program won't complain, and the only clues you'll receive are that testparm reports the path parameter set to /d # server's data partition , and the failures that result when clients attempt to access the share.

6.1.1.5 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. If it finds any changes, they are immediately put into effect.

Having Samba check the configuration file automatically can be convenient , but it also means that if you edit smb.conf directly, you might be immediately changing your network's configuration every time you save the file. If you're making anything more than a minor change, it may be wiser to copy smb.conf to a temporary file, edit that, run testparm filename to check it, and then copy the temporary file back to smb.conf . That way, you can be sure to put all your changes into effect at once, and only after you are confident that you have created the exact configuration you wish to implement.

If you don't want to wait for the configuration file to be reloaded automatically, you can force a reload either by sending a hangup signal to the smbd and nmbd processes or simply by restarting the daemons. Actually, it can be a good idea to restart the daemons because it forces the clients to disconnect and reconnect , ensuring that the new configuration is applied to all clients. We showed you how to restart the daemons in Chapter 2, and sending them a hangup (HUP) signal is very similar. On Linux, it can be done with the command:

 #  killall -HUP smbd nmbd  

In this case, 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 go into effect immediately either. (This behavior was implemented intentionally because it keeps active clients from being suddenly disconnected or encountering unexpected access problems while a session is open .)

6.1.2 Variables

Because a new copy of the smbd daemon is created for each connecting client, it is possible for each client to have its own customized configuration file. Samba allows a limited, yet useful, form of variable substitution in the configuration file to allow information about the Samba server and the client to be included in the configuration at the time the client connects. Inside the configuration file, a variable begins with a percent sign ( % ), followed by a single upper- or lowercase letter, and can be used only on the right side of a configuration option (i.e., after the equal sign). An example is:

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

The %a stands for the client system's architecture and will be replaced as shown in Table 6-1.

Table 6-1. %a substitution

Client operating system ("architecture")

Replacement string

Windows for Workgroups

WfWg

Windows 95 and Windows 98

Win95

Windows NT

WinNT

Windows 2000 and Windows XP

Win2K

Samba

Samba

Any OS not listed earlier

UNKNOWN

In this example, Samba will assign a unique path for the [pub] share to client systems based on what operating system they are running. The paths that each client would see as its share differ according to the client's architecture:

 /home/ftp/pub/WfwG /home/ftp/pub/Win95 /home/ftp/pub/WinNT /home/ftp/pub/Win2K /home/ftp/pub/Samba /home/ftp/pub/UNKNOWN 

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 20 variables, as shown in Table 6-2.

Table 6-2. Samba variables

Variable

Definition

Client variables

%a

Client's architecture (see Table 6-1)

%I

Client's IP address (e.g., 172.16.1.2)

%m

Client's NetBIOS name

%M

Client's DNS name

User variables

%u

Current Unix username

%U

Requested client username (not always used by Samba)

%H

Home directory of %u

%g

Primary group of %u

%G

Primary group of %U

Share variables

%S

Current share's name

%P

Current share's root directory

%p

Automounter's path to the share's root directory, if different from %P

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

%$ var

The value of environment variable var

Here's another example of using variables: let's say there are five clients on your network, but one client, maya , requires a slightly different [homes] configuration. With Samba, it's simple to handle this:

 [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 system is maya , and if a smb.conf.maya file exists in the /usr/local/samba/lib directory, Samba will insert that configuration file into the default one. If any configuration options are restated in smb.conf.maya , 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.

If the file specified by the include parameter does not exist, 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 maya when using this strategy, instead of one for each client that is on the network.

Client-specific configuration files can be used to customize particular clients. They also can be used to make debugging Samba easier. For example, 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.

You can use the variables in Table 6-2 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.

   


Using Samba
Using Samba: A File and Print Server for Linux, Unix & Mac OS X, 3rd Edition
ISBN: 0596007698
EAN: 2147483647
Year: 2003
Pages: 475

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net