[Chapter 4] Disk Shares
Date: 1999-11-05T21:31:52Z

| ## Using Samba Robert Eckstein, David Collier-Brown, Peter Kelly 1st Edition November 1999 1-56592-449-5, Order Number: 4495 416 pages, $34.95 Buy the hardcopy Table of Contents

| Chapter 4 |

> # 4. Disk Shares

> Contents:
> Learning the Samba Configuration File
> Special Sections
> Configuration File Options
> Server Configuration
> Disk Share Configuration
> Networking Options with Samba
> Virtual Servers
> Logging Configuration Options

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

> ## 4.1 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
>     	min print space = 2000
>     [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, Installing Samba on a Unix System.

> ### 4.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) 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, Samba Configuration Option Quick Reference, contains an alphabetical index of all the configuration options and their meanings.

> #### 4.1.1.1 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.

> #### 4.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 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.

> #### 4.1.1.3 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`.

> #### 4.1.1.4 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.

> #### 4.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 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.

> ### 4.1.2 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.

3.3 An Introduction to SMB/CIFS |  | 4.2 Special Sections

O'Reilly Home | O'Reilly Bookstores | How to Order | O'Reilly Contacts
International | About O'Reilly | Affiliated Companies

© 1999, O'Reilly & Associates, Inc.