General Samba Configuration

There are two aspects to Samba configuration: general configuration options and configurations for specific Samba shares (directories or printers that Samba serves to clients ). Configuring the global options correctly is particularly important, because problems in these settings can cause the server to be completely inaccessible. The global settings also affect Samba features that aren't directly related to file and printer sharing, such as how Samba locates other systems on a NetBIOS network.

The Samba Configuration File

Samba uses a file called smb.conf for its configuration. Most Linux distributions place this file in /etc , /etc/samba , or /etc/samba.d . Like many Linux configuration files, this file uses a pound sign ( # ) as a comment character. Uncommented lines are broken into separate share definitions, which are identified by a name in square brackets:

 [  share-name  ] 

Lines following the share name control that share's settings ”the directory Samba associates with the share, how filenames are handled, and so on. Global configuration options appear in a section that looks like a share definition, but it's not. This is the [global] section of the smb.conf file. Settings in this section may be defaults that carry over to other shares if they're not overridden, or they may be settings that are meaningful only in the [global] section itself.

Individual settings are controlled through parameters, which in Samba are lines that take the following form:

  parameter  =  Value  

Samba is very flexible in whether parameters and values are in upper- or lowercase, but by convention I list most parameters in all lowercase and most values with initial capitalization. A few values (such as those that refer to Linux filenames) are case-sensitive. Some values set binary features; for these, Yes , True , and 1 are synonymous, as are No , False , and .

Setting Server Identification

NetBIOS networks use names for computers and groups of computers that are independent of the computers' TCP/IP hostnames. For instance, harding.threeroomco.com could also be known by the NetBIOS name BILLY in the USPRES domain. To avoid confusion, I use all-uppercase NetBIOS names to distinguish these from TCP/IP names. The NetBIOS name space has just two levels: computer names and workgroup or domain names. (NetBIOS domains are unrelated to TCP/IP domains.) For this reason, Samba needs some way to specify both a NetBIOS name and a NetBIOS workgroup or domain name.

NOTE

NetBIOS workgroups and domains are very similar. A workgroup is a collection of computers with a common workgroup name. A domain is a workgroup that features a computer (the domain controller ) that provides centralized authentication and other services. Domains can also be spread across multiple network segments, which is more difficult to accomplish with workgroups. Samba can take on the role of a domain controller, as described shortly in "Becoming a Domain Controller."

You specify the workgroup or domain name with the workgroup parameter, thus:

 workgroup = USPRES 

This tells the computer that it's a member of the USPRES workgroup. The system can still communicate with members of other workgroups, but some functions, such as browsing a network in Windows, rely upon the workgroup name. Therefore, if you set the workgroup name incorrectly, your Samba server won't show up in Windows' Network Neighborhood or My Network Places browsers. This is a common problem with initial Samba configuration.

By default, Samba uses the first component of the computer's TCP/IP hostname as its NetBIOS name. For instance, on harding.threeroomco.com , Samba uses the NetBIOS name HARDING . You can override this setting with the netbios name parameter. You can also use the netbios aliases parameter to set the computer to respond to multiple NetBIOS names. For instance, the following parameters tell the computer to respond to both BILLY and WILLIAM :

 netbios name = BILLY netbios aliases = WILLIAM 

TIP

It's usually best to use the same TCP/IP and NetBIOS names for a computer. This will avoid confusion over what the computer is called. If your computer's TCP/IP hostname is set strangely or incorrectly, though, the NetBIOS name will inherit this peculiarity. Therefore, it's a good idea to use netbios name to set the name explicitly to whatever the TCP/IP hostname should be.

Setting Security Options

Early SMB/CIFS implementations sent passwords in cleartext, meaning that they weren't encrypted. This made the passwords vulnerable to detection by other computers on some types of local networks, or if SMB/CIFS sessions were passed through routers. Subsequent versions of SMB/CIFS therefore added password encryption technologies. The problem is that the encryption methods used by SMB/CIFS are incompatible with those generally used on Linux systems for managing local users' passwords. It's impossible to take an encrypted SMB/CIFS password and verify the user against the normal Linux user database. Therefore, Samba must implement its own password database to handle encrypted passwords. This database is called smbpasswd , and it's controlled through a utility of the same name.

Versions of Windows since Windows 95 OSR2 and Windows NT 4.0 SP3 use encrypted passwords by default. These systems cannot connect to a Samba server that's configured using its default cleartext passwords; one or the other must be reconfigured. In the long term , it's generally easier and safer to reconfigure Samba to accept encrypted passwords than it is to reconfigure the Windows clients to send cleartext passwords.

To enable Samba to use encrypted passwords, you use the encrypt passwords parameter, which is a binary parameter that tells the system to accept encrypted passwords. Set this parameter to Yes and Samba will begin checking for encrypted passwords in its smbpasswd file. This file must contain encrypted passwords to do any good, though. To add an encrypted password for a user, issue the following command:

 #  smbpasswd -a   username  

This adds the user username to the smbpasswd file. The utility will ask for the password (twice, to be sure you don't mistype it). The computer must already have a valid user called username , or smbpasswd won't add the name. The first time you run the command, it will complain that the smbpasswd file doesn't exist; but it will create the file automatically, so you can ignore this complaint.

Another important security feature is provided by the hosts allow and hosts deny parameters. These work much like the /etc/hosts.allow and /etc/hosts.deny files of TCP Wrappers (discussed in Chapter 4): They provide lists of hosts that are explicitly allowed to connect to the server, or that are explicitly not allowed to connect, respectively. For instance, the following parameter allows computers in the 192.168.7.0/24 network to connect, as well as the system algernon. pangaea .edu , but no others:

 hosts allow = 192.168.7. algernon.pangaea.edu 

NOTE

For most configurations, you can skip ahead to the section entitled "Serving Files with Samba." The intervening sections are of interest only if you want your Samba server to function as a NetBIOS name server, a master browser, or a domain controller. The default settings work fine on most existing networks.

Becoming a NetBIOS Name Server

NetBIOS networks require some means of name resolution. Traditionally, NetBIOS name resolution has used methods separate from TCP/IP name resolution, but today one option is to use TCP/IP name resolution. In total, four methods are available:

• TCP/IP names ” It's possible to use TCP/IP names for name resolution, and in fact Windows 2000, Windows XP, and Samba all default to this method, despite the fact that it's not strictly a NetBIOS solution.

• An lmhosts file ” Systems can record mappings of names to IP addresses in a file, typically called lmhosts , which works much like the Linux /etc/hosts file.

• Broadcasts ” Whenever a computer needs the address of another, the first system can send out a broadcast asking for the second computer's address. This approach is easy to configure and works well on small networks, but produces a lot of extraneous chatter on larger networks. Broadcasts also don't work if your network is split up into multiple segments separated by routers, unless the routers are configured to echo broadcast traffic.

• A WINS server ” A NetBIOS Name Service (NBNS) server, also called a Windows Internet Name Service (WINS) server, works much like a TCP/IP Domain Name System (DNS) server in that it translates between machine names and IP addresses for other systems.

To configure a Samba system to function as a WINS server, you must set one parameter in the [global] section of smb.conf :

 wins support = Yes 

WINS servers require no extra configuration ”at least not on the server side. When NetBIOS clients and servers come online, they register themselves with the WINS server, which maintains information on the systems. You need to tell all your systems to use the designated WINS server. In Windows, you do this from the TCP/IP Properties dialog box, as shown in Figure 7.1. If you click Use DHCP for WINS Resolution, you can have Windows obtain this information from a DHCP server. (Chapter 5 includes a discussion of how to include this information in a Linux DHCP server's configuration.)

Figure 7.1. Windows' TCP/IP Properties dialog box lets you specify a WINS server address.

To configure a Samba server to use a WINS server for NetBIOS name resolution, you need to set two smb.conf parameters: wins server and name resolve order . Give the IP address of a WINS server as the first parameter's value and one to four names for the four types of name resolution as the second parameter's value. Samba will attempt to use each of the name resolution methods specified in the order you list them. (The options host and bcast stand for normal TCP/IP resolution methods and NetBIOS broadcasts, respectively.) For instance, you might include the following parameters:

 wins server = 192.168.1.1 name resolve order = wins lmhosts host bcast 

It's important that only one system be configured as a WINS server. If you have multiple WINS servers, it's possible that name resolution will become unreliable because some systems will register with one server and others with the other server. (NetBIOS does provide for a secondary name server to improve reliability without running into this problem, but Samba doesn't support working as a secondary name server.)

Becoming a Master Browser

Earlier, I alluded to the Windows Network Neighborhood or My Network Places browsers. These are not the same as Web browsers, although Microsoft has blurred the lines in its user interfaces. Rather, these browsers allow you to browse to SMB/CIFS servers on a NetBIOS network, as shown in Figure 7.2. You can double-click on a computer name to see the SMB/CIFS shares it's defined. File shares show up as folders and printer shares as printer icons. You can double-click a file share to access its files much as you do files on the local hard disk.

Figure 7.2. Windows lets you browse computers within your domain or workgroup, or on other domains or workgroups with a presence on your local network segment.

This is all well and good from a user's point of view, but it doesn't happen without effort from the software side. Think of the situation from the point of view of the Windows network browser: How does it know what computers on the local network have shares available? NetBIOS answers this question by designating one computer on a network segment as a local master browser. This computer maintains a list of the SMB/CIFS servers on its network segment, and delivers this information, upon request, to SMB/CIFS clients. The result is that the clients need only locate the master browser, which they do by sending a broadcast message when they boot, asking for the master browser's address. When a server does this, it also registers itself with the master browser, thus keeping the master browser's list up to date.

NetBIOS domains include a second type of master browser, known as the domain master browser. This master browser communicates with local master browsers on other subnets that are part of the same domain. The master browsers exchange browse lists, thus keeping the systems coordinated, albeit with a bit of a time delay.

Domain master browsers are normally associated with domain controllers (discussed shortly). A computer must be explicitly configured to take on this role. Local master browsers, though, are designated through an election process, in which all the computers on a network segment present their credentials and the one with the highest score wins the election and becomes the local master browser. It's important that all master browsers be reliable systems; if the computers frequently crash or reboot, there'll be frequent periods during which browsing won't work on the network. It's also important that a Samba system not be too insistent about winning browser elections; certain parameters can cause Samba to repeatedly call for elections , which can cause browsing blackouts.

To configure a Samba system to become the local master browser, you must set it to participate in and win elections. To do this, you should create [global] parameters similar to the following:

 browse list = Yes local master = Yes preferred master = Yes os level = 65 

The browse list parameter causes Samba to compile a browse list, which it may then share with other systems. This parameter's default is Yes , so it can usually be omitted. The local master = Yes parameter is also the default. It causes Samba to participate in elections, but doesn't guarantee victory. The preferred master parameter defaults to No . When set to Yes , it causes the system to call an election when it starts up, and periodically thereafter if it doesn't win an election. If you have multiple Samba servers, you should set this parameter to Yes on at most one of the servers, otherwise your network will be disrupted by frequent master browser elections. Finally, the os level parameter sets the primary criterion used in master browser elections. The higher the value, the more likely the system is to win. Setting os level = 65 should win against all Windows systems through at least Windows Me and Windows 2000, but could lose against a Samba system configured with a higher value. If you don't want a Samba system to ever win the master browser election, set this parameter's value to .

Domain master browser configuration requires you to set the local master browser options to win and to set the domain master = Yes parameter. You should also configure the system as the primary domain controller, as described shortly in "Becoming a Domain Controller." As with local master browser configuration, you shouldn't configure more than one system (Samba or Windows) to become the domain master browser. If your network uses a workgroup configuration rather than a domain configuration, there's no need to set this option.

Becoming a Domain Controller

NetBIOS computers are organized into either workgroups or domains. These structures are very similar to each other, but a domain is more centralized; it uses a computer known as a domain controller to authenticate users. Rather than have every server decide whether or not to allow users access to shares, the domain controller does this job. This can greatly simplify administration of a network with several servers, particularly if users are constantly coming and going. It does, however, require additional effort to set up initially. Domains also offer additional features, such as the ability to provide network logon scripts to clients whenever users log on, and the ability to store Windows profiles, which are individualized desktop customization settings, so that these settings can move with users from one client to another. In fact, domain configuration is complex enough that I can only touch upon its broad outlines in this section.

There are two types of NetBIOS domain controllers: primary domain controllers (PDCs) and backup domain controllers (BDCs). The BDC takes over PDC functions if the PDC system crashes or becomes inaccessible. Samba handles PDC operations well, but Samba can't be used as a BDC.

To configure Samba to work as a PDC, you should add the following parameters to the [global] section of your smb.conf file:

 security = User encrypt passwords = Yes domain logons = Yes 

The security parameter sets Samba to process its own share-access requests by using Linux's usernames and passwords. (This is the default for Samba 2.0.0 and later.) The encrypt passwords parameter controls Samba's use of encrypted passwords, as described earlier. Domains must use encrypted passwords. The domain logons parameter is key to PDC operation; it tells Samba to accept domain logon requests and process them according to the contents of the smbpasswd file. Windows PDCs also function as domain master browsers and WINS servers, so it's best if you configure your Samba server to do the same (this was described earlier).

NOTE

You set the domain name through the workgroup parameter in smb.conf .

If your network includes Windows NT, 2000, or XP systems, you must take some additional configuration steps. First, Samba versions prior to 2.0.5 don't support Windows NT domain clients, versions prior to 2.2.0 don't support Windows 2000 domain clients, and versions prior to 2.2.1a don't support Windows XP or Windows 2000 Service Pack 2 (SP2) clients, so you must upgrade if you have an earlier version of Samba. Versions 2.2.0 and later add many new features to NT/2000 domain client support, even for Windows NT 4.0 users. Next , you need to create what's known as a trust account on Linux for each NT/2000/XP client. You can do this by issuing the following commands:

 #  groupadd -r trust  #  useradd -r -g trust -d /dev/null -s /dev/null   client   $  #  smbpasswd -a -m   client  

You only need to issue the groupadd command once; it creates a special group for the trust accounts. (In fact, you could use an existing group, but it's best to create a special group for this purpose.) The useradd command creates a special account for the NetBIOS computer CLIENT . The dollar sign ( $ ) at the end of the username is required. Finally, the smbpasswd command adds client to the smbpasswd file. You should not include the dollar sign for the username in this command. When your Windows NT/2000/XP client next tries to access the domain, it will log on using its trust account and use Samba's password database for authenticating its own users.

Domain configuration also requires changes to the way the clients are configured. This can be handled in the TCP/IP Control Panel in Windows 9 x /Me. Select the Client for Microsoft Networks item and click Properties. Windows displays the Client for Microsoft Networks Properties dialog box shown in Figure 7.3. Check the Log On to Windows NT Domain item and enter the domain name. In Windows 2000, open the System Properties dialog box by right-clicking My Computer on the desktop and choosing Properties from the resulting pop-up menu. Click the Network Identification tab, then the Properties button. When you activate the domain configuration, you'll be asked for an administrative username and password. Enter an ordinary username and password.

Figure 7.3. Changing to a domain configuration involves checking a box and entering the domain name on the Windows client.