Advanced Linux Networking

Configuring Samba as a domain controller, WINS server, and so on is often desirable, but many Samba servers don't need to be configured as such. The most common use for Samba is as a file server. Configuring Samba in this way entails creating file shares, which follow the [global] section of smb.conf . You can define a basic file share in just a handful of lines. There are various additional options that can be quite powerful, which you may want to add to these lines.

Creating a File Share

A basic Samba file share looks like this:

[sample] path = /home/samba/shared-dir browseable = Yes read only = No

This definition creates a share called [sample] ”it appears by the name SAMPLE in Windows browse lists such as that shown in Figure 7.2. The share corresponds to the /home/samba/shared-dir directory on the computer; users who browse to the [sample] share will access files in that directory. The browseable = Yes line isn't strictly necessary, since it restates the default setting. It causes the share to appear in browse lists. (You can remove a share from browse lists by setting browseable = No , but those who know of its existence can access it by entering its name directly in the Address line of a Windows file browser.) By default, Samba creates read-only shares ” clients can read files in the shares but not write to them. To make a share read/write, you should include the read only = No parameter, or one of its synonyms, writeable = Yes or write ok = Yes . Linux's ownership and permissions rules still apply to files in the share, although you can use Samba features to alter matters, as described shortly in "Configuring Ownership and Permissions."

Many networks use a Samba server to provide file storage space for users' documents. Used in this way, a special shortcut share is particularly helpful. This is the [ homes ] share. When you include a share definition using the heading of [homes] , Samba treats things a bit differently:

• You don't need to include a path parameter. Instead, Samba uses the home directory of the user who logs into the share.

• The share appears in browse lists under the user's own name (such as rodsmith in Figure 7.2). If you set the browseable = No parameter, this suppresses the appearance of a share called HOMES in browse lists, but it doesn't suppress the username-based share name.

