Section 4.3. Creating a Printer Share

4.3. Creating a Printer Share

Now that you've got printers working on the Samba server using CUPS or some other printing software, it's time to begin configuring a printer share in Samba itself. Printer shares are very much like file shares, so you can configure printer shares much as you would configure file shares, but with a few key differences. You'll also need to decide whether to share a non-PostScript printer as a PostScript model (using Ghostscript to convert PostScript into the printer's native format) or using native drivers on the clients (bypassing Ghostscript on the server).

4.3.1. File Shares Versus Printer Shares

SMB/CIFS printer shares are virtually identical to file shares from a Samba configuration perspective. The difference is what the server does with files sent to the share by clients. In the case of file shares, the files are stored in a local directory and then ignoredat least, until they're accessed by the same or another client. In the case of printer shares, though, the server stores the file and then passes that file to the local printing system. The printing system typically prints the file and then deletes it. (Samba supports specifying an arbitrary command as the printing system, though, so you can use "printer" shares to perform unusual tasks, such as creating a CD-R.)

Because SMB/CIFS printer shares are so similar to file shares, they're defined just as you would define a file share, by placing the share name in square brackets, as in [okidata] to create a printer share called OKIDATA. In order to create a printer share, though, you must set one or more additional parameters:

printable

This share-level Boolean parameter, when set to Yes (the default is No), defines a printer share; it alone will create a printer share, although it might not work, depending on other parameters and the overall computer configuration. This parameter overrides the writeable parameter and its synonyms; all printable shares are necessarily read/write. A synonym for this parameter is print ok.

printing

This parameter sets the printing system that Linux uses. Samba supports 11 values (BSD, AIX, LPRng, PLP, SysV, HPUX, QNX, SoftQ, CUPS, OS2, and NT), but only BSD, LPRng, and CUPS are common in Linux. (The SoftQ option was removed early in the 3.0.x series, while OS2 and NT are recent additions.) This parameter sets the defaults for several other parameters, enabling Samba to most efficiently submit print jobs to your local print queues. Until Samba 3.0.3, this parameter was global, but it's a now a share-level parameter.

print command

This share-level parameter sets the command that's used to print a file. The default depends on the printing parameter. You can tweak this option to achieve special effects, such as setting duplex printing. If you try changing this parameter, be sure that the command you specify deletes the input file (identified by the Samba %s variable).

printer name

You can specify the name of the local print queue with this parameter. If you omit it, the default is based on the share name; for instance, if the share is called OKIDATA, Samba will try to submit the job to a queue called okidata. One important exception is described shortly. This option actually sets the %p variable, which specifies the print queue in the print command.

printcap name

This parameter points Samba at a file that defines local printers. It's important only if you define a [printers] share, as described shortly. Ordinarily, this parameter points to /etc/printcap, but if you set printing = CUPS, you can also set printcap name = CUPS to have Samba use the CUPS API to obtain a printer list. This requires CUPS support in the Samba binary, which may be added or omitted as a compile-time option. If this support is missing, you may still use printing = CUPS, but Samba won't use the CUPS API, and you may need to set printcap name = /etc/printcap.

load printers

This global Boolean parameter tells Samba whether to load the printers specified in printcap name for browsing. This parameter defaults to Yes, and if you intend to use a [printers] share, you shouldn't change it.

min print space

To minimize the risk of problems due to insufficient disk space, you can specify a minimum that must be present before Samba will accept a print job. This parameter takes disk space in kilobytes; if less space is free in the target directory, Samba will refuse the print job. The default value is 0, which disables this check.

Several other options are available to tweak features, such as the commands used to delete print jobs, pause the print queue, and so on. Consult the smb.conf manpage for details. In addition, some common file share parameters are important. Most notable of these is directory or its synonym, path. These parameters tell Samba where to store the print job before it's submitted to the print queue. The default value of /tmp usually works, but you may want to change this to a Samba-specific directory, such as /var/spool/samba. You should not try pointing Samba to your CUPS, LPRng, or other local printing system's queue! If you create a new Samba printer queue directory, be sure it's readable to all users who are authorized to use the printer. You may also want to set the sticky bit on the directory, which will prevent users other than the files' owners from deleting a file:

