Chapter 6. The Samba Configuration File

In previous 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 300 unique options (also called parameters). Some of these options you will use and change frequently; others you might never use, depending 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 options to create and modify disk shares. Subsequent chapters will discuss browsing, how to configure users, security, printing, and other topics related to implementing Samba on your network.

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.

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.

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.

TIP

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

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.

Special Sections

Now that we've gotten our feet wet with variables, there are a few special sections of the Samba configuration file that we should talk about. Again, don't worry if you do not understand every configuration option listed here; we'll go over each of them in the upcoming chapters.

The [ global] Section

The [global] section appears in virtually every Samba configuration file, even though it is not mandatory. There are two purposes for the [global] section. Server-wide settings are defined here, and any options that apply to shares will be used as a default in all share definitions, unless overridden within the share definition.

To illustrate this, let's again look at the example at the beginning of the chapter:

[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

When a client connects to the [test] share, Samba first reads the [global] section and sets the option read only = no as the global default for each share it encounters throughout the configuration file. This includes the [homes] and [test] shares. When it reads the definition of the [test] share, it then finds the configuration option read only = yes and overrides the default from the [global] section with the value yes.

Any option that appears before the first marked section is assumed to be a global option. This means that the [global] section heading is not absolutely required; however, we suggest you always include it for clarity and to ensure future compatibility.

The [ homes] Section

If a client attempts to connect to a share that doesn't appear in the smb.conf file, Samba will search for a [homes] share in the configuration file. If a [homes] share exists, the unresolved share name is assumed to be a Unix username. If that username appears in the password database on the Samba server, Samba assumes the client is a Unix user trying to connect to her home directory on the server.

For example, assume a client system is connecting to the Samba server toltec for the first time and tries to connect to a share named [alice]. There is no [alice] share defined in the smb.conf file, but there is a [homes], so Samba searches the password database file and finds an alice user account is present on the system. Samba then checks the password provided by the client against user alice's Unix password—either with the password database file if it's using nonencrypted passwords or with Samba's smbpasswd file if encrypted passwords are in use. If the passwords match, Samba knows it has guessed right: the user alice is trying to connect to her home directory. Samba will then create a share called [alice] for her, with the share's path set to alice's home directory.

The process of using the [homes] section to create users (and dealing with their passwords) is discussed in more detail in Chapter 9.

The [printers] Section

The third special section is called [printers] and is similar to [homes]. If a client attempts to connect to a share that isn't in the smb.conf file and its name can't be found in the password file, Samba will check to see if it is a printer share. Samba does this by reading the printer capabilities file (usually /etc/printcap) to see if the share name appears there.[1] If it does, Samba creates a share named after the printer.

This means that as with [homes], you don't have to maintain a share for each system printer in the smb.conf file. Instead, Samba honors the Unix printer registry if you ask it to, and it provides the registered printers to the client systems. However, there is a potential difficulty: if you have an account named fred and a printer named fred, Samba will always find the user account first, even if the client really needed to connect to the printer.

The process of setting up the [printers] share is discussed in more detail in Chapter 10.

Configuration Options

Options in the Samba configuration files fall into one of two categories: global options or share options. Each category dictates where an option can appear in the configuration file.

Global options

Global options must appear in the [global] section and nowhere else. These are options that typically apply to the behavior of the Samba server itself and not to any of its shares.

Share options

Share options can appear in share definitions, the [global] section, or both. If they appear in the [global] section, they will define a default behavior for all shares unless a share overrides the option with a value of its own.

In addition, configuration options can take three kinds of values. They are as follows:

Boolean

These are simply yes or no values, but can be represented by any of the following: yes, no, true, false, 1, or 0. The values are case-insensitive: YES is the same as yes.

Numeric

This is a decimal, hexadecimal, or octal number. The standard 0xnn syntax is used for hexadecimal and 0nnn for octal.

String

This is a string of case-sensitive characters, such as a filename or a username.

Configuration File Options

You can instruct Samba to include or replace configuration options as it is processing them. The options to do this are summarized in Table 6-3.

Table 6-3. Configuration file options

Option

Parameters

Function

Default

Scope

config file

string (name of file)

Sets the location of a configuration file to use instead of the current one

None

Global

include

string (name of file)

Specifies an additional set of configuration options to be included in the configuration file

None

Global

copy

string (name of share)

Allows you to clone the configuration options of another share in the current share

None

Share

include

This option, discussed in greater detail earlier, copies the target file into the current configuration file at the point specified, as shown in Figure 6-1. This option also can be used with variables. You can use this option as follows:

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

If the configuration file specified does not exist, the option is ignored. Options in the include file override any option specified previously, but not options that are specified later. In Figure 6-1, all three options will override their previous values.

Figure 6-1. The include option in a Samba configuration file

The include option does not work with the variables %u (user), %P (current share's root directory), or %S (current share's name) because they are not set at the time the include parameter is processed.

Server Configuration

We will now start from scratch and build a configuration file for our Samba server. First we will introduce three basic configuration options that can appear in the [global] section of the smb.conf file:

[global]
    #  Server configuration parameters
    netbios name = toltec
    server string = Samba %v on %L
    workgroup = METRAN
    encrypt passwords = yes

This configuration file is pretty simple; it advertises the Samba server under the NetBIOS name toltec. In addition, it places the system in the METRAN workgroup and displays a description to clients that includes the Samba version number, as well as the NetBIOS name of the Samba server.

TIP

If you used the line encrypt passwords = yes in your earlier configuration file, you should do so here as well.

If you like, you can go ahead and try this configuration file. Create a file named smb.conf under the /usr/local/samba/lib directory with the text listed earlier. Then restart the Samba server and use a Windows client to verify the results. Be sure that your Windows clients are in the METRAN workgroup as well. After double-clicking the Network Neighborhood on a Windows client, you should see a window similar to Figure 6-2. (In this figure, Mixtec is another Samba server, and Zapotec is a Windows client.)

Figure 6-2. Network Neighborhood showing Toltec, the Samba server

You can verify the server string by listing the details of the Network Neighborhood window (select Details in the View menu). You should see a window similar to Figure 6-3.

Figure 6-3. Network Neighborhood details listing

If you were to click the toltec icon, a window should appear that shows the services that it provides. In this case, the window would be completely empty because there are no shares on the server yet.

Server Configuration Options

Table 6-4 summarizes the server configuration options introduced previously. All three of these options are global in scope, so they must appear in the [global] section of the configuration file.

Table 6-4. Server configuration options

Option

Parameters

Function

Default

Scope

netbios name

string

NetBIOS name of the Samba server

Server's unqualified DNS hostname

Global

workgroup

string

NetBIOS group to which the server belongs

Defined at compile time

Global

server string

string

Descriptive string for the Samba server

Samba %v

Global

netbios name

The netbios name option allows you to set the NetBIOS name of the server. For example:

netbios name = YORKVM1

The default value for this configuration option is the server's hostname—that is, the first part of its fully qualified domain name. For example, a system with the DNS name ruby.ora.com would be given the NetBIOS name RUBY by default. While you can use this option to restate the system's NetBIOS name in the configuration file (as we did previously), it is more commonly used to assign the Samba server a NetBIOS name other than its current DNS name. Remember that the name given must follow the rules for valid NetBIOS machine names as outlined in Chapter 1.

Changing the NetBIOS name of the server is not recommended unless you have a good reason. One such reason might be if the hostname of the system is not unique because the LAN is divided over two or more DNS domains. For example, YORKVM1 is a good NetBIOS candidate for vm1.york.example.com to differentiate it from vm1.falkirk.example.com, which has the same hostname but resides in a different DNS domain.

Another use of this option is for relocating SMB services from a dead or retired system. For example, if SALES is the SMB server for the department and it suddenly dies, you could immediately reset netbios name = SALES on a backup Samba server that's taking over for it. Users won't have to change their drive mappings to a different server; new connections to SALES will simply go to the new server.

workgroup

The workgroup parameter sets the current workgroup (or domain) in which the Samba server will advertise itself. Clients that wish to access shares on the Samba server should be in the same NetBIOS group. Remember that workgroups are really just NetBIOS group names and must follow the standard NetBIOS naming conventions outlined in Chapter 1.

The default option for this parameter is set at compile time to WORKGROUP. Because this is the default workgroup name of every unconfigured Windows and Samba system, we recommend that you always set your workgroup name in the Samba configuration file. When choosing your workgroup name, try to avoid making it the same name as a server or user. This will avoid possible problems with WINS name resolution.

server string

The server string parameter defines a comment string that will appear next to the server name in both the Network Neighborhood (when shown with the Details view) and the comment entry of the Microsoft Windows printer manager.[2]

You can use variables to provide information in the description. For example, our entry earlier was:

[global]
    server string = Samba %v on (%h)

The default for this option simply presents the current version of Samba and is equivalent to:

server string = Samba %v

Disk Share Configuration

We mentioned in the previous section that there were no disk shares on the toltec server. Let's continue building the configuration file and create an empty disk share called [data]. Here are the additions that will do it:

[data]
    path = /export/samba/data
    comment = Data Drive
    volume = Sample-Data-Drive
    writable = yes

The [data] share is typical for a Samba disk share. The share maps to the directory /export/samba/data on the Samba server. We've also provided a comment that describes the share as a Data Drive, as well as a volume name for the share itself.

Samba's default is to create a read-only share. As a result, the writable option needs to be explicitly set for each disk share you wish to make writable.

We will also need to create the /export/samba/data directory on the Samba server with the following commands:

# mkdir /export/samba/data
# chmod 777 /export/samba/data

Now, if we connect to the toltec server again by double-clicking its icon in the Windows Network Neighborhood, we will see a single share entitled data, as shown in Figure 6-4. This share has read/write access, so files can be copied to or from it.

Figure 6-4. The initial data share on the Samba server

Disk Share Configuration Options

The basic Samba configuration options for disk shares previously introduced are listed in Table 6-5.

Table 6-5. Basic share configuration options

Option

Parameters

Function

Default

Scope

path (directory)

string (directory name)

Sets the Unix directory that will be provided for a disk share or used for spooling by a printer share.

/tmp

Share

comment

string

Sets the comment that appears with the share.

None

Share

volume

string

Sets the MS-DOS volume name for the share.

Share name

Share

read only

boolean

If yes, allows read-only access to a share.

yes

Share

writable (write ok or writeable)

boolean

If no, allows read-only access to a share. If yes, both reading and writing are allowed.

no

Share

Networking Options with Samba

If you're running Samba on a multihomed system (on multiple subnets), you will need to configure Samba to use all the network interfaces. Another use for the options presented in this section is to implement better security by allowing or disallowing connections on the specified interfaces.

Let's assume that our Samba server can access both the subnets 192.168.220.* and 134.213.233.*. Here are our additions to the configuration file to add the networking configuration options:

[global]
    #  Networking configuration options
    hosts allow = 192.168.220. 134.213.233.
    hosts deny = 192.168.220.102
    interfaces = 192.168.220.100/255.255.255.0 \
                    134.213.233.110/255.255.255.0
    bind interfaces only = yes

Take a look at the hosts allow and hosts deny options. If these options sound familiar, you're probably thinking of the hosts.allow and hosts.deny files that are found in the /etc directories of many Unix systems. The purpose of these options is identical to those files; they provide a means of security by allowing or denying the connections of other hosts based on their IP addresses. We could use the hosts.allow and hosts.deny files, but we are using this method instead because there might be services on the server that we want others to access without also giving them access to Samba's disk or printer shares.

With the hosts allow option, we've specified a 192.168.220 IP address, which is equivalent to saying: "All hosts on the 192.168.220 subnet." However, we've explicitly specified in a hosts deny line that 192.168.220.102 is not to be allowed access.

You might be wondering why 192.168.220.102 will be denied even though it is still in the subnet matched by the hosts allow option. It is important to understand how Samba sorts out the rules specified by hosts allow and hosts deny :

  1. If no allow or deny options are defined anywhere in smb.conf, Samba will allow connections from any system.

  2. If hosts allow or hosts deny options are defined in the [global] section of smb.conf, they will apply to all shares, even if either option is defined in one or more of the shares.

  3. If only a hosts allow option is defined for a share, only the hosts listed will be allowed to use the share. All others will be denied.

  4. If only a hosts deny option is defined for a share, any client which is not on the list will be able to use the share.

  5. If both a hosts allow and hosts deny option are defined, a host must appear in the allow list and not appear in the deny list (in any form) to access the share. Otherwise, the host will not be allowed.

WARNING

Take care that you don't explicitly allow a host to access a share, but then deny access to the entire subnet of which the host is part.

Let's look at another example of that final item. Consider the following options:

hosts allow = 111.222.
hosts deny = 111.222.333.

In this case, only the hosts that belong to the subnet 111.222.*.* will be allowed access to the Samba shares. However, if a client belongs to the 111.222.333.* subnet, it will be denied access, even though it still matches the qualifications outlined by hosts allow. The client must appear on the hosts allow list and must not appear on the hosts deny list to gain access to a Samba share.

The other two options that we've specified are interfaces and bind interface only. Let's look at the interfaces option first. Samba, by default, sends data only from the primary network interface, which in our example is the 192.168.220.100 subnet. If we would like it to send data to more than that one interface, we need to specify the complete list with the interfaces option. In the previous example, we've bound Samba to interface with both subnets (192.168.220 and 134.213.233) on which the system is operating by specifying the other network interface address: 134.213.233.100. If you have more than one interface on your computer, you should always set this option, as there is no guarantee that the primary interface that Samba chooses will be the right one.

Finally, the bind interfaces only option instructs the nmbd process not to accept any broadcast messages other than on the subnets specified with the interfaces option. This is different from the hosts allow and hosts deny options, which prevent clients from making connections to services, but not from receiving broadcast messages. Using the bind interfaces only option is a way to shut out all datagrams from foreign subnets. In addition, it instructs the smbd process to bind to only the interface list given by the interfaces option. This restricts the networks that Samba will serve.

Networking Options

The networking options we introduced earlier are summarized in Table 6-6.

Table 6-6. Networking configuration options

Option

Parameters

Function

Default

Scope

hosts allow (allow hosts)

string (list of hostnames)

Client systems that can connect to Samba.

None

Share

hosts deny (deny hosts)

string (list of hostnames)

Client systems that cannot connect to Samba.

None

Share

interfaces

string (list of IP/netmask combinations)

Network interfaces Samba will respond to. Allows correcting defaults.

System-dependent

Global

bind

interfaces only

boolean

If set to yes, Samba will bind only to those interfaces specified by the interfaces option.

no

Global

hosts allow

The hosts allow option (sometimes written as allow hosts) specifies the clients that have permission to access shares on the Samba server, written as a comma- or space-separated list of hostnames of systems or their IP addresses. You can gain quite a bit of security by simply placing your LAN's subnet address in this option.

You can specify any of the following formats for this option:

  • Hostnames, such as ftp.example.com .

  • IP addresses, such as 130.63.9.252.

  • Domain names, which can be differentiated from individual hostnames because they start with a dot. For example, .ora.com represents all systems within the ora.com domain.

  • Netgroups, which start with an at sign (@), such as @printerhosts. Netgroups are usually available only on systems running NIS or NIS+. If netgroups are supported on your system, there should be a netgroups manual page that describes them in more detail.

  • Subnets, which end with a dot. For example, 130.63.9. means all the systems whose IP addresses begin with 130.63.9.

  • The keyword ALL, which allows any client access.

  • The keyword EXCEPT followed by one or more names, IP addresses, domain names, netgroups, or subnets. For example, you could specify that Samba allow all hosts except those on the 192.168.110 subnet with hosts allow = ALL EXCEPT 192.168.110. (remember to include the trailing dot).

Using the ALL keyword by itself is almost always a bad idea because it means that crackers on any network can access your Samba server.

The hostname localhost, for the loopback address 127.0.0.1, is included in the hosts allow list by default and does not need to be listed explicitly unless you have specified the bind interfaces only parameter. This address is required for Samba to work properly.

Other than that, there is no default value for the hosts allow configuration option. The default course of action in the event that neither the hosts allow or hosts deny option is specified in smb.conf is to allow access from all sources.

TIP

If you specify hosts allow in the [global] section, that definition will override any hosts allow lines in the share definitions. This is the opposite of the usual behavior, which is for parameters set in share definitions to override default values set in the [global] section.

Virtual Servers

Virtual servers can be used to create the illusion of having multiple servers on the network, when in reality there is only one. The technique is simple to implement: a system simply registers more than one NetBIOS name in association with its IP address. There are tangible benefits to doing this.

For example, the accounting department might have an accounting server, and clients of it would see just the accounting disks and printers. The marketing department could have its own server, marketing, with its own reports, and so on. However, all the services would be provided by one medium-size Unix server (and one relaxed administrator) instead of having one small server per department.

Virtual Server Configuration Options

Samba will allow a server to use more than one NetBIOS name with the netbios aliases option. See Table 6-7.

Table 6-7. Virtual server configuration options

Option

Parameters

Function

Default

Scope

netbios aliases

string (list of NetBIOS names)

Additional NetBIOS names to respond to, for use with multiple "virtual" Samba servers

None

Global

netbios aliases

The netbios aliases option can be used to give the Samba server more than one NetBIOS name. Each NetBIOS name listed as a value will be displayed in the Network Neighborhood of Windows clients. When a connection is requested to any of the servers, it will connect to the same Samba server.

This might come in handy, for example, if you're transferring three departments' data to a single Unix server with larger and faster disks and are retiring or reallocating the old Windows NT/2000 servers. If the three servers are called sales, accounting, and admin, you can have Samba represent all three servers with the following options:

[global]
    netbios aliases = sales accounting admin
    include = /usr/local/samba/lib/smb.conf.%L

See Figure 6-5 for what the Network Neighborhood would display from a client. When a client attempts to connect to Samba, it will specify the name of the server to which it's trying to connect, which is made available in the configuration file through the %L variable. If the requested server is sales, Samba will include the file /usr/local/samba/lib/smb.conf.sales. This file might contain global and share declarations exclusively for the sales team, such as the following:

[global]
    workgroup = SALES
    hosts allow = 192.168.10.255

[sales2003]
    path = /usr/local/samba/sales/sales2003/
...

This particular example would set the workgroup to SALES as well and set the IP address to allow connections only from the SALES subnet (192.168.10). In addition, it would offer shares specific to the sales department.

Figure 6-5. Using NetBIOS aliases for a Samba server

Logging Configuration Options

Occasionally, we need to find out what Samba is up to. This is especially true when Samba is performing an unexpected action or is not performing at all. To find out this information, we need to check Samba's log files to see exactly why it did what it did.

Samba log files can be as brief or verbose as you like. Here is an example of what a Samba log file looks like:

[2002/07/21 13:23:25, 3] smbd/service.c:close_cnum(514)
  maya (172.16.1.6) closed connection to service IPC$
[2002/07/21 13:23:25, 3] smbd/connection.c:yield_connection(40)
  Yielding connection to IPC$
[2002/07/21 13:23:25, 3] smbd/process.c:process_smb(615)
  Transaction 923 of length 49
[2002/07/21 13:23:25, 3] smbd/process.c:switch_message(448)
  switch message SMBread (pid 467)
[2002/07/21 13:23:25, 3] lib/doscalls.c:dos_ChDir(336)
  dos_ChDir to /home/samba
[2002/07/21 13:23:25, 3] smbd/reply.c:reply_read(2199)
  read fnum=4207 num=2820 nread=2820
[2002/07/21 13:23:25, 3] smbd/process.c:process_smb(615)
  Transaction 924 of length 55
[2002/07/21 13:23:25, 3] smbd/process.c:switch_message(448)
  switch message SMBreadbraw (pid 467)
[2002/07/21 13:23:25, 3] smbd/reply.c:reply_readbraw(2053)
  readbraw fnum=4207 start=130820 max=1276 min=0 nread=1276
[2002/07/21 13:23:25, 3] smbd/process.c:process_smb(615)
  Transaction 925 of length 55
[2002/07/21 13:23:25, 3] smbd/process.c:switch_message(448)
  switch message SMBreadbraw (pid 467)

Much of this information is of use only to Samba programmers. However, we will go over the meaning of some of these entries in more detail in Chapter 12.

Samba contains six options that allow users to describe how and where logging information should be written. Each of these are global options and cannot appear inside a share definition. Here is an example of some logging options that we are adding to our configuration file:

[global]
    log level = 2
    log file = /var/log/samba.log.%m
    max log size = 50
    debug timestamp = yes

Here, we've added a custom log file that reports information up to debug level 2. This is a relatively light debugging level. The logging level ranges from 1 to 10, where level 1 provides only a small amount of information and level 10 provides a plethora of low-level information. Levels 2 or 3 will provide us with useful debugging information without wasting disk space on our server. In practice, you should avoid using log levels greater than 3 unless you are working on the Samba source code.

The logging file is located in the /var/log directory thanks to the log file configuration option. However, we can use variable substitution to create log files specifically for individual users or clients, such as with the %m variable in the following line:

log file = /usr/local/logs/samba.log.%m

Isolating the log messages can be invaluable in tracking down a network error if you know the problem is coming from a specific client system or user.

We've added a precaution to the log files: no one log file can exceed 50 KB in size, as specified by the max log size option. If a log file exceeds this size, the contents are moved to a file with the same name but with the suffix .old appended. If the .old file already exists, it is overwritten and its contents are lost. The original file is cleared, waiting to receive new logging information. This prevents the hard drive from being overwhelmed with Samba log files during the life of the Samba daemons.

We have decided to write the timestamps of the messages in the logs with the debug timestamp option, which is the default behavior. This will place a timestamp in each message written to the logging file. If we were not interested in this information, we could specify no for this option instead.

Using syslog

If you wish to use the system logger (syslog ) in addition to or in place of the standard Samba logging file, Samba provides options for this as well. However, to use syslog, the first thing you will have to do is make sure that Samba was built with the configure --with-syslog option. See Chapter 2 for more information on configuring and compiling Samba. See Appendix E for more information about the --with-syslog option.

Once that is done, you will need to configure your /etc/syslog.conf to accept logging information from Samba. If there is not already a daemon.* entry in the /etc/syslog.conf file, add the following:

daemon.*        /var/log/daemon.log

This specifies that any logging information from system daemons will be stored in the /var/log/daemon.log file. This is where the Samba information will be stored as well. From there, you can set a value for the syslog parameter in your Samba configuration file to specify which logging messages are to be sent to syslog. Only messages that have debug levels lower than the value of the syslog parameter will be sent to syslog. For example, setting the following:

syslog = 3

specifies that any logging messages with a level of 2 or below will be sent to both syslog and the Samba logging files. (The mappings to syslog priorities are described in the upcoming section "syslog.") To continue the example, let's assume that we have set the log level option to 4. Logging messages with levels of 2 and 1 will be sent to both syslog and the Samba logging files, and messages with a level of 3 or 4 will be sent to the Samba logging files, but not to syslog. If the syslog value exceeds the log level value, nothing will be sent to syslog.

If you want to specify that messages be sent only to syslog—and not to the standard Samba logging files—you can place this option in the configuration file:

syslog only = yes

If this is the case, any logging information above the number specified in the syslog option will be discarded, as with the log level option.

Logging Configuration Options

Table 6-8 lists each logging configuration option that Samba can use.

Table 6-8. Logging configuration options

Option

Parameters

Function

Default

Scope

log file

string (name of file)

Name of the log file that Samba is to use. Works with all variables.

Specified in Samba makefile

Global

log level

(debug level)

numeric (0-10)

Amount of log/debug messages that are sent to the log file. 0 is none; 3 is considerable.

1

Global

max log size

numeric (size in KB)

Maximum size of log file.

5000

Global

debug timestamp (timestamp logs)

boolean

If no, doesn't timestamp logs, making them easier to read during heavy debugging.

yes

Global

syslog

numeric (0-10)

Level of messages sent to syslog. Those levels below syslog level will be sent to the system logger.

1

Global

syslog only

boolean

If yes, uses syslog entirely and sends no output to the Samba log files.

no

Global


Footnotes

[1] Depending on your system, this file might not be /etc/printcap. You can use the testparm command that comes with Samba to dump the parameter definitions and determine the value of the printcap name configuration option. The value assigned to it is the default value chosen when Samba was configured and compiled, which should be correct.

[2] We are referring here to the window that opens when a printer icon in the Printers control panel is double-clicked.


TOC