Most Linux distributions include a [homes] share definition in their default smb.conf files. Therefore, even if you don't define any shares yourself, you'll have a Samba server configuration suitable for many common uses. (You'll still need to set your workgroup name and, in all probability, adjust your password encryption policies, as described earlier.)

You can define as many file shares as you like, including a mix of ordinary shares and a [homes] share. There's no point in defining multiple [homes] shares, though. If you find yourself including some parameter in all your shares, you might consider moving that parameter to the [global] section. Doing this will make that option the default for all your shares.

Setting Windows Filename Options

Linux and Windows have different filename requirements. If your network still has DOS clients, DOS has still another set of filename conventions. These facts make Samba's job a difficult one, because it has to provide a way to make a Linux filesystem look like a DOS or Windows filesystem.

Perhaps the most important of the differences between Linux and Windows filename handling lies in case sensitivity. Linux treats its filenames in a case-sensitive manner ” FILE.TXT , file.txt , and File.txt are all treated differently, so all three can exist in a single directory without conflict. Linux's case-sensitivity also means that a user must enter precisely the correct case when accessing a file. Windows, by contrast, is case-retentive, which means that it retains case in filenames, but it doesn't use case when matching filenames. Therefore, two filenames that differ only in case cannot exist in a single directory. DOS uses a completely case-insensitive system; all filenames are converted to uppercase, even if the user enters a mixed-case or lowercase filename.

The case sensitive Samba parameter controls whether it treats filenames in a case-sensitive manner or not. This parameter defaults to No , which works well with both Windows and DOS clients. When a client requests a file of a particular name, Samba checks for a name that differs from the original only in case if the original doesn't match, thus emulating Windows' behavior. The drawback is that this causes a slight performance hit. If you must have the very best performance possible, you can try setting case sensitive = Yes , but there's a good chance that at least some Windows programs will misbehave when Samba is so configured. You might also want to use this setting if you intend to use Samba with clients that are case sensitive, such as Linux.

The preserve case and short preserve case parameters define whether Samba retains case on filenames. When set to Yes (the default), Samba creates files using precisely the case specified by the client. When set to No , Samba converts filenames' case to uppercase or lowercase, depending on the value of default case , which defaults to Lower but can be set to Upper . The preserve case parameter affects the case of all files, but this setting is overridden by short preserve case for short filenames ”those that conform to the length limits of DOS (eight characters plus a 3-character extension, often called 8.3 filenames ). You might want to set short preserve case = No if your network hosts a large number of DOS clients. Doing this will result in lowercase filenames stored on the Linux server, although the DOS clients will see them as being uppercase.

One SMB/CIFS feature is that it supports the delivery of 8.3 filenames even for files with long names . This allows DOS and 16-bit Windows programs (which can handle only 8.3 filenames) to access files with long filenames. Windows servers store 8.3 filenames with their files, so they can deliver these filenames without trouble. Linux, however, doesn't store 8.3 filenames, so Samba must create them dynamically. Using the default mangled names = Yes setting enables this behavior; setting mangled names = No disables the creation of 8.3 filenames.

Configuring Ownership and Permissions

Linux security is built around ownership and UNIX-style permissions. SMB/CIFS, though, doesn't use these features in the same way that Linux does. SMB/CIFS permits logins to a server using a username and password, so by default Samba uses Linux user accounts for this purpose. With cleartext passwords, Samba uses the standard Linux authentication mechanisms, but with encrypted passwords, Samba authenticates users itself. Either way, Samba provides features that allow you to alter the username associated with a login. Specifically , the force user and force group parameters allow you to treat all accesses to a share as if they came from some other user or group, respectively. For instance, consider the following share definition:

[jekyl] path = /home/samba/jekyl read only = No force user = hyde

Any user who accesses this share will do so as the Linux user hyde . For instance, if muriel logs in and creates a file, that file will be owned by hyde . If henry logs in and creates a file, that file will also be owned by hyde . Either user can read the others' files via Samba in this directory, even if neither can read the other's files directly from a regular login to Linux, and even if neither can read the /home/samba/jekyl directory from a regular Linux login. Anybody who uses this share can read any files within it that are readable by hyde . The force group parameter works in a similar way, but it affects the group associations of files rather than the ownership.

NOTE

The force user and force group parameters can greatly simplify certain types of Samba configurations. For instance, if you want to create a Samba share in which individuals may freely exchange documents, you can use force user to ensure that all the files created in that directory have a single Linux owner, and that anybody using the share can read the files. You can create an account specifically for this purpose, and use Linux permissions that are as lax or restrictive as you deem necessary on the Linux side. If you need to restrict the users who may access the share from Samba, you can do so with additional parameters, discussed shortly in the section "Limiting Access to Shares."

Whereas Linux and SMB/CIFS both support usernames, Linux permissions don't map quite directly onto any SMB/CIFS concepts. When Samba supports DOS or Windows 9 x /Me clients, the client doesn't understand these concepts at all. Therefore, you're free to specify the permissions of files created by clients, using the create mask and directory mask parameters, which affect the permissions on files and directories, respectively. Both parameters take 3- or 4-digit octal values that represent the permission bits that may be set in a file that Samba creates. The default value for create mask is 0744 , and for directory mask is 0755 . Both values allow read/write access to the owner and read-only access to the file's group and the world. You can adjust these values as you see fit, but be aware that they interact with the storage of DOS-style archive, system, and hidden bits.

DOS and Windows filesystems support three attribute bits that Linux filesystems don't support. Therefore, Samba can map these bits onto execute bits. You can control whether or not this mapping occurs by using appropriate Samba parameters. Specifically:

• map archive ” If set to Yes (the default), this parameter maps the DOS archive bit onto the Linux user execute bit. DOS and Windows clients set this bit on new files, and clear it when the file has been backed up through appropriate backup software. For this reason, with the default create mask , new files created by Samba clients appear to be executable by their owners if viewed in Linux.

• map system ” If set to Yes , this parameter causes the DOS system bit to be mapped to the Linux group execute bit. The default value is No , so this mapping doesn't occur. DOS and Windows mark a few critical system files with this bit, but such files are unlikely to be stored on Samba servers.

• map hidden ” If set to Yes , this parameter maps the DOS hidden bit to the Linux world execute bit. The default value is No . Many DOS and Windows programs hide files that have their hidden bits set from users; the files are still accessible, but they don't show up in directory listings or file selection dialog boxes.

NOTE

The default create mask value mirrors the settings of the mapping parameters. If you want to change the map system or map hidden parameter defaults, you must also change the create mask value by adding 1 to the next -to-last or last digit, respectively.

Windows NT/2000/XP uses a more sophisticated internal security model than does Windows 9 x /Me. Specifically, Windows NT/2000/XP supports Access Control Lists (ACLs), which allow you to specify the level of access particular users may have to a file. Samba allows you to map the Linux user, group, and world permissions onto Windows ACLs, so that you can adjust read and write permissions from Windows NT/2000/XP systems. This feature is controlled through the nt acl support parameter, which defaults to Yes . You'd change this parameter to No if you want to disable an NT/2000/XP system's ability to modify Linux permissions on a fine-grained basis.

NOTE

Limiting Access to Shares

Samba provides many means to control access to itself. For instance, the hosts allow and hosts deny options were mentioned earlier, in the section "Setting Security Options," and of course Samba uses an authentication model in which users provide a username and password. (It's possible to configure Samba to perform by-share authentication rather than by-user authentication, by setting the security = Share parameter. This setting tends to be tricky to configure properly, though, because it maps poorly onto Linux's underlying security scheme.) Samba also provides several mechanisms for controlling access to individual shares. Of particular interest are the valid users and invalid users parameters, which provide lists of users who may or may not use the share, respectively. If you use valid users , you must present a space-separated list of users who are allowed to access the share; all others are denied access. You can use invalid users to blacklist certain users to keep them out of a share, even if they have access to other shares.

Another pair of access-control parameters are write list and read list . These parameters allow you to override a share's read-only or read/write settings for individual users. For instance, you might want to create a share that contains program files to which most users should not be able to write, so you'd create the share read-only. You might want to give one or two users full read/write access to the share to allow them to upgrade software, though. You'd use write list to specify these users.

As an example of these parameters, consider the following share:

[control] path = /home/samba/control read only = Yes invalid users = thomas susan write list = gertrude henry

This share is read-only for most users, but two users ( thomas and susan ) are denied access entirely, and two others ( gertrude and henry ) are given read/write access to the share.