SAMBA

Due to the incredibly large number of Microsoft applications, it is almost expected that a server be able to provide some kind of access to the Windows machines. If you have TCP/IP running on your machines, then you have connectivity from your Windows machines to a Linux server through telnet and ftp. However, you do have access to the file and print services provided by an NT server. Or do you?

The network protocol used by Windows NT networks is the Session Message Block or SMB. This is the same protocol that Microsoft has been using for years with their Lan Manager product. Therefore, anything that can access a Lan Manager server, will be able to access an NT server.

Recently, Linux has been able to support SMBs through the SAMBA package. This not only means that a Linux machine can provide file and print service to Windows machines, but they can also provide the same services to a Linux machine.

Because Linux and Windows have a different understanding of security and approach it in a different way, you have to be careful in what you make available. However, in keeping with the UNIX tradition of configurability, you have a wide range of choices on how to configure your system. The are many different options to define your security as well as what you make available and how.

SAMBA has both a server and a client component and as one might expect the client side is fairly straightforward. Fortunately, to get the server side working, you don't have to do too much. On the other hand, there are a lot of options that you can use to configure the system to fit your needs.

There are five primary files that SAMBA uses. The SMB daemon is smbd, which is the SMB server. This is what is what is providing the services. The client side is the program smbclient. This is what allows you to access Windows machines from your Linux workstations and servers.

The nmbd program is the NetBIOS name server daemon.

SAMBAs configuration file is smb.conf which you should find in the /etc directory. This file has a format that is similar to Windows INI files, in that it is broken up into section. Each section has a particular function. For example, the section that describe the printer configuration would start like this:

[Printers]

Like the Windows ini files, smb.conf is line based, with one option per line. In general, the configuration options have the format:

option = value

Finally, there is the testpararm program, which is used to test the SAMBA configuration.

The first section of smb.conf sets up the global configuration and is called, [global]. The default looks something like this:

[global]
   printing = bsd
   printcap name = /etc/printcap
   load printers = yes
;  Uncomment this if you want a guest account
;  guest  account = pcguest
   log file = /var/log/samba-log.%m
   lock directory = /var/lock/samba
   share modes = yes

The printing option determines how the printer status information is interpreted. The default is bsd, which is the most common used. For information on the others, see the smbd man-page.

The printcap name option defines the name of the printcap file. In this example, we are using the standard printcap file. If you use a different printing option, the printcap file could be different.

The load printers options determines whether or not all the printers listed in printcap are loaded for browsing.

The guest account is used for enabling access somewhat anonymously. By default this is disabled, as in this example. To enable it, uncomment the lines by removing the semi-colons. The actual effects of this account we'll get to later

The log file option defines what file to write diagnostic messages and other information. Note that there is a %m at the end of the file. This variable is the netbios name of the client machine. This can be used in other places, as well. In this case, there will be one log file for each client.

The lock directory options define the directory where lock files are put. The share modes option is used to enable/disable the "share modes" when files are opened. This allows clients to get exclusive read or write of files. Since this is something not directly supported by Linux, smbd uses locks in the lock directory.

There are primarily two types of services that you access via smb: file and print services. File services are directories that have been made available. Normally, all sub-directories under the exported or shared directory are accessible. Lets assume that we want to make the users home directory available. To do this we share them. The section might look like this:

[home_dirs]
   comment = Home Directories
   path=/home
   read only = no

Here the section name is [home_dirs] but we specify the path of /home. So when we are on Windows machine (e.g. Windows 98) we would see this directory as homes. (Since that is the share name) In this example, we specified the directory as not being read only. This would be the same as specifying the directory as writable. (Note that the section [homes] is a special section, which we will get to shortly)

We can also define access for specific users. For example, if I wanted to give each user access to their own home directory and no other, I could create shares for each directory. So, the share for jimmo's home directory might be:

   [jimmo]
   comment = Jimmo's Home Directory
   path=/home/jimmo
   valid users = jimmo
   writable  = yes

