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).
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 ignored—at 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
This share-level Boolean parameter, when set to
Yes (the default is
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
This parameter sets the printing system that Linux uses. Samba
supports 11 values (
NT), but only
CUPS are common in
SoftQ option was removed early in the
3.0.x series, while
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.
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
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
%p variable, which specifies the print queue
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
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
CUPS, but Samba won’t use the
CUPS API, and you may need to set
printcap name = /etc/printcap.
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
Several other options are available to tweak features, such as the
commands used to delete print jobs, pause the print queue, and so on.
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
/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:
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.
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
[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.
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 driver—say, to use a PostScript driver when printing text but to use a printer-specific driver when printing graphics.