Samba, still actively developed in order to maintain feature compatibility with the ever-changing Microsoft software, provides a framework to allow Linux machines to access Windows network resources, such as shared drives and printers. Samba not only lets Linux machines access these services, but also allows Linux to offer these same services to Windows machines. With Samba, it's possible to completely replace a Windows-based file server, a Windows print server, and even, with advanced options, replace the Primary Domain Controller (PDC). Recent versions of Samba even allow Active Directory compatibility. The open-source flexibility of Samba means that development will be able to continue, and new features will be introduced when the Windows architecture changes. More information on Samba can be found in Using Samba, Second Edition (O'Reilly), by Jay Ts, Robert Eckstein, and David Collier-Brown.
The underlying technology used in Samba is based on Server Message Blocks (SMB), which was originally developed in the early 80s by Dr. Barry Feigenbaum while he was working at IBM. Initially, IBM was actively involved with the development, but Microsoft soon took charge and heavily continued the development work. In later years, Microsoft renamed the SMB protocol to Common Internet File System (CIFS), by which it is now known. One sees the terms used interchangeably.
There is little accurate and official documentation about how CIFS functions. Unlike most other network protocols, there is no official RFC documentation, though Microsoft did submit specifications to the IETF in the 1990s that expired due to numerous inaccuracies and inconsistencies. Newer documentation attempts by Microsoft have not been as helpful to the Samba development group, due to the licensing restrictions place upon it as well as a general lack of new information.
There are a number of options available for obtaining Samba. Many distributions now come with Samba as a part of their default installation. If this is the case with your distribution, you will not necessarily need to build from source. Red Hat, Mandrake, and SuSE users may install the package from RPM, available via a number of Samba mirrors. Gentoo users need only use emerge samba to install the package, and Debian users do the same with apt-get. Other users, or those who prefer to do so, can install the Samba package from source. Often this provides the greatest amount of flexibility because of the options available at compile time.
In order to build from source, you will need to obtain the latest source tarball, found at any of the Samba mirrors listed on the main http://www.samba.org site. Once the tarball has downloaded, extract it to a directory and build the binaries using the provided configuration file.
vlager# tar xzvf samba-current.tgz vlager# cd samba-3.0.0 vlager# cd source vlager# ./configure . . . . . . vlager# make . . . vlager# make install
Once the software has compiled and installed, you will need to choose how you wish to have it run at startup. It can be run as an inetd service or as a daemon. Either way is acceptable, but running Samba from inetd may require the update of your /etc/services file. You will need to make sure that the following lines, which define the Samba protocol, are inserted:
netbios-ns 137/tcp # NETBIOS Name Service netbios-ns 137/udp netbios-dgm 138/tcp # NETBIOS Datagram Service netbios-dgm 138/udp netbios-ssn 139/tcp # NETBIOS session service netbios-ssn 139/udp microsoft-ds 445/tcp Microsoft-DS microsoft-ds 445/udp Microsoft-DS
After this has been added or confirmed, you are should add Samba to your inetd.conf file, or to your xinetd configuration. You should also check to verify that your firewall is configured to allow the necessary ports.
Alternately, if you're planning to have Samba run as a daemon process, you will need to add it to your rc startup scripts. This is different for each of the various Linux distributions, so if you're unsure of how to do this, check your distribution's documentation.
Once you've compiled or installed Samba, you now have the potentially lengthy task of configuration ahead of you. The enormous flexibility offered by Samba means that there are a number of configuration options. Fortunately, for file server functionality, the configuration is fairly straightforward. In this section, we'll cover some of the basic options and discuss how to create shared file directories. For additional information, refer to Using Samba (O'Reilly).
The easiest way to get started configuring Samba is to start with the minimal configuration and add to it. So, to start, we'll just create a workgroup, name our server, and add a simple file share.
{global}
workgroup = Brewery
netbios name = vlager
[share]
path = /home/files
comment = Some HomeBrew recipesYou can test your Samba configurations with testparm. It will parse your configuration files and point out any typos or incorrect options you've entered. At this point, it's not too likely that you'll have any mistakes, but it's still good to get to know how to use the tool.
If everything works, you can start or restart your Samba server and attempt to view your new file share. The smbclient program, which is a part of the Samba package, can be used to view file shares. In this example, we're going to look at the file shares we've just created on vlager (10.10.0.5)
client# smbclient -L 10.10.0.5
Password:
Sharename Type Comment
--------- ---- -------
share Disk Some HomeBrew recipes
client#After the successful completion of this step, we're now ready to tackle some more sophisticated configuration options, which will make Samba much more useful.
The above configuration is great if you're only interested in having an open file share, but you may have been wondering about access control. In the above example configuration, anyone can connect to the file share. This is generally not a desirable configuration on a network. It is for that reason that Samba does, in fact, have user authorization functionality.
Staring with the previous configuration file, authentication can be added by adding the following lines:
security = user encrypt passwords = yes smb passwd file = /etc/samba/private/smbpasswd username map = /etc/samba/smbusers
The first line enables user security. This means that you will need to manage the users file on the Samba server. The second line establishes that the Samba password file will be encrypted. The third and fourth lines provide the path locations for the password and user files. It isn't necessary to have a separate users file, but it is possible with Linux.
When this has been configured, you will now be required to create users on your system. The Samba suite provides smbpasswd to manage user accounts. This isn't required, because Samba can reference the users in your /etc/passwd file. However, if there are users from Microsoft environments accessing files on your new Samba server, you will need to have this file.
Creating users is pretty straightforward and is done with the smbpasswd utility.
vlager# smbpasswd -a larry
New SMB password:
Retype new SMB password:
vlager#Once the user has been created, it can be tested with either a Windows machine or a Linux machine using smbmount. After entering \\<server.ip> into the Explorer address bar, the Windows user will be presented with a dialog box, as shown in Figure 16-1.
For Linux, and other Unixes, smbmount is invoked as follows:
vlager# mount -t smbfs -o username=larry //server.ip /mnt/sambaIf everything has been successful, you will now be able to access the shared directory at /mnt/samba.
So far, we've discussed the bare minimum configuration of a Samba server. This is great for those who just want to quickly get something on the network. In order to get a little bit more out of Samba, we'll now take a look at some additional options.
The Samba server offers some additional security, which can prove very useful in large networks. IP-based access control is available with what are likely very familiar commands:
hosts allow = 10.10. hosts.deny = any
This will allow connections only from the 10.10 network. The Samba IP access control follows the same logic used by tcpwrappers. You can either explicitly allow or deny IP addresses or ranges. This option is really convenient because it can be used at the global or the share level, meaning that you can have a list of IP addresses that are either allowed or banned from all of your server's file shares, or you can break it down so that only certain IP addresses have access to certain shared directories. This type of granular access is not even offered by Windows itself!
The Samba server is also flexible as to which interface it will bind to. By default, it will bind to all available interfaces, including loopback. To remove any unwanted access, such as binding Samba to the external interface of a dual-homed machine, the bind interface can be specified.
bind interfaces only = True interfaces = eth1 10.10.0.4
This will make sure that Samba listens only on the specified interface on the provided IP address. If you are concerned about security, it is best to restrict access at the application level, rather than rely on a firewall to protect you.
Another type of access control offered by Samba is the ability to mark a shared directory as browsable. If it is browsable, it will be immediately visible and users will be able to peruse its contents. The command to manipulate this feature is:
browsable = yes|no
If you would like to be able to give people access to certain files, perhaps by sending them a URI pointing to a specific file, while not wanting them to be able to see all the files in the directory, this option should be set to no. A URI of this kind should look familiar; for example, \\vlager.vbrew.com\recipe\secret.txt would work for Windows users, while for Unix users, one might use smb://vlager.vbrew.com/recipe/secret.txt. In either case, the user would be allowed access to just the secret.txt file only. For most purposes it is set to yes, as the Samba server tends to be more functional when users can browse the filesystem.
Along the same lines, shared directories can be marked as to whether or not they're publicly available. If a folder is not public, even with a specific URI a user cannot access a file. It is important to note, though, that anyone with a Samba account will be able to view folders that are labeled public.
public = yes|no
Having granted viewing rights to a user, the Samba administrator can also choose whether or not shared directories are writable. This is done with the writable command:
writable = yes|no
When this option is set to no, nothing can be written to the directory.
Should you wish to have a fairly open Samba server for something like an open, browsable documentation server, you might wish to enable the Samba guest account. This is easily done with the guest directive:
guest ok = yes|no
Finally, one of the most useful features of Samba is that it allows access to shared directories to be controlled with user access lists. The easiest way to accomplish this is by using the valid users option.
valid users = sharon paul charlie pat
You can also simplify this by using an already defined group from your /etc/group file:
valid users = @brewers
The at sign (@) tells Samba that the brewers value is the group name. Having controlled access to the point where you're comfortable, you're probably interested in making sure that your configuration is working. One of the best ways to see what's happening with Samba is through its excellent logging capabilities.
Using the log functions with Samba is quite simple. There are a number of additional modifiers that can be added to expand on the logging capabilities. The most basic logging can be accomplished with the following command:
log file = /var/log/samba.log
This will provide basic logging of all Samba transactions to the file specified. However, in some instances, these logfiles can be a bit unwieldy if many machines are accessing the Samba server. To make the logging easier to sift through, Samba offers the ability to log by each host that connects. Enabling this functionality requires only the following addition:
log file = /var/log/samba.log.%m
As with most logging functions on Linux, the administrator has the ability to configure how much logging occurs. In Samba, these log levels follow a 0 to 10 scale, starting from light to intensive logging. For most uses, the Samba documentation suggests using log level 2, which provides a good amount of information for debugging, without overdoing it. Levels 3 and higher are designed for Samba programmers and aren't for normal usage. To specify the log level in your Samba configuration file, add this line:
log level = 2
If you have a fairly busy server, it is likely that your logfiles will grow very quickly. For this reason, Samba offers a maximum size logfile directive.
max log size = 75
This example sets the maximum logfile size to 75 KB. When the logfile reaches this size, it is automatically renamed by adding .old to the file, and a new logfile is created. When the new logfile reaches 75 KB, the previous .old file is overwritten. If you have logfile retention requirements in your environment, make sure that you have a script that automatically archives your Samba logs.
In addition to its own logging capabilities, Samba, when compiled with the --with-syslog option, will also use the system logger. In situations when administrators have automated log-watching tools, like swatch, this can be more useful. To have Samba use syslog, just add the following line to your Samba configuration file:
syslog = 2
This will send all of Samba's Level 2 logging detail to the syslogfile. If you're happy with this, and would like to use the syslog exclusively, specify the following in your smb.conf:
syslog only = yes
Samba is fully functional as a Windows print server, enabling users to connect and print, and even download relevant print drivers. According to the Samba team, this was one of the biggest interoperability issues they faced because of complexities with the Windows print job queuing system. There are a number of ways to configure Samba for printing, but the two most common are the traditional BSD printing, and more recent CUPS.
The older, traditional method of printing is the BSD print system which is based around the RFC 1179 framework. It uses commands such as lpr that most Unix administrators are familiar with. Samba works well with this environment, and it is easily configured. The basic configuration to enable BSD printing looks like this:
[global] printing = bsd load printers = yes [printers] path = /var/spool/samba printable = yes public = yes writable = no
At this point, if you're thinking that this seems really simplistic, it is! This is thanks to the fact that Samba makes a great number of assumptions with its default configuration. To see what the configuration really looks like, you can use the testparm program:
ticktock samba # testparm -s -v |egrep "(lp|print|port|driver|spool|\[)"
Processing section "[printers]"
[global]
smb ports = 445 139
nt pipe support = Yes
nt status support = Yes
lpq cache time = 10
load printers = Yes
printcap name = /etc/printcap
disable spoolss = No
enumports command =
addprinter command =
deleteprinter command =
show add printer wizard = Yes
os2 driver map =
wins support = No
printer admin =
nt acl support = Yes
min print space = 0
max reported print jobs = 0
max print jobs = 1000
printable = No
printing = bsd
print command = lpr -r -P'%p' %s
lpq command = lpq -P'%p'
lprm command = lprm -P'%p' %j
lppause command =
lpresume command =
printer name =
use client driver = No
[printers]
path = /var/spool/samba
printable = YesThis is the point at which you can readjust some of the default options that might not be right for your system. One item to consider is whether the lp commands are in your default path. You can also add anything to the lp command lines that you see fit.
A sample /etc/printcap file is also included here. As all systems are different, this configuration file may not work properly for you, but it is provided to give you an idea of the configuration format. For more detailed information, check the printcap manpages.
# /etc/printcap: printer capability database. /lp|Generic dot-matrix printer entry :lp=/dev/lp1 :sd=/var/spool/lpd/lp :af=/var/log/lp-acct :lf=/var/log/lp-errs :pl#66 :pw#80 :pc#150 :mx#0 :sh
The Common Unix Printing System (CUPS) is quickly replacing BSD-style printing in most Linux distributions. There are numerous reasons why CUPS is displacing the status quo, which we will leave for another discussion. However, no discussion of printing in the Samba environment would be complete without now including a section on CUPS printing.
To introduce printing with CUPS, let's have a look at a simple CUPS configured smb.conf file:
[global] load printers = yes printing = cups printcap name = cups [printers] comment = Brewery Printers path = /var/spool/samba browsable = no public = yes guest ok = yes writable = no printable = yes printer admin = root, @wheel
This is all that is required for basic configuration to make Samba work with CUPS, provided that CUPS itself is functional on your system.
The global section establishes that the /etc/printcap file is enumerated with the load printers option, which automatically parses the printcap and enables the printers configured within. This feature can be both really helpful and a bit frightening for some system administrators. While it makes configuration much easier, it does somewhat reduce the administrators ability to control what is visible to users. If this option turned off, you must individually create each printer share in the Samba configuration files.
The printing option, which we had previously set to bsd, has been changed to cups. We've also named the printcap cups for clarity.
The next section, printers, is also very similar to the previous example; however, we've now configured a printer administration group. This is a basic option that will allow the group specified to have administrative access to the CUPS aspects of the printing.
While not necessary, there are a number of additional options that can be added to a cups-based printer configuration to customize it based on need. For more detail and advanced configuration with CUPS and Samba, check the Samba web site at http://www.samba.org and the CUPS web site at http://www.cups.org.
Samba Web Administration Tool (SWAT) is used to simplify administration and configuration of Samba. For those who like to use a GUI, this is one of the best options because it is written by the Samba team and contains all possible configuration options. Other GUI frontend programs will work, but may not be as current.
SWAT is basically a web server as well as an administration tool. In order to get it working, you will need to add it to your inetd.conf or xinetd configurations. With xinetd, your configuration for swat should look something like this:
service swat
{
port = 901
socket_type = stream
wait = no
user = root
server = /usr/sbin/swat
log_on_failure += USERID
disable = no
}You will also need to add the SWAT port to your /etc/services file, if it's not already there.
swat 901/tcp # Samba configuration tool
After you restart your xinetd process, you are ready to use the service, which you would do by pointing your web browser at your Samba server's IP address on port 901.
You may have noticed that SWAT doesn't use SSL, which is probably OK if you are using it from only localhost. If you are interested in using it over the network, however, encryption is a good idea. Though SWAT doesn't support encryption, it can be added using the popular SSL tunneling tool called stunnel.
The easiest method to configure this was developed by Markus Krieger. In order to use this method, you will need to have both OpenSSL and stunnel installed. Documentation and source code for stunnel can be found at http://www.stunnel.org. Once both are installed and operational, you will need to generate a private key, which can be done like this:
vlager# /usr/bin/openssl req -new -x509 -days 730 -nodes -config /path/to/stunnel/stunnel.cnf -out /etc/stunnel/stunnel.pem -keyout /etc/stunnel/stunnel.pemOnce you have created your keys, you need to make sure that you remove the original SWAT from your inetd.conf file and send a SIGHUP signal to the daemon, if necessary. You will no longer be calling the standard SWAT daemon through inetd, so be sure that it has been removed.
stunnel can now be started. You can launch it from the command line or create a small script to launch it automatically. To start stunnel, as root, type:
vlager# stunnel -p /etc/stunnel/stunnel.pem -d 901 -l /path/to/samba/bin/swat swatIf you've built your Samba server and everything has worked perfectly the first time, consider yourself a part of the lucky minority. For everyone else, we'll now discuss a few tips on how to track down and fix some common problems.
When troubleshooting Samba, one important issue to keep in mind is that the default options always take priority. This means that if a default configuration option is set, simply commenting it out does not change its value. For example, you can try to disable the load printers option by simply commenting it out.
[printers] path = /var/spool/samba #load printers = yes
However, using testparm, you will see that the option is still set to yes.
ticktock samba # testparm -s -v |grep "load printers"
load printers = YesWith Samba, you must always explicitly define the options you wish to have; commenting out will not necessarily guarantee success. If something isn't working as expected, check this first.
As basic as it sounds, you should also check to see whether the smbd and nmbd processes exist. It is not uncommon for something to cause them to fail silently, and you will not realize they are not running.
One of the more common login problems with Samba occurs with the root, but can happen with any user on the system. For each Samba user, it is important to remember that a separate Samba password must be created because Samba does not use the Linux /etc/shadow hash. For example, if you try to access a Samba file share as root, the system root password will fail, unless you've already created a Samba password for the root account using the same root password (which is definitely not advised). To correct this issue, a separate account must be created as follows:
vlager# smbpasswd -a root
New SMB password:
Retype new SMB password:
Added user root.