Here we added the valid users option, which, as one might expect, indicates which users can have access to this directory. Since the only user specified is jimmo, only I can access this directory. Note that if I were to add the option browseable = no and use the Windows browser (not the same as a Web browser), I would not not be able to see the share, even though I could explicitely connect to it. If it were browseable, but I was not in the list of valid users, I could see it, but would then be asked for your password. Since I was not in the list of valid users, no password I enter would work. (At least this is the behavior from Windows 98)

Setting up a printer is the same basic process. We define a resource that we share and specify what access is permitted. An example, might look like this:

[deskjet]
   comment = Deskjet on Junior
   path = /tmp
   printer = lp
   public = no
   writable = no
printable = yes

Here the path is not the path to the resource, but rather a world-writable directory that has the sticky-bit set. This is the spool directory and allows us to write to it, but no one can remove our files. In this example, I just used /tmp. However, you could create a special directory for this purpose, for example /var/spool/public. We could also specify a list of valid users for this printer.

The [homes] section is used to connect to users home directories on the fly, without having to create individual shares as I suggested above. When you try to connect to a service with the same name as a user, smbd will do one of two things. If there really is a service of that name, smbd will connect to it. If there is no such service, smbd will treat it like a user name and look for that users home directory in the passwd file. Next, smbd will create a "virtual" share by making an internal copy of the [homes] section, but using the users name as the share name. An example [homes] section might look like this:

[homes]
    comment = Home Directories
    browseable = no
    read only = no
    create mode = 0750

Note that there is no path specified in this example. This is because, the path for the share is the home directory specified in /etc/passwd. However, we could have specified a path and although the name of the share would be that of the user, the path would be whatever we specified.

We could still specify the path using the %S variable. This is the name of the current service, which, in this case, is the name of the current user. This could be done like this:

path=/data/pcusers/%S

This might be useful if we give the users one home directory when accessing from a PC and another home directory when directly logging into the Linux machine.

The [printers] section behaves similarly to the [homes] section. If you try to connect to a service, smbd will first look for a service with the specific name. If it finds one, that's what it will connect to. If there is none, it will look through the printcap file. If there is a matching printer name in the printcap file, this is the one that will get used. Otherwise, an error is returned. An example, [printers] might look like this:

[printers]
   path = /var/spool/public
   writable = no
   public = yes
   printable = yes

Note that this service is defined as not writable. However, it is defined as being printable. This is necessary for correct operation.

To a limited extent, your Linux machine can be configured as an SMB client. This is done using the smbclient program. This provides a functionality similar to ftp in that you can copy files from one machine to another. The general syntax would be:

smbclient \\\\server\\service</P>

Note that there are twice as many back-slashes as normal. This is because the shell will first try to interpret the slashes, so we have to escape each one with a back slash. Alternatively, we could enclose the complete service name inside of single quotes, like this:

smbclient \\server\service

At this point we have configured SAMBA to allow us to connect from a Windows machine, or any other machine that understand SMBs. The good news is that's not all. SAMBA has many more configuration options. The bad news is that we don't have space to cover them all. The first place to start looking is the smbd and smb.conf man-pages. These both go into a lot of detail about how you can configure SAMBA.

There are a few configuration options that I would like to address. The first set have to do with security. SAMBA allows you to specify access based on both user (as described above) and by host. This is done with the allow hosts option. Like the valid user list, the list of authorized hosts is comma delimited values. In this case, the IP address or host name. You can globally define access by including the list in the [global] section or you can define it for specific services.

Using the IP address, you could specify entire networks by simply including just the network portion of the IP address. For example:

hosts allow = 192.168

We could also exclude specific addresses. For example:

hosts allow = 192.168 EXCEPT 192.168.42

This allows access from the class B net 192.168, but denies access from any machine on the class C network 192.168.42.

Supplemental to hosts allow is hosts deny, which, as you might guess, is used to specifically deny access. This has the same syntax as hosts allow. Note that access defined here is the first phase. If you deny access to a particular machine, that's it. They cant get any further. However, if you allow access they can still be restricted at the user level.

You could also use a list of invalid users to restrict access. For example, you could define root as an invalid user. This would prevent root from accessing any service, which is helpful if you leave a security hole open. You can also include users that are part of Linux group by preceeding that name with an at-sign@. For example, to keep root and members of the adm group out, the line might look like this:

invalid users = root,@adm

Note that any place that you have a list of users, you can use the @ construct to include group names.

On some cases, there are directories that you don't want users to have access to, although you allow them access to their parent. This is first accomplished by setting the permissions on the directory. However, this is not always a valid alternative. For example, you may not want users to have access to the /dev directory, but you cant change the permissions. However, you can use the don't descend option to prevent them from accessing through SAMBA. This options takes a common separated list. For example:

don't descend = /proc,/dev

The guest ok option (and its synonym public) are used to give access to services without requiring a password. Once connected, access will be the same as the guest account. This is a boolean option with a default of no.

Another useful option give you the ability to define a configuration file based on the user or machine that is connecting. This is done with the config file option, which appears in the global section. Setting the configuration file based on the machine name might look like this:

config file = /etc/smb.conf.%m

When you connect, smbd will look for a matching configuration file. If it finds one, it will reload the new one. If there is no match, the original configuration stays in effect. This is useful for defining a configuration for some machines (or users) and not for others.

To make management easier, especially if you have a lot of shares for a lot of different machines, using the include option you can have one main configuration file and include the configuration files for specific machines and users. By using variable substitution, you can create files based on machine or user name and then include them. For example, to include files based on machine name, the directive might look like this:

include /etc/smb.com.%m

Also helpful to manage your services is the copy option, which allows you to copy services (what else?). This way you can create services with different names but have the same basic configuration options. The syntax is simply:

copy = service

Where service is the name of the service that you want to copy.

Two things to note. First, the "original" must appear first in the configuration file. Second, you can change parameters in the copy and they will override anything in the original. This would be useful to create a kind of template, which , for example, defines the access permissions, but each service would define its own path.

The guest account option is used in conjunction with the guest ok and defines a user name that will be used during the connection. This user must exist in the password file, but it is safest that they don't have a valid login (i.e. have /bin/false as their shell).

You can limit access further by defining a service as guest only. This means that although a user has a valid password to access a particular service, they are limited to whatever the guest account has access to.

If you have been working with UNIX and DOS/Windows machines at the same time, you probably have experienced something that is affectionately called file name mangling. This results from the fact that UNIX file names can be longer than the standard DOS 8.3 names.

You can configure Samba so that it will " mangling" the DOS names for you, so they are accessible by DOS and Windows. (Note that you don't need to do this with Win98 or WinNT). Depending on what your needs are, you can mangle names in different ways.

One difference between UNIX and DOS file names that always give me trouble is that DOS doesn't see a difference between upper a lowercase. Therefore, the files LETTER.TXT and letter.txt are the same in DOSs eyes. The mangled names option (yes/no) is used to turn this functionality on and off. If enabled (yes), names are mangled according to the rules you define. Otherwise, they are invisible. (See the sbm.conf man-page for details on how names are mangled.)

To mangle the name correctly, you first need to define a default case with the default case option which can either be upper or lower. Using the mangle case option (yes/no) you tell smbd to mangle the characters that are not the default case.

You can also set the case sensitive option (yes/no), which control whether the name are case sensitive or not. If not (the default), smbd must do a name search to access the appropriate file. When you create a new file, the preserve case option (yes/no) defines how smbd will behave. The default is no.

The mangled map option allows you to define specific changes to files. This is useful when mangling of file names is not the best choice. The classic example is Web pages. On UNIX machines, these normally have the extension .html. However, this does not fit with the 8.3 convention of DOS file names. Normally, DOS would come up with some weird, mangled name. You can keep the name somewhat normal by using a mangled map. For example:

mangled map = (*.html *.htm)

This means that whenever smbd files a file with an extension of .html it will automatically convert the extention to .htm.

The good and bad news is that's not it. The smb.conf file contains dozens more options. Many of which you require a very strong imagination to come up with uses for. However, this is in keeping with the Linux tradition that you are only limited by your imagination.

Table - Key SAMBA files

User Comments: