Learn Linux, 302 (Mixed environments)

Print services

Create and manage Samba print shares in a mixed environment


Content series:

This content is part # of # in the series: Learn Linux, 302 (Mixed environments)

Stay tuned for additional content in this series.

This content is part of the series:Learn Linux, 302 (Mixed environments)

Stay tuned for additional content in this series.


In this article, learn to:

  • Create and configure printer sharing
  • Configure integration between Samba and the Common UNIX® Print System (CUPS)
  • Manage Windows® print drivers, and configure downloads of print drivers
  • Configure the [print$] share
  • Understand security concerns with printer sharing
  • Set up and manage print accounting

This article helps you prepare for Objective 312.3 in Topic 312 of the Linux Professional Institute's (LPI) Mixed Environment Specialty exam (302). The objective has a weight of 2.


To get the most from the articles in this series, you should have an advanced knowledge of Linux and a working Linux system on which you can practice the commands covered in this article. In addition, you should have access to a Windows environment that you can use to test file and print access.

Configuring a printer share

Configuring a Samba printer share is much like configuring a file share. You define a section, set some parameters, and connect your clients. Because printing is involved, however, there are some subtle differences. Listing 1 shows a fairly typical configuration inside smb.conf.

Listing 1. Typical printing configuration
  load printers = yes
  printing = sysv
  comment = Printers
  path = /var/spool/samba
  writable = no
  printable = yes

Listing 1 doesn't define any specific printers. Instead, it tells Samba to load the list of system printers, then defines a template section called [printers]. Recall from the previous article that the [homes] section is used as a template for home directories. The [printers] section does the same thing for printers.

At the global level, the load printers parameter tells Samba to look for system printers and set them up as shares. printing = sysv means to use the older SysV printing system. This will do for now, but later, you will learn how to configure the more modern CUPS.

The [printers] section defines what each printer share will look like. Unless you need to offer special options per printer, such as restricting users, you can usually get away with the template. The path is for Samba's use. When you print to a Samba printer, smbd spools the file to the directory that the path parameter specifies before sending the job on to the system print facility. Then, you must make sure that the share is not writable and that it is printable so that Samba can properly use it as a printer share.

Now, if you browse to your server, you can see the list of printers. If you have the correct printer driver installed on your Windows client, you can proceed to install that printer and use it over the network.

Integrating Samba and CUPS

CUPS has replaced the SysV printing system in most Linux distributions. CUPS is more flexible and user friendly than SysV printing, and it offers a compatibility layer that integrates seamlessly with legacy printing. If you're using lp or lpq commands, you're likely going through CUPS.

One way CUPS improves upon legacy printing is its ability to pre-process print jobs. For example, if you send a PDF file to a printer, CUPS can understand the file format, send the output through something like GhostScript, and translate the file into a language that the printer can understand. This was possible with a lot of hacking in the old days, but it's all baked into CUPS.

The simplest configuration required to enable CUPS printing is shown in Listing 2.

Listing 2. Enabling CUPS support
printing = cups
printcap = cups

Listing 2 works in global mode. First, printing is done through the CUPS libraries instead of lpr. The last command tells Samba to fetch its list of printers from the CUPS daemon instead of the system printcap file. You may still have a printcap file even if you use CUPS, as CUPS maintains this file for compatibility with non-CUPS applications.

Even with Samba integrated with CUPS, you still use CUPS tools to manage the print queues. If you do not know your way around CUPS, here is an overview of the more important commands:

  • lp. Sends output to the printer. (You usually pipe the output of one command to this command, such as cat /etc/motd | lp.)
  • cupsenable and cupsdisable. Starts and stops printers, respectively. (These are good commands for resetting a printer, too.)
  • cupsreject. Rejects or accepts jobs to a printer. (This command does not change the status of the printer; instead, it tells CUPS to reject incoming jobs.)
  • lpadmin. Lets you set configuration values on a printer, such as assigning quotas.
  • lpq. Shows the queued entries for a given printer.
  • lprm. Lets you cancel jobs from a printer.

Raw vs. intelligent configuration

Printers generally understand a Page Description Language (PDL) such as Adobe® PostScript® or Printer Command Language (PCL). Some printers may use a vendor-specific PDL. It is the job of the Windows printer driver to translate the application's print commands into the PDL the printer speaks. Without the printer driver, the commands that the application generates will be printed directly as text, resulting in reams of garbage.

This method of having the client process the document into a format ready for the printer is called raw printing. In this mode, Samba merely copies the bytes from the client to the printer. This approach has two downsides:

  • The client must have the printer-specific driver in order to print.
  • It is difficult for Samba to understand what the job is doing, such as to log how many pages were printed.

Despite these two drawbacks, raw printing is easy to set up. Printer drivers can be distributed from the Samba server with some additional effort.

Distributing drivers to Windows clients

Getting Samba to distribute your printer drivers is a complicated matter. The best approach is to install a universal PostScript printer driver and use that for all your printers. CUPS will take care of converting the client's PostScript into something the printer understands through its intelligent printing system. You will also gain insight into the number of pages printed by using this approach instead of native drivers.

You will need to download the CUPS drivers: The current file is cups-windows-6.0-1.i386.rpm (see Related topics for a link). This package installs the following files into /usr/share/cups/drivers:

  • cups6.inf
  • cups6.ini
  • cupsps6.dll
  • cupsui6.dll

The CUPS drivers only support Microsoft® Windows 2000 and later clients, which is usually alright, but the Samba utility used later is hard-coded to look for the legacy Microsoft drivers and fails if they are not present. The following files will be on your system, and they should also be copied to /usr/share/cups/drivers:

  • ps5ui.dll
  • pscript5.dll
  • pscript.hlp
  • pscript.ntf

These files are usually in your C:\WINDOWS\ServicePackFiles\i386 directory.

Now that all eight files are in your CUPS drivers directory, you create the print$ share. This share is hard-coded into Windows clients, and this is where the clients look for printer drivers when a printer is installed. The printer share is a fairly standard share, as shown in Listing 3.

Listing 3. The print$ share
  comment = Printer Driver Export
  path = /etc/samba/drivers
  browseable = yes
  guest ok = no
  read only = yes
  write list = root

Listing 3 shows a simple share that's Read-only to everyone but the root user. Don't forget to restart Samba to make this share take effect.

Finally, use the cupsaddsmb command to install the printer drivers. For the Downstairs_Laser share, simply run cupsaddsmb -v Downstairs_Laser. You will be prompted for your root password, and then your screen will show a flurry of activity.

Clients can now browser to your Samba server and double-click the printer. They will be able to use the printer without any extra steps, such as printer identification and driver installation.

Vendor-specific drivers

You should use the generic CUPS PostScript driver so that CUPS can understand what is being printed. If you decide to distribute Windows drivers, the procedure is similar. First, you don't use the cupsaddsmb command. You copy the drivers to /etc/samba/drivers yourself but also must put them in an architecture-specific directory (cupsaddsmb did this for you). For example, W32X86 is used for 32-bit drivers.

You use the rpcclient command to tell Samba about the driver. You must pass the name of the printer driver files and the official name of the printer. See Related topics for a worked-out example.

Accounting and security

Accounting, when it comes to printers, is really about tracking and restricting page usage per user. Security refers to the ability to know who is using your printers and limiting access where required. This access could be the ability to print to the printer or the ability to cancel other people's jobs.

Printer security

Samba's role in the printing process is to take a client's print file, such as PostScript, and send it to CUPS. Anything Samba does, such as showing the status of the print queue to a client, it does through CUPS. CUPS queues the files; CUPS controls the printer. Samba's job is to be a conduit between CUPS and the client.

It is possible to get the clients to print directly to CUPS using the Internet Printing Protocol. However, the ease of printer installation from the Microsoft Network Neighborhood cannot be underestimated. Just remember that any controls you implement at the Samba level can be potentially overridden at the CUPS level if clients connect directly to CUPS.

Consider a printer share that has been protected using valid users = alice, bob to allow only two users to print. If user mallory tries to print through Samba, the request will be denied. If CUPS was not set up with similar permissions, mallory could print to the printer through the CUPS queue.

One other security consideration is the use of guest users. If you can authenticate every user who needs to print, ensure that guest ok = no is in your [printers] configuration section; then, only authenticated users will be able to print. Otherwise, unknown users can print to your printers.

Print quotas

As in printing jobs, CUPS handles the accounting work, not Samba. CUPS allows for the use of printer quotas, which limit the number of printed pages per user per time period. Listing 4 shows how to impose a quota on a printer.

Listing 4. Imposing a quota on a printer
# lpadmin -p Downstairs_Laser -o job-quota-period=604800 -o job-page-limit=100 \

Listing 4 sets three options on the printer. The first is the job quota period, which is 604,800 seconds (1 week). The second is the page limit during that quota period: Here, it is 100 pages. A third option limits the amount of printing to 50MB. The latter is not required, especially because it's a difficult value to gauge, but it does provide options for people who want to limit the printing of graphically intensive files.

To verify or check the quota on a printer, look in /etc/cups/printers.conf; you will see the QuotaPeriod, PageLimit, and KLimit options with the values you added above. To remove quotas, set the values to 0.

Each print job logs to a file called page.log, which is often found in /var/log/cups. A typical line looks like Listing 5.

Listing 5. A typical page accounting log
Downstairs_Laser 755 sean [26/Apr/2011:15:02:27 -0500] 1 1 - localhost smbprn.0019.FWqosE

The left part of the line is most relevant to printer accounting. The fields, in order, are:

  • The printer name
  • The job number assigned to the print job
  • The user who printed
  • The date in GMT and the time zone offset
  • The number of pages printed
  • The number of copies sent

Thus, the number of pages used is the number of pages printed times the number of copies sent. See Related topics for a description of the remaining fields.

Note: The biggest limitation of CUPS quotas is that they apply to all users.

Moving forward

The next exam objective, 312.4, will dive into the details of making Samba act as and with Microsoft primary and backup domain controllers.

Downloadable resources

Related topics

  • The web version of the smb.conf man page is more convenient than the command-line version.
  • Review the developerWorks study material for Topic 107 to get a refresher on command-line printing.
  • Chapter 21 of the Samba-HOWTO describes "classical" printing support, which is what you had before CUPS was involved. This site also has a worked-out example for adding a Windows printer driver.
  • Chapter 22 of the Samba-HOWTO has extra information on CUPS and Samba integration.
  • Review the entire LPI exam prep series on developerWorks to learn Linux fundamentals and prepare for systems administrator certification based on LPI exam objectives prior to April 2009.
  • Download the Windows CUPS driver.
  • Get the latest Samba version so that you're up to date with the latest features.
  • In the developerWorks Linux zone, find hundreds of how-to articles and tutorials, as well as downloads, discussion forums, and a wealth of other resources for Linux developers and administrators.
  • Evaluate IBM products in the way that suits you best: Download a product trial, try a product online, use a product in a cloud environment, or spend a few hours in the SOA Sandbox learning how to implement Service Oriented Architecture efficiently.
  • Follow developerWorks on Twitter, or subscribe to a feed of Linux tweets on developerWorks.


Sign in or register to add and subscribe to comments.

ArticleTitle=Learn Linux, 302 (Mixed environments): Print services