# mkdir /var/spool/samba # chmod 777 /var/spool/samba # chmod o+t /var/spool/samba

One unusual printer share is defined as [printers]. If this share is present, Samba creates individual shares for all of the shares in /etc/printcap (or another file specified by printcap name). Using a [printers] share can greatly simplify printer configuration, particularly on a server with many printers you want to share. This share is described in more detail in Section 4.5.4.

4.3.2. Sharing PostScript Printers

In Linux's native printing system, most programs treat printers as PostScript models. Part of the job of CUPS (or any other Linux printing queue) is to pass PostScript files through Ghostscript to convert them into formats that the printer can actually understand. (Of course, if the printer is a PostScript model, this conversion process isn't necessary when programs generate PostScript output.) From a purely Linux point of view, Samba is just another program; the fact that the files Samba prints originate from another computer is unimportant.

The result of this arrangement is that sharing a printer as a PostScript printer is usually fairly straightforward. If you can print from the Samba server computer itself using commands like lpr or the CUPS test page printout, you can share a printer with a fairly basic smb.conf entry:

[epson]    directory = /var/spool/samba    printable = Yes

This entry makes a printer share called EPSON available to clients. On the clients, you must use a PostScript driver to print to the printer, whether or not the printer is really a PostScript model; to the client, it looks like a PostScript printer. (Windows printer drivers are described in more detail in Section 4.4.)

Some Windows PostScript drivers generate output that can confuse a normal Linux queue into thinking the file is not, in fact, PostScript. If your Windows printouts to genuine PostScript printers consist of PostScript code rather than the documents you intended, one workaround is to use a raw queue like the one described in the Section 4.3.3, on the Samba server.

Sharing printers as PostScript models means that print jobs are sent over the network as PostScript. In the case of text documents, this is generally fairly efficient because the content is mostly text, rather than text converted to bitmaps. Using PostScript can also simplify driver installation and maintenance on a network with many printers; you may be able to use just one driver for several different printers. On the other hand, if the printer isn't really a PostScript model, the Samba server computer will need to convert the text into some other form (usually a printer-specific bitmap), which can consume a fair amount of CPU time on the server.

4.3.3. Sharing Non-PostScript Printers

When sharing a non-PostScript printer, another option is available: you can share the printer using a "raw" Linux printer queue. This queue uses the local Linux printing system, such as CUPS, but it bypasses Ghostscript. The result is that programs, such as Samba and its clients, must produce files the printer can parse. Typically, you do this by installing and using a printer's native drivers, as supplied by the manufacturer, on the Windows clients.

The Samba printer share configuration for a non-PostScript printer is likely to look much like the configuration for a PostScript printer. The main difference on the Samba server side is in the Linux printer queue configuration. In the case of CUPS, when you provide CUPS with the printer's make (in Step #4 of the procedure in the Section 4.2.2), you select Raw, followed by Raw Queue as the model. Alternatively, in Samba 3.0.3 and later, you can use the Samba cups options = raw parameter if you set printing = CUPS. This option tells CUPS to handle the input as if it were to a raw queue. If you're using LPRng or BSD LPD, omit the if line in /etc/printcap to create a raw queue.

When sharing printers in this way, the client generates printer-specific codes. For many low-end printers, this means that the clients generate bitmaps, even when printing text. These bitmaps are likely to be larger than PostScript files describing the same page, so raw printer queues may increase the network bandwidth requirements of printing. On the other hand, because Ghostscript isn't involved on the print server, the CPU requirements on the server are likely to be reduced. Non-PostScript Windows printer drivers are also likely to provide access to printer features that aren't easily adjusted through PostScript drivers, such as a printer's resolution.

When deciding between PostScript and raw queues, your best bet is to set up both types of queue and evaluate performance yourself. Try printing some documents in both ways and judge the output quality, print speed, and network load. You can then decide which method to use when you make the printers available to all your users. In some cases, you may want to make a printer accessible in both ways. This will enable your users to pick the optimum driversay, to use a PostScript driver when printing text but to use a printer-specific driver when printing graphics.