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 StructureLet'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 commasAn 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 CapitalizationCapitalization 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 continuationYou 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 CommentsYou 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.
6.1.1.5 Changes at runtimeYou 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.
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 VariablesBecause 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
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
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. |