From 293421f3c64a2adff7dc15f7ad3adb6120c9fd16 Mon Sep 17 00:00:00 2001
From: Gerald Carter Table of Contents
-Printing is often a mission-critical service for the users. Samba can
+ Table of Contents
+Printing is often a mission-critical service for the users. Samba can
provide this service reliably and seamlessly for a client network
consisting of Windows workstations.
-A Samba print service may be run on a Standalone or a Domain
-member server, side by side with file serving functions, or on a
-dedicated print server. It can be made as tight or as loosely secured
-as needs dictate. Configurations may be simple or complex. Available
-authentication schemes are essentially the same as described for file
-services in previous chapters. Overall, Samba's printing support is
-now able to replace an NT or Windows 2000 print server full-square,
-with additional benefits in many cases. Clients may download and
-install drivers and printers through their familiar "Point'n'Print"
-mechanism. Printer installations executed by "Logon Scripts" are no
-problem. Administrators can upload and manage drivers to be used by
-clients through the familiar "Add Printer Wizard". As an additional
-benefit, driver and printer management may be run from the command line
-or through scripts, making it more efficient in case of large numbers
-of printers. If a central accounting of print jobs (tracking every
-single page and supplying the raw data for all sorts of statistical
-reports) is required, this is best supported by CUPS as the print
-subsystem underneath the Samba hood.
+A Samba print service may be run on a Stand-alone or Domain Member server,
+side by side with file serving functions, or on a dedicated print server.
+It can be made as tight or as loosely secured as needs dictate. Configurations
+may be simple or complex. Available authentication schemes are essentially
+the same as described for file services in previous chapters. Overall,
+Samba's printing support is now able to replace an NT or Windows 2000
+print server full-square, with additional benefits in many cases. Clients
+may download and install drivers and printers through their familiar
+“Point'n'Print” mechanism. Printer installations executed by
+“Logon Scripts” are no problem. Administrators can upload and
+manage drivers to be used by clients through the familiar “Add Printer
+Wizard”. As an additional benefit, driver and printer management may
+be run from the command line or through scripts, making it more efficient
+in case of large numbers of printers. If a central accounting of print jobs
+(tracking every single page and supplying the raw data for all sorts of
+statistical reports) is required, this function is best supported by
+the newer Common UNIX Printing System (CUPS)
+as the print subsystem underneath the Samba hood.
-This chapter deals with the foundations of Samba printing, as they
-implemented by the more traditional UNIX (BSD- and System V-style)
-printing systems. Many things apply to CUPS, the newer Common UNIX
-Printing System, too; so if you use CUPS, you might be tempted to jump
-to the next chapter -- but you will certainly miss a few things if you
-do so. Better to read this chapter too.
+This chapter deals with the foundations of Samba printing as they
+are implemented by the more traditional UNIX (BSD- and System V-style)
+printing systems. Many things covered in this chapter apply also to CUPS.
+If you use CUPS, you may be tempted
+to jump to the next chapter but you will certainly miss a few things if
+you do. It is recommended that you read this chapter as well as .
-Most of the given examples have been verified on Windows XP
+Most of the following examples have been verified on Windows XP
Professional clients. Where this document describes the responses to
-commands given, bear in mind that Windows 2000 clients are very
-similar, but may differ in details. Windows NT is somewhat different
+commands given, bear in mind that Windows 200x/XP clients are quite
+similar, but may differ in minor details. Windows NT is somewhat different
again.
-
-Samba's printing support always relies on the installed print
-subsystem of the UNIX OS it runs on. Samba is a "middleman". It takes
-printfiles from Windows (or other SMB) clients and passes them to the
-real printing system for further processing. Therefore it needs to
-"talk" to two sides: to the Windows print clients and to the UNIX
-printing system. Hence we must differentiate between the various
-client OS types each of which behave differently, as well as the
-various UNIX print subsystems, which themselves have different
-features and are accessed differently. This part of the Samba HOWTO
-Collection deals with the "traditional" way of UNIX printing first;
-the next chapter covers in great detail the more modern
-Common UNIX Printing System
-(CUPS).
-
- CUPS users, be warned: don't just jump on to the next
-chapter. You might miss important information contained only
-here!
-
-To successfully print a job from a Windows client via a Samba
-print server to a UNIX printer, there are 6 (potentially 7)
-stages:
- Windows opens a connection to the printer share Samba must authenticate the user Windows sends a copy of the printfile over the network
-into Samba's spooling area Windows closes the connection again Samba invokes the print command to hand the file over
-to the UNIX print subsystem's spooling area The UNIX print subsystem processes the print
-job The printfile may need to be explicitly deleted
-from the Samba spooling area.
-There are a number of configuration parameters in
- controlling Samba's printing
-behaviour. Please also refer to the man page for smb.conf to
-acquire an overview about these. As with other parameters, there are
-Global Level (tagged with a "G" in the listings) and
-Service Level ("S") parameters.
- These may go into the
-[global] section of smb.conf.
-In this case they define the default
-behaviour of all individual or service level shares (provided those
-don't have a different setting defined for the same parameter, thus
-overriding the global default). These may not go into individual
-shares. If they go in by error, the "testparm" utility can discover
-this (if you run it) and tell you so. The following smb.conf parameters directly
-related to printing are used in Samba. See also the
-smb.conf man page for detailed explanations:
- Global level parameters: addprinter command,
-deleteprinter command,
-disable spoolss,
-enumports command,
-load printers,
-lpq cache time,
-os2 driver map,
-printcap name, printcap,
-show add printer wizard,
-total print jobs,
-use client driver.
- Service level parameters: hosts allow,
-hosts deny,
-lppause command,
-lpq command,
-lpresume command,
-lprm command,
-max print jobs,
-min print space,
-print command,
-printable, print ok ,
-printer name, printer,
-printer admin,
-printing = [cups|bsd|lprng...],
-queuepause command,
-queueresume command,
-total print jobs.
+
+Samba's printing support always relies on the installed print subsystem
+of the UNIX OS it runs on. Samba is a “middleman.” It takes
+print files from Windows (or other SMB) clients and passes them to the real
+printing system for further processing, therefore, it needs to communicate with
+both sides: the Windows print clients and the UNIX printing system. Hence, we
+must differentiate between the various client OS types, each of which behave
+differently, as well as the various UNIX print subsystems, which themselves
+have different features and are accessed differently.
+
+This deals with the traditional way of UNIX printing. The next chapter
+covers in great detail the more modern Common UNIX Printing
+System (CUPS).
+ CUPS users, be warned: do not just jump on to the next
+chapter. You might miss important information only found here!
+
+It is apparent from postings on the Samba mailing list that print configuration
+is one of the most problematic aspects of Samba administration today. Many
+new Samba administrators have the impression that Samba performs some sort
+of print processing. Rest assured, Samba does not peform any type of print
+processing. It does not do any form of print filtering.
-Samba's printing support implements the Microsoft Remote Procedure
-Calls (MS-RPC) methods for printing. These are used by Windows NT (and
-later) print servers. The old "LanMan" protocol is still supported as
-a fallback resort, and for older clients to use. More details will
-follow further beneath.
-
-Here is a very simple example configuration for print related settings
-in the file. If you compare it with your own system's , you probably find some
-additional parameters included there (as pre-configured by your OS
-vendor). Further below is a discussion and explanation of the
-parameters. Note, that this example doesn't use many parameters.
+Samba obtains from its clients a data stream (print job) that it spools to a
+local spool area. When the entire print job has been received, Samba invokes
+a local UNIX/Linux print command and passes the spooled file to it. It is
+up to the local system printing subsystems to correctly process the print
+job and to submit it to the printer.
+
+Successful printing from a Windows client via a Samba print server to a UNIX
+printer involves six (potentially seven) stages:
+ Windows opens a connection to the printer share. Samba must authenticate the user. Windows sends a copy of the print file over the network
+into Samba's spooling area. Windows closes the connection. Samba invokes the print command to hand the file over
+to the UNIX print subsystem's spooling area. The UNIX print subsystem processes the print job. The print file may need to be explicitly deleted
+from the Samba spooling area. This item depends on your print spooler
+configuration settings.
+There are a number of configuration parameters to control Samba's
+printing behavior. Please refer to the man page for smb.conf for an
+overview of these. As with other parameters, there are Global Level
+(tagged with a G in the listings) and Service Level
+(S) parameters.
+ These may not go into
+ individual share definitions. If they go in by error,
+ the testparm utility can discover this
+ (if you run it) and tell you so.
+ These may be specified in the
+ [global] section of smb.conf.
+ In this case they define the default behavior of all individual
+ or service level shares (provided they do not have a different
+ setting defined for the same parameter, thus overriding the
+ global default).
+
+ shows a simple printing configuration.
+If you compare this with your own, you may find
+additional parameters that have been pre-configured by your OS
+vendor. Below is a discussion and explanation of the
+parameters. This example does not use many parameters.
However, in many environments these are enough to provide a valid
-smb.conf file which enables all clients to print.
- Example 18.1. Simple configuration with BSD printing
-This is only an example configuration. Samba assigns default values to all
-configuration parameters. On the whole the defaults are conservative and
-sensible. When a parameter is specified in the smb.conf file this overwrites
-the default value. The testparm utility when run as root
-is capable of reporting all setting, both default as well as smb.conf file
-settings. Testparm gives warnings for all mis-configured
-settings. The complete output is easily 340 lines and more, so you may want
-to pipe it through a pager program.
+smb.conf file that enables all clients to print.
+
+ Example 18.1. Simple configuration with BSD printing
+This is only an example configuration. Samba assigns default values to
+all configuration parameters. The defaults are conservative
+and sensible. When a parameter is specified in the smb.conf file, this
+overwrites the default value. The testparm utility when
+run as root is capable of reporting all setting, both default as well as
+smb.conf file settings. Testparm gives warnings for all
+misconfigured settings. The complete output is easily 340 lines and more,
+so you may want to pipe it through a pager program.
The syntax for the configuration file is easy to grasp. You should
-know that is not very picky about its
-syntax. It has been explained elsewhere in this document. A short
-reminder: It even tolerates some spelling errors (like "browsable"
-instead of "browseable"). Most spelling is case-insensitive. Also, you
-can use "Yes|No" or "True|False" for boolean settings. Lists of names
+know that is not very picky about its syntax. As has been explained
+elsewhere in this document, Samba tolerates some spelling errors (such
+as browsable instead of
+browseable), and spelling is
+case-insensitive. It is permissible to use Yes/No
+or True/False for Boolean settings. Lists of names
may be separated by commas, spaces or tabs.
-
-To see all (or at least most) printing related settings in Samba,
-including the implicitly used ones, try the command outlined below
-(hit "ENTER" twice!). It greps for all occurrences of "lp", "print",
-"spool", "driver", "ports" and "[" in testparm's output and gives you
-a nice overview about the running smbd's print configuration. (Note
-that this command does not show individually created printer shares,
-or the spooling paths in each case). Here is the output of my Samba
-setup, with exactly the same settings in
-as shown above:
+
+To see all (or at least most) printing-related settings in Samba, including
+the implicitly used ones, try the command outlined below. This command greps
+for all occurrences of lp, print, spool, driver, ports
+and [ in testparms output. This provides a convenient
+overview of the running smbd print configuration. This
+command does not show individually created printer shares or the spooling
+paths they may use. Here is the output of my Samba setup, with settings
+shown in :
+
You can easily verify which settings were implicitly added by Samba's
-default behaviour. Don't forget about this point: it may
+default behavior. Remember: it may
be important in your future dealings with Samba.
- testparm in samba 3 behaves differently from 2.2.x: used
-without the "-v" switch it only shows you the settings actually
-written into ! To see the complete
-configuration used, add the "-v" parameter to testparm.
+ testparm in Samba-3 behaves differently from that in 2.2.x: used
+without the “-v” switch it only shows you the settings actually
+written into! To see the complete
+configuration used, add the “-v” parameter to testparm.
Should you need to troubleshoot at any stage, please always come back
-to this point first and verify if "testparm" shows the parameters you
-expect! To give you an example from personal experience as a warning,
-try to just "comment out" the load printers"
+to this point first and verify if testparm shows the parameters you
+expect. To give you a warning from personal experience,
+try to just comment out the load printers
parameter. If your 2.2.x system behaves like mine, you'll see this:
-Despite my imagination that the commenting out of this setting should
-prevent Samba from publishing my printers, it still did! Oh Boy -- it
-cost me quite some time to find out the reason. But I am not fooled
-any more... at least not by this ;-)
+I assumed that commenting out of this setting should prevent Samba from
+publishing my printers, but it still did. It took some time to figure out
+the reason. But I am no longer fooled ... at least not by this.
-Only when setting the parameter explicitly to
-"load printers = No"
-would Samba recognize my intentions. So my strong advice is:
- Never rely on "commented out" parameters! Always set it up explicitly as you intend it to
+Only when the parameter is explicitly set to
+load printers = No
+would Samba conform with my intentions. So, my strong advice is:
+ Never rely on commented out parameters. Always set parameters explicitly as you intend them to
behave. Use testparm to uncover hidden
-settings which might not reflect your intentions.
-You can have a working Samba print configuration with this
-minimal :
+settings that might not reflect your intentions.
+The following is the most minimal configuration file:
-This example should show you that you can use testparm to test any
-filename for fitness as a Samba configuration. Actually, we want to
-encourage you not to change your
- on a working system (unless you know
-exactly what you are doing)! Don't rely on an assumption that changes
-will only take effect after you re-start smbd! This is not the
-case. Samba re-reads its every 60
-seconds and on each new client connection. You might have to face
-changes for your production clients that you didn't intend to apply at
-this time! You will now note a few more interesting things. Let's now
-ask testparm what the Samba print configuration
-would be, if you used this minimalistic file as your real
-:
+This example should show that you can use testparm to test any Samba
+configuration file. Actually, we encourage you not
+to change your working system (unless you know exactly what you are
+doing). Don't rely on the assumption that changes will only take effect after
+you re-start smbd! This is not the case. Samba re-reads it every 60 seconds
+and on each new client connection. You might have to face changes for your
+production clients that you didn't intend to apply. You will now
+note a few more interesting things; testparm is useful to
+identify what the Samba print configuration would be if you used this minimalistic
+configuration. Here is what you can expect to find:
-testparm issued 2 warnings:
- because we didn't specify the
-[printers] section as printable,
-and because we didn't tell it which spool directory to
-use.
-However, this was not fatal, and samba will default to values that
-will work here. Please, don't rely on this and don't use this
-example! This was only meant to make you careful to design and specify
-your setup to be what you really want it to be. The outcome on your
-system may vary for some parameters, since you may have a Samba built
-with a different compile-time configuration.
-Warning: don't put a comment sign at
-the end of a valid line. It
-will cause the parameter to be ignored (just as if you had put the
-comment sign at the front). At first I regarded this as a bug in my
-Samba version(s). But the man page states: “Internal whitespace
-in a parameter value is retained verbatim.” This means that a
-line consisting of, for example,
-
-will regard the whole of the string after the "="
-sign as the value you want to define. And this is an invalid value
-that will be ignored, and a default value used instead.]
-
- In the extended BSD configuration example we show a more verbose example configuration for print related
- settings in BSD-printing style environment . Below is a discussion
-and explanation of the various parameters. We chose to use BSD-style
-printing here, because we guess it is still the most commonly used
-system on legacy Linux installations (new installs now predominantly
-have CUPS, which is discussed entirely in the next chapter of this
-document). Note, that this example explicitly names many parameters
-which don't need to be specified because they are set by default. You
-might be able to do with a leaner smb.conf file. Example 18.2. Extended configuration with BSD printing
-This also is only an example configuration. You
-may not find all the settings in your own
- (as pre-configured by your OS
-vendor). Many configuration parameters, if not explicitly set to a
-specific value, are used and set by Samba implicitly to its own
-default, because these have been compiled in. To see all settings, let
-root use the testparm
-utility. testparm also gives warnings if you have
-mis-configured certain things..
-
-Following is a discussion of the settings from above shown example.
-
-The [global] section is one of 4 special
+testparm issued two warnings:
+ We did not specify the [printers] section as printable. We did not tell Samba which spool directory to use.
+However, this was not fatal and Samba will default to values that will
+work. Please, do not rely on this and do not use this example. This was
+included to encourage you to be careful to design and specify your setup to do
+precisely what you require. The outcome on your system may vary for some
+parameters given, since Samba may have been built with different compile-time
+options. Warning: do not put a comment sign
+at the end of a valid line. It will cause the parameter
+to be ignored (just as if you had put the comment sign at the front). At first
+I regarded this as a bug in my Samba versions. But the man page clearly says:
+“Internal whitespace in a parameter value is retained verbatim.”
+This means that a line consisting of, for example:
+
+will regard the whole of the string after the
+“=” sign as the value you want to
+define. This is an invalid value that will be ignored and a default
+value will be
+used in its place.
+
+In we show a more verbose example configuration
+for print-related settings in a BSD-style printing environment. What follows
+is a discussion and explanation of the various parameters. We chose to
+use BSD-style printing here because it is still the most commonly used
+system on legacy UNIX/Linux installations. New installations predominantly
+use CUPS, which is discussed in a separate chapter. explicitly
+names many parameters that do not need to be specified because they are set
+by default. You could use a much leaner smb.conf file. Alternately, you can use
+testparm or SWAT to optimize the smb.conf
+file to remove all parameters that are set at default.
+ Example 18.2. Extended BSD Printing Configuration
+This is an example configuration. You may not find all the settings that are in
+the confioguration file that was provided by the OS vendor. Samba configuration
+parameters, if not explicitly set default to a sensible value.
+To see all settings, as root use the testparm
+utility. testparm gives warnings for misconfigured settings.
+
+The following is a discussion of the settings from above shown example.
+
+The [global] section is one of four special
sections (along with [[homes],
-[printers] and
-[print$]...) It contains all parameters which
-apply to the server as a whole. It is the place for parameters which
-have only a "global" meaning. It may also contain service level
-parameters which then define default settings for all other
-sections and shares. This way you can simplify the configuration and
-avoid setting the same value repeatedly. (Within each individual
-section or share you may however override these globally set "share
-level" settings and specify other values).
- this causes Samba to use default print commands
-applicable for the BSD (a.k.a. RFC 1179 style or LPR/LPD) printing
-system. In general, the "printing" parameter informs Samba about the
-print subsystem it should expect. Samba supports CUPS, LPD, LPRNG,
-SYSV, HPUX, AIX, QNX and PLP. Each of these systems defaults to a
-different print command (and other queue control
-commands). this tells Samba to create automatically all
-available printer shares. "Available" printer shares are discovered by
-scanning the printcap file. All created printer shares are also loaded
-for browsing. If you use this parameter, you do not need to specify
-separate shares for each printer. Each automatically created printer
-share will clone the configuration options found in the
-[printers] section. (A load printers
-= no setting will allow you to specify each UNIX printer
-you want to share separately, leaving out some you don't want to be
-publicly visible and available). this setting is normally
-enabled by default (even if the parameter is not written into the
-). It makes the Add Printer Wizard icon
-show up in the Printers folder of the Samba host's
-share listing (as shown in Network Neighbourhood or
-by the net view command). To disable it, you need to
-explicitly set it to no (commenting it out
-will not suffice!). The Add Printer Wizard lets you upload printer
-drivers to the [print$] share and associate it
-with a printer (if the respective queue exists there before the
-action), or exchange a printer's driver against any other previously
-uploaded driver. this setting sets the upper limit to 100 print jobs
-being active on the Samba server at any one time. Should a client
-submit a job which exceeds this number, a “no more space
-available on server” type of error message will be returned by
-Samba to the client. A setting of "0" (the default) means there is
-no limit at all!
- this tells Samba where to look for a list of
-available printer names. (If you use CUPS, make sure that a printcap
-file is written: this is controlled by the "Printcap" directive of
-cupsd.conf).
- members of the ntadmin group should be able to add
-drivers and set printer properties ("ntadmin" is only an example name,
-it needs to be a valid UNIX group name); root is implicitly always a
-printer admin. The "@" sign precedes group names in
-. A printer admin can do anything to
-printers via the remote administration interfaces offered by MS-RPC
-(see below). Note that the printer admin
-parameter is normally a share level parameter, so you may associate
-different groups to different printer shares in larger installations,
-if you use the printer admin parameter on the
-share levels).
- this controls the cache time for the results of the
-lpq command. It prevents the lpq command being called too often and
-reduces load on a heavily used print server.
- if set to yes, this setting only
-takes effect for Win NT/2k/XP clients (and not for Win 95/98/ME). Its
-default value is No (or False).
-It must not be enabled on print shares
-(with a yes or true setting) which
-have valid drivers installed on the Samba server! For more detailed
-explanations see the man page of smb.conf.
-
-This is the second special section. If a section with this name
-appears in the smb.conf, users are able to
-connect to any printer specified in the Samba host's printcap file,
-because Samba on startup then creates a printer share for every
-printername it finds in the printcap file. You could regard this
-section as a general convenience shortcut to share all printers with
-minimal configuration. It is also a container for settings which
-should apply as default to all printers. (For more details see the
-smb.conf man page.) Settings inside this
-container must be share level parameters.
- the comment is shown next to
-the share if a client queries the server, either via Network
-Neighbourhood or with the net view command to list
-available shares.
- please note well, that the
-[printers] service must be
-declared as printable. If you specify otherwise, smbd will refuse to
-load at startup. This parameter allows
-connected clients to open, write to and submit spool files into the
-directory specified with the path parameter for
-this service. It is used by Samba to differentiate printer shares from
-file shares. this must point to a directory used by Samba to spool
-incoming print files. It must not be the same as the spool
-directory specified in the configuration of your UNIX print
-subsystem! The path would typically point to a directory
-which is world writeable, with the "sticky" bit set to it.
- this is always set to no if
-printable = yes. It makes the
-[printer] share itself invisible in the
-list of available shares in a net view command or
-in the Explorer browse list. (Note that you will of course see the
-individual printers).
-
-if set to yes, then no password is required to
-connect to the printers service. Access will be granted with the
-privileges of the guest account. On many systems the
-guest account will map to a user named "nobody". This user is in the UNIX
-passwd file with an empty password, but with no valid UNIX login.
-(Note: on some systems the guest account might not have the
-privilege to be able to print. Test this by logging in as your
-guest user using su - guest and run a system print
-command like
- lpr -P printername /etc/motd this is a synonym for guest ok = yes. Since we have guest ok = yes,
-it really doesn't need to be here! (This leads to the interesting
-question: “What, if I by accident have to contradictory settings
-for the same share?” The answer is: the last one encountered by
-Samba wins. The "winner" is shown by testparm. Testparm doesn't
-complain about different settings of the same parameter for the same
-share! You can test this by setting up multiple lines for the "guest
-account" parameter with different usernames, and then run testparm to
-see which one is actually used by Samba.)
- this normally (for other types of shares) prevents
-users creating or modifying files in the service's directory. However,
-in a "printable" service, it is always allowed to
-write to the directory (if user privileges allow the connection), but
-only via print spooling operations. "Normal" write operations are not
-allowed.
-If a section appears in the , which is
-tagged as printable = yes, Samba presents it as
-a printer share to its clients. Note, that Win95/98/ME clients may
-have problems with connecting or loading printer drivers if the share
-name has more than 8 characters! Also be very careful if you give a
-printer the same name as an existing user or file share name: upon a
-client's connection request to a certain sharename, Samba always tries
-to find file shares with that name first; if it finds one, it will
-connect to this and will never ultimately connect to a printer with
-the same name!
- the comment says it all.
- here we set the spooling area for this printer to
-another directory than the default. It is not a requirement to set it
-differently, but the option is available.
- the printer admin definition is different for this
-explicitly defined printer share from the general
-[printers] share. It is not a requirement; we
-did it to show that it is possible if you want it.
- we also made this printer browseable (so that the
-clients may conveniently find it when browsing the Network
-Neighbourhood).
- see explanation in last subsection.
- see explanation in last subsection.
- here we exercise a certain degree of access control
-by using the hosts allow and hosts deny parameters. Note, that
-this is not by any means a safe bet. It is not a way to secure your
-printers. This line accepts all clients from a certain subnet in a
-first evaluation of access control
- all listed hosts are not allowed here (even if they
-belong to the "allowed subnets"). As you can see, you could name IP
-addresses as well as NetBIOS hostnames
-here.
- this printer is not open for the guest account!
-
-In each section defining a printer (or in the
-[printers] section), a print
-command parameter may be defined. It sets a command to
-process the files which have been placed into the Samba print spool
-directory for that printer. (That spool directory was, if you
-remember, set up with the path
-parameter). Typically, this command will submit the spool file to the
-Samba host's print subsystem, using the suitable system print
-command. But there is no requirement that this needs to be the
-case. For debugging purposes or some other reason you may want to do
-something completely different than "print" the file. An example is a
-command that just copies the print file to a temporary location for
-further investigation when you need to debug printing. If you craft
-your own print commands (or even develop print command shell scripts),
-make sure you pay attention to the need to remove the files from the
-Samba spool directory. Otherwise your hard disk may soon suffer from
-shortage of free space.
-
-You learned earlier on, that Samba in most cases uses its built-in
-settings for many parameters if it can not find an explicitly stated
-one in its configuration file. The same is true for the
-print command. The default print command varies
-depending on the printing parameter
-setting. In the commands listed below, you will notice some parameters
-of the form %X where X is
-p, s, J etc. These letters stand for
-"printername", "spoolfile" and "job ID" respectively. They are
-explained in more detail further below. Here is an overview (excluding
-the special case of CUPS, which is discussed in the next chapter):
-
-We excluded the special CUPS case here, because it is discussed in the
-next chapter. Just a short summary. For printing =
-CUPS: If SAMBA is compiled against libcups, it uses the
-CUPS API to submit jobs, etc. (It is a good idea also to set
-printcap = cups in case your
-cupsd.conf is set to write its autogenerated
-printcap file to an unusual place). Otherwise Samba maps to the System
-V printing commands with the -oraw option for printing, i.e. it uses
-lp -c -d%p -oraw; rm %s With printing =
-cups , and if SAMBA is compiled against libcups, any
-manually set print command will be ignored!
-
-Having listed the above mappings here, you should note that there used
-to be a bug in recent 2.2.x versions which
-prevented the mapping from taking effect. It lead to the
-"bsd|aix|lprng|plp" settings taking effect for all other systems, for
-the most important commands (the print command, the
-lpq command and the lprm
-command). The lppause command and the
-lpresume command remained empty. Of course, these
-commands worked on bsd|aix|lprng|plp but they didn't work on
-sysv|hpux|qnx systems. To work around this bug, you need to
-explicitly set the commands. Use testparm -v to
-check which command takes effect. Then check that this command is
-adequate and actually works for your installed print subsystem. It is
-always a good idea to explicitly set up your configuration files the
-way you want them to work and not rely on any built-in defaults.
-
-After a print job has finished spooling to a service, the
-print command will be used by Samba via a
-system() call to process the spool file. Usually
-the command specified will submit the spool file to the host's
-printing subsystem. But there is no requirement at all that this must
-be the case. The print subsystem will probably not remove the spool
-file on its own. So whatever command you specify on your own you
-should ensure that the spool file is deleted after it has been
-processed.
+[printers]
+and [print$]...). The
+[global] contains all parameters which apply
+to the server as a whole. It is the place for parameters that have only a
+global meaning. It may also contain service level parameters that then define
+default settings for all other sections and shares. This way you can simplify
+the configuration and avoid setting the same value repeatedly. (Within each
+individual section or share you may, however, override these globally set
+share settings and specify other values).
+ Causes Samba to use default print commands
+ applicable for the BSD (also known as RFC 1179 style or LPR/LPD) printing
+ system. In general, the printing parameter informs Samba about the
+ print subsystem it should expect. Samba supports CUPS, LPD, LPRNG,
+ SYSV, HPUX, AIX, QNX, and PLP. Each of these systems defaults to a
+ different print command (and other queue control
+ commands). Tells Samba to create automatically all
+ available printer shares. Available printer shares are discovered by
+ scanning the printcap file. All created printer shares are also loaded
+ for browsing. If you use this parameter, you do not need to specify
+ separate shares for each printer. Each automatically created printer
+ share will clone the configuration options found in the
+ [printers] section. (The load printers
+ = no setting will allow you to specify each UNIX printer
+ you want to share separately, leaving out some you do not want to be
+ publicly visible and available). Setting is normally enabled by default (even if the parameter is not specified in smb.conf).
+ It causes the Add Printer Wizard icon to appear
+ in the Printers folder of the Samba host's
+ share listing (as shown in Network Neighborhood or
+ by the net view command). To disable it, you need to
+ explicitly set it to no (commenting it out
+ will not suffice). The Add Printer Wizard lets you upload printer
+ drivers to the [print$] share and associate it
+ with a printer (if the respective queue exists before the
+ action), or exchange a printer's driver against any other previously
+ uploaded driver. Sets the upper limit to 100 print jobs
+ being active on the Samba server at any one time. Should a client
+ submit a job that exceeds this number, a “no more space
+ available on server” type of error message will be returned by
+ Samba to the client. A setting of zero (the default) means there is
+ no limit at all.
+ Tells Samba where to look for a list of
+ available printer names. Where CUPS is used, make sure that a printcap
+ file is written. This is controlled by the Printcap directive in the
+ cupsd.conf file.
+ Members of the ntadmin group should be able to add
+ drivers and set printer properties (ntadmin is only an example name,
+ it needs to be a valid UNIX group name); root is implicitly always a
+ printer admin. The @ sign precedes group names in the
+ /etc/group. A printer admin can do anything to
+ printers via the remote administration interfaces offered by MS-RPC
+ (see below). In larger installations, the printer admin
+ parameter is normally a per-share parameter. This permits different groups to administer each printer share.
+ Controls the cache time for the results of the
+ lpq command. It prevents the lpq command being called too often and
+ reduces the load on a heavily used print server.
+ If set to yes, only
+ takes effect for Windows NT/200x/XP clients (and not for Win 95/98/ME). Its
+ default value is No (or False).
+ It must not be enabled on print shares
+ (with a yes or true setting) that
+ have valid drivers installed on the Samba server. For more detailed
+ explanations see the smb.conf man page.
+
+This is the second special section. If a section with this name appears in
+the smb.conf, users are able to connect to any printer specified in the
+Samba host's printcap file, because Samba on startup then creates a printer
+share for every printername it finds in the printcap file. You could regard
+this section as a general convenience shortcut to share all printers with
+minimal configuration. It is also a container for settings that should
+apply as default to all printers. (For more details see the smb.conf
+man page.) Settings inside this container must be Share Level parameters.
+
+ The comment is shown next to the share if
+ a client queries the server, either via Network Neighborhood or with
+ the net view command to list available shares.
+
+ The [printers] service must
+ be declared as printable. If you specify otherwise, smbd will refuse to load at
+ startup. This parameter allows connected clients to open, write to and submit spool files
+ into the directory specified with the path
+ parameter for this service. It is used by Samba to differentiate printer shares from
+ file shares.
+
+ Must point to a directory used by Samba to spool incoming print files. It
+ must not be the same as the spool directory specified in the configuration of your UNIX
+ print subsystem! The path typically points to a directory that is world
+ writeable, with the “sticky” bit set to it.
+
+ Is always set to no if
+ printable = yes. It makes
+ the [printer] share itself invisible in the list of
+ available shares in a net view command or in the Explorer browse
+ list. (You will of course see the individual printers).
+
+ If this parameter is set to yes, no password is required to
+ connect to the printer's service. Access will be granted with the privileges of the
+ guest account. On many systems the guest
+ account will map to a user named “nobody”. This user will usually be found
+ in the UNIX passwd file with an empty password, but with no valid UNIX login. (On some
+ systems the guest account might not have the privilege to be able to print. Test this
+ by logging in as your guest user using su - guest and run a system
+ print command like:
+
+ lpr -P printername /etc/motd
+
+ Is a synonym for guest ok = yes.
+ Since we have guest ok = yes, it
+ really does not need to be here. (This leads to the interesting question: “What if I
+ by accident have two contradictory settings for the same share?” The answer is the
+ last one encountered by Samba wins. Testparm does not complain about different settings
+ of the same parameter for the same share. You can test this by setting up multiple
+ lines for the guest account parameter with different usernames,
+ and then run testparm to see which one is actually used by Samba.)
+
+ Normally (for other types of shares) prevents users from creating or modifying files
+ in the service's directory. However, in a “printable” service, it is
+ always allowed to write to the directory (if user privileges allow the
+ connection), but only via print spooling operations. Normal write operations are not permitted.
+
+If a section appears in the smb.conf file, which when given the parameter
+printable = yes causes Samba to configure it
+as a printer share. Windows 9x/Me clients may have problems with connecting or loading printer drivers
+if the share name has more than eight characters. Do not name a printer share with a name that may conflict
+with an existing user or file share name. On Client connection requests, Samba always tries to find file
+shares with that name first. If it finds one, it will connect to this and will not connect
+to a printer with the same name!
+
+ The comment says it all.
+
+ Sets the spooling area for this printer to a directory other than the default. It is not
+ necessary to set it differently, but the option is available.
+
+ The printer admin definition is different for this explicitly defined printer share from the general
+ [printers] share. It is not a requirement; we
+ did it to show that it is possible.
+
+ This makes the printer browseable so the clients may conveniently find it when browsing the
+ Network Neighborhood.
+
+ See .
+
+ See .
+
+ Here we exercise a certain degree of access control by using the hosts allow and hosts deny
+ parameters. This is not by any means a safe bet. It is not a way to secure your
+ printers. This line accepts all clients from a certain subnet in a first evaluation of
+ access control.
+
+ All listed hosts are not allowed here (even if they belong to the allowed subnets). As
+ you can see, you could name IP addresses as well as NetBIOS hostnames here.
+
+ This printer is not open for the guest account.
+
+In each section defining a printer (or in the [printers] section),
+a print command parameter may be defined. It sets a command to process the files
+that have been placed into the Samba print spool directory for that printer. (That spool directory was,
+if you remember, set up with the path parameter). Typically,
+this command will submit the spool file to the Samba host's print subsystem, using the suitable system
+print command. But there is no requirement that this needs to be the case. For debugging or
+some other reason, you may want to do something completely different than print the file. An example is a
+command that just copies the print file to a temporary location for further investigation when you need
+to debug printing. If you craft your own print commands (or even develop print command shell scripts),
+make sure you pay attention to the need to remove the files from the Samba spool directory. Otherwise,
+your hard disk may soon suffer from shortage of free space.
+
+You learned earlier on that Samba, in most cases, uses its built-in settings for many parameters
+if it cannot find an explicitly stated one in its configuration file. The same is true for the
+print command. The default print command varies depending
+on the printing parameter setting. In the commands listed
+below, you will notice some parameters of the form %X where X is
+p, s, J, and so on. These letters stand for printer name, spoolfile and job ID, respectively.
+They are explained in more detail further below. presents an overview of key
+printing options but excludes the special case of CUPS that is discussed in .
+ Table 18.1. Default Printing Settings
+We excluded the special case of CUPS here, because it is discussed in the next chapter. For
+printing = CUPS, if Samba is compiled against libcups, it uses the CUPS API to submit
+jobs. (It is a good idea also to set printcap = cups
+in case your cupsd.conf is set to write its autogenerated printcap file to an
+unusual place). Otherwise, Samba maps to the System V printing commands with the -oraw option for printing,
+i.e., it uses lp -c -d%p -oraw; rm %s. With printing = cups,
+and if Samba is compiled against libcups, any manually set print command will be ignored!
+
+After a print job has finished spooling to a service, the print command
+ will be used by Samba via a system() call to process the
+spool file. Usually the command specified will submit the spool file to the host's printing subsystem. But
+there is no requirement at all that this must be the case. The print subsystem may not remove the spool
+file on its own. So whatever command you specify, you should ensure that the spool file is deleted after
+it has been processed.
-There is no difficulty with using your own customized print commands
-with the traditional printing systems. However, if you don't wish to
-"roll your own", you should be well informed about the default
-built-in commands that Samba uses for each printing subsystem (see the
-table above). In all the commands listed in the last paragraphs you
-see parameters of the form %X These are
-macros, or shortcuts, used as place holders for
-the names of real objects. At the time of running a command with such
-a placeholder, Samba will insert the appropriate value
-automatically. Print commands can handle all Samba macro
-substitutions. In regard to printing, the following ones do have
+There is no difficulty with using your own customized print commands with the traditional printing
+systems. However, if you do not wish to roll your own, you should be well informed about the default
+built-in commands that Samba uses for each printing subsystem (see
+Table 17.1). In all the
+commands listed in the last paragraphs, you see parameters of the form %X. These are
+macros, or shortcuts, used as placeholders for the names of real objects. At the time
+of running a command with such a placeholder, Samba will insert the appropriate value automatically. Print
+commands can handle all Samba macro substitutions. In regard to printing, the following ones do have
special relevance:
- %s, %f - the path to the spool
-file name %p - the appropriate printer
-name %J - the job name as
-transmitted by the client. %c - the number of printed
-pages of the spooled job (if known). %z - the size of the spooled
-print job (in bytes)
-The print command MUST contain at least one occurrence of
-%s or %f. -- The
-%p is optional. If no printer name is supplied,
-the %p will be silently removed from the print
-command. In this case the job is sent to the default printer.
+ %s, %f the path to the spool file name. %p the appropriate printer name. %J the job name as transmitted by the client. %c the number of printed pages of the spooled job (if known). %z the size of the spooled print job (in bytes).
+The print command must contain at least one occurrence of %s or
+the %f. The %p is optional. If no printer name is supplied,
+the %p will be silently removed from the print command. In this case, the job is
+sent to the default printer.
-If specified in the [global] section, the print
-command given will be used for any printable service that does not
-have its own print command specified. If there is neither a specified
-print command for a printable service nor a global print command,
-spool files will be created but not processed! And (most importantly):
-print files will not be removed, so they will start filling your Samba
-hard disk.
+If specified in the [global] section, the print command given will be
+used for any printable service that does not have its own print command specified. If there is neither a
+specified print command for a printable service nor a global print command, spool files will be created
+but not processed! Most importantly, print files will not be removed, so they will consume disk space.
-Note that printing may fail on some UNIXes from the "nobody"
-account. If this happens, create an alternative guest account and
-supply it with the privilege to print. Set up this guest account in
-the [global] section with the guest
-account parameter.
+Printing may fail on some UNIX systems when using the “nobody” account. If this happens, create an
+alternative guest account and give it the privilege to print. Set up this guest account in the
+[global] section with the guest account parameter.
-You can form quite complex print commands. You need to realize that
-print commands are just passed to a UNIX shell. The shell is able to
-expand the included environment variables as usual. (The syntax to
-include a UNIX environment variable $variable
-in or in the Samba print command is
-%$variable.) To give you a working
-print command example, the following will log a
-print job to /tmp/print.log, print the file, then
-remove it. Note that ';' is the usual separator for commands in shell
-scripts:
+You can form quite complex print commands. You need to realize that print commands are just
+passed to a UNIX shell. The shell is able to expand the included environment variables as
+usual. (The syntax to include a UNIX environment variable $variable
+in the Samba print command is %$variable.) To give you a working
+print command example, the following will log a print job
+to /tmp/print.log, print the file, then remove it. The semicolon (“;”
+is the usual separator for commands in shell scripts:
-You may have to vary your own command considerably from this example
-depending on how you normally print files on your system. The default
-for the print command parameter varies depending on the setting of
-the printing parameter. Another example is:
-
-Before version 2.2.0, Samba's print server support for Windows clients
-was limited to the level of LanMan printing
-calls. This is the same protocol level as Windows 9x PCs offer when
-they share printers. Beginning with the 2.2.0 release, Samba started
-to support the native Windows NT printing mechanisms. These are
-implemented via MS-RPC (RPC = Remote
-Procedure Calls ). MS-RPCs use the
-SPOOLSS named pipe for all printing.
+You may have to vary your own command considerably from this example depending on how you normally print
+files on your system. The default for the print command
+parameter varies depending on the setting of the printing
+parameter. Another example is:
+
+Prior to Samba-2.2.x, print server support for Windows clients was limited to LanMan
+printing calls. This is the same protocol level as Windows 9x/Me PCs offer when they share printers.
+Beginning with the 2.2.0 release, Samba started to support the native Windows NT printing mechanisms. These
+are implemented via MS-RPC (RPC = Remote Procedure Calls
+). MS-RPCs use the SPOOLSS named pipe for all printing.
The additional functionality provided by the new SPOOLSS support includes:
- Support for downloading printer driver files to Windows
-95/98/NT/2000 clients upon demand (Point'n'Print);
- Uploading of printer drivers via the Windows NT
-Add Printer Wizard (APW) or the
-Imprints tool set.
- Support for the native MS-RPC printing calls such as
- StartDocPrinter, EnumJobs(), etc... (See the MSDN documentation for more information on the Win32 printing API); Support for NT Access Control
-Lists (ACL) on printer objects; Improved support for printer queue manipulation
-through the use of internal databases for spooled job information
-(implemented by various *.tdb
-files).
-One other benefit of an update is this: Samba 3 is able to publish
-all its printers in Active Directory (or LDAP)!
+
+ Support for downloading printer driver files to Windows 95/98/NT/2000 clients upon
+ demand (Point'n'Print).
+
+ Uploading of printer drivers via the Windows NT Add Printer Wizard (APW)
+ or the
+ Support for the native MS-RPC printing calls such as
+ StartDocPrinter, EnumJobs(), and so on. (See the
+
+ Support for NT Access Control Lists (ACL) on printer objects.
+
+ Improved support for printer queue manipulation through the use of internal databases for spooled
+ job information (implemented by various *.tdb files).
+
+A benefit of updating is that Samba-3 is able to publish its printers to Active Directory (or LDAP).
+
+A fundamental difference exists between MS Windows NT print servers and Samba operation. Windows NT
+permits the installation of local printers that are not shared. This is an artifact of the fact that
+any Windows NT machine (server or client) may be used by a user as a workstation. Samba will publish all
+printers that are made available, either by default or by specific declaration via printer-specific shares.
-One slight difference is here: it is possible on a Windows NT print
-server to have printers listed in the Printers folder which are
-not shared. Samba does not make this
-distinction. By definition, the only printers of which Samba is aware
-are those which are specified as shares in
-. The reason is that Windows NT/200x/XP Professional
-clients do not normally need to use the standard SMB printer share;
-rather they can print directly to any printer on another Windows NT
-host using MS-RPC. This of course assumes that the printing client has
-the necessary privileges on the remote host serving the printer. The
-default permissions assigned by Windows NT to a printer gives the
-"Print" permissions to the well-known Everyone
-group. (The older clients of type Win9x can only print to "shared"
+Windows NT/200x/XP Professional clients do not have to use the standard SMB printer share; they can
+print directly to any printer on another Windows NT host using MS-RPC. This, of course, assumes that
+the client has the necessary privileges on the remote host that serves the printer resource. The
+default permissions assigned by Windows NT to a printer gives the Print permissions to the well-known
+Everyone group. (The older clients of type Windows 9x/Me can only print to shared
printers).
-
-There is still confusion about what all this means: Is it or
-is it not a requirement for printer drivers to be installed on a Samba
-host in order to support printing from Windows clients? The
-answer to this is: No, it is not a
-requirement. Windows NT/2000 clients can, of
-course, also run their APW to install drivers
-locally (which then connect to a Samba served
-print queue). This is the same method as used by Windows 9x
-clients. (However, a bug existed in Samba 2.2.0
-which made Windows NT/2000 clients require that the Samba server
-possess a valid driver for the printer. This was fixed in Samba
-2.2.1).
+
+There is much confusion about what all this means. The question is often asked, “Is it or is
+it not necessary for printer drivers to be installed on a Samba host in order to support printing from
+Windows clients?” The answer to this is no, it is not necessary.
+
+Windows NT/2000 clients can, of course, also run their APW to install drivers locally
+(which then connect to a Samba-served print queue). This is the same method used by Windows 9x/Me
+clients. (However, a bug existed in Samba 2.2.0 that made Windows NT/2000 clients
+require that the Samba server possess a valid driver for the printer. This was fixed in Samba 2.2.1).
+
+But it is a new capability to install the printer drivers into the [print$]
+share of the Samba server, and a big convenience, too. Then all clients
+(including 95/98/ME) get the driver installed when they first connect to this printer share. The
+uploading or depositing of the driver into this
+[print$] share and the following binding of this driver to an existing
+Samba printer share can be achieved by different means:
+
+ Running the APW on an NT/200x/XP Professional client (this does not work from 95/98/ME clients).
+
+ Using the Imprints toolset.
+
+ Using the smbclient and rpcclient commandline tools.
+
+ Using cupsaddsmb (only works for the CUPS
+ printing system, not for LPR/LPD, LPRng, and so on).
+
+Samba does not use these uploaded drivers in any way to process spooled files. These drivers are utilized
+entirely by the clients who download and install them via the “Point'n'Print” mechanism
+supported by Samba. The clients use these drivers to generate print files in the format the printer
+(or the UNIX print system) requires. Print files received by Samba are handed over to the UNIX printing
+system, which is responsible for all further processing, as needed.
+
+ Versions of Samba prior to 2.2 made it possible to use a share named
+ [printer$]. This name was taken from the same named service created by
+ Windows 9x/Me clients when a printer was shared by them. Windows 9x/Me printer servers always
+ have a [printer$] service that provides read-only access (with
+ no password required) to support printer driver downloads. However, Samba's initial
+ implementation allowed for a parameter named printer driver location to
+ be used on a per share basis. This specified the location of the driver files associated with
+ that printer. Another parameter named printer driver provided a means of
+ defining the printer driver name to be sent to the client.
+
+ These parameters, including the printer driver file parameter,
+ are now removed and cannot be used in installations of Samba-3. The share name
+ [print$] is now used for the location of downloadable printer
+ drivers. It is taken from the [print$] service created
+ by Windows NT PCs when a printer is shared by them. Windows NT print servers always have a
+ [print$] service that provides read-write access (in the context
+ of its ACLs) to support printer driver downloads and uploads. This does not mean Windows
+ 9x/Me clients are now thrown aside. They can use Samba's [print$]
+ share support just fine.
+
+In order to support the uploading and downloading of printer driver files, you must first configure a
+file share named [print$]. The public name of this share is hard coded
+in the MS Windows clients. It cannot be renamed since Windows clients are programmed to search for a
+service of exactly this name if they want to retrieve printer driver files.
+
+You should modify the server's file to add the global parameters and create the
+[print$] file share (of course, some of the parameter values, such
+as path are arbitrary and should be replaced with appropriate values for your
+site). See .
-But it is a new option to install the printer
-drivers into the [print$] share of the Samba
-server, and a big convenience too. Then all
-clients (including 95/98/ME) get the driver installed when they first
-connect to this printer share. The uploading or
-depositing of the driver into this
-[print$] share, and the following binding of
-this driver to an existing Samba printer share can be achieved by
-different means:
- running the APW on an
-NT/200x/XP Professional client (this doesn't work from 95/98/ME
-clients); using the Imprints
-toolset; using the smbclient and
-rpcclient commandline tools; using cupsaddsmb(only works for
-the CUPS printing system, not for LPR/LPD, LPRng
-etc.).
-Please take additional note of the following fact: Samba
-does not use these uploaded drivers in any way to process spooled
-files. Drivers are utilized entirely by the clients, who
-download and install them via the "Point'n'Print" mechanism supported
-by Samba. The clients use these drivers to generate print files in the
-format the printer (or the UNIX print system) requires. Print files
-received by Samba are handed over to the UNIX printing system, which
-is responsible for all further processing, if needed.
-
-[print$] vs. [printer$]
-.
-Versions of Samba prior to 2.2 made it possible to use a share
-named [printer$]. This name was taken from the
-same named service created by Windows 9x clients when a printer was
-shared by them. Windows 9x printer servers always have a
-[printer$] service which provides read-only
-access (with no password required) in order to support printer driver
-downloads. However, Samba's initial implementation allowed for a
-parameter named printer driver location to be
-used on a per share basis. This specified the location of the driver
-files associated with that printer. Another parameter named
-printer driver provided a means of defining the
-printer driver name to be sent to the client. These parameters,
-including the printer driver file parameter,
-are now removed and can not be used in installations of samba-3.
-Now the share name [print$] is used for the
-location of downloadable printer drivers. It is taken from the
-[print$] service created by Windows NT PCs when
-a printer is shared by them. Windows NT print servers always have a
-[print$] service which provides read-write
-access (in the context of its ACLs) in order to support printer driver
-down- and uploads. Don't fear -- this does not mean Windows 9x
-clients are thrown aside now. They can use Samba's
-[print$] share support just fine.
-
-In order to support the up- and downloading of printer driver files,
-you must first configure a file share named
-[print$]. The "public" name of this share is
-hard coded in Samba's internals (because it is hard coded in the MS
-Windows clients too). It cannot be renamed since Windows clients are
-programmed to search for a service of exactly this name if they want
-to retrieve printer driver files.
+ Example 18.3. [print\$] example
-You should modify the server's file to
-add the global parameters and create the
-[print$] file share (of course, some of the
-parameter values, such as 'path' are arbitrary and should be replaced
-with appropriate values for your site):
- Example 18.3. [print\$] example
Of course, you also need to ensure that the directory named by the
-path parameter exists on the UNIX file system.
-
-[print$] is a special section in
-. It contains settings relevant to
-potential printer driver download and local installation by clients.
- the comment appears next to the share name if it is
-listed in a share list (usually Windows clients won't see it often but
-it will also appear up in a smbclient -L sambaserver
- output). this is the path to the location of the Windows
-driver file deposit from the UNIX point of
-view. this makes the [print$] share
-"invisible" in Network Neighbourhood to clients. However, you can
-still "mount" it from any client using the net use
-g:\\sambaserver\print$ command in a "DOS box" or the
-"Connect network drive" menu from Windows
-Explorer. this gives read only access to this share for all
-guest users. Access may be used to download and install printer
-drivers on clients. The requirement for guest ok =
-yes depends upon how your site is configured. If users
-will be guaranteed to have an account on the Samba host, then this is
-a non-issue.
-The non-issue is this: if all your Windows NT users are guaranteed to
-be authenticated by the Samba server (for example if Samba
-authenticates via an NT domain server and the NT user has already been
-validated by the Domain Controller in order to logon to the Windows NT
-session), then guest access is not necessary. Of course, in a
-workgroup environment where you just want to be able to print without
-worrying about silly accounts and security, then configure the share
-for guest access. You'll probably want to add map to guest = Bad User in the
-[global] section
-as well. Make sure you understand what this parameter does before
-using it.
- as we don't want everybody to upload driver files (or
-even change driver settings) we tagged this share as not
-writeable. since the [print$] was made
-read only by the previous setting, we need to create a "write list"
-also. UNIX groups (denoted with a leading "@" character) and users
-listed here are allowed write access (as an exception to the general
-public's "read-only" access), which they need to update files on the
-share. Normally you will want to only name administrative level user
-accounts in this setting. Check the file system permissions to make
-sure these accounts can copy files to the share. If this is a non-root
-account, then the account should also be mentioned in the global
-printer admin parameter. See the
- man page for more information on
-configuring file shares.
-In order for a Windows NT print server to support the downloading of
-driver files by multiple client architectures, you must create several
-subdirectories within the [print$] service
-(i.e. the UNIX directory named by the path
-parameter). These correspond to each of the supported client
-architectures. Samba follows this model as well. Just like the name of
-the [print$] share itself, the subdirectories
-*must* be exactly the names listed below (you may leave out the
-subdirectories of architectures you don't want to support).
+path parameter exists on the UNIX file system.
+
+The [print$] is a special section in smb.conf. It contains settings relevant to
+potential printer driver download and is used by windows clients for local print driver installation.
+The following parameters are frequently needed in this share section:
+
+ The comment appears next to the share name if it is listed in a share list (usually Windows
+ clients will not see it, but it will also appear up in a smbclient -L sambaserver
+ output).
+
+ Is the path to the location of the Windows driver file deposit from the UNIX point of view.
+
+ Makes the [print$] share invisible to clients from the
+
+ Gives read-only access to this share for all guest users. Access may be granted to
+ download and install printer drivers on clients. The requirement for guest ok
+ = yes depends on how your site is configured. If users will be guaranteed
+ to have an account on the Samba host, then this is a non-issue.
+
+ If all your Windows NT users are guaranteed to be authenticated by the Samba server
+ (for example, if Samba authenticates via an NT domain server and the user has already been
+ validated by the Domain Controller in order to logon to the Windows NT session), then guest
+ access is not necessary. Of course, in a workgroup environment where you just want
+ to print without worrying about silly accounts and security, then configure the share for
+ guest access. You should consider adding map to guest = Bad
+ User in the [global] section
+ as well. Make sure you understand what this parameter does before using it.
+
+ Because we do not want everybody to upload driver files (or even change driver settings),
+ we tagged this share as not writeable.
+
+ The [print$] was made read-only by the previous
+ setting so we should create a write list entry also. UNIX
+ groups (denoted with a leading “@” character). Users listed here are allowed
+ write-access (as an exception to the general public's read-only access), which they need to
+ update files on the share. Normally, you will want to only name administrative-level user
+ account in this setting. Check the file system permissions to make sure these accounts
+ can copy files to the share. If this is a non-root account, then the account should also
+ be mentioned in the global printer admin
+ parameter. See the smb.conf man page for more information on configuring file shares.
+
+In order for a Windows NT print server to support the downloading of driver files by multiple client
+architectures, you must create several subdirectories within the [print$]
+service (i.e., the UNIX directory named by the path
+parameter). These correspond to each of the supported client architectures. Samba follows this model as
+well. Just like the name of the [print$] share itself, the subdirectories
+must be exactly the names listed below (you may leave out the subdirectories of architectures you do
+not need to support).
Therefore, create a directory tree below the
[print$] share for each architecture you wish
-to support.
+to support like this:
-In order to add a new driver to your Samba host, one of two conditions
-must hold true:
- The account used to connect to the Samba host must
-have a UID of 0 (i.e. a root account) The account used to connect to the Samba host must be
-named in the printer adminlist.
-Of course, the connected account must still possess access to add
-files to the subdirectories beneath
-[print$]. Remember that all file shares are set
-to 'read only' by default.
-
-Once you have created the required [print$]
-service and associated subdirectories, go to a Windows NT 4.0/2k/XP
-client workstation. Open Network Neighbourhood or
-My Network Places and browse for the Samba host.
-Once you have located the server, navigate to its Printers and
-Faxes folder. You should see an initial listing of printers
-that matches the printer shares defined on your Samba host.
-
-You have successfully created the [print$]
-share in ? And Samba has re-read its
-configuration? Good. But you are not yet ready to take off. The
-driver files need to be present in this share,
-too! So far it is still an empty share. Unfortunately, it is not enough
-to just copy the driver files over. They need to be set
-up too. And that is a bit tricky, to say the least. We
-will now discuss two alternative ways to install the drivers into
-[print$]:
- using the Samba commandline utility
-rpcclient with its various subcommands (here:
-adddriver and setdriver) from
-any UNIX workstation; running a GUI (Printer
-Properties and Add Printer Wizard)
-from any Windows NT/2k/XP client workstation.
-The latter option is probably the easier one (even if the only
-entrance to this realm seems a little bit weird at first).
-
-The initial listing of printers in the Samba host's
-Printers folder accessed from a client's Explorer
-will have no real printer driver assigned to them. By default
-this driver name is set to a NULL
-string. This must be changed now. The local Add Printer
-Wizard, run from NT/2000/XP clients, will help us in this
-task.
+[print$]--+
+ |--W32X86 # serves drivers to Windows NT x86
+ |--WIN40 # serves drivers to Windows 95/98
+ |--W32ALPHA # serves drivers to Windows NT Alpha_AXP
+ |--W32MIPS # serves drivers to Windows NT R4000
+ |--W32PPC # serves drivers to Windows NT PowerPC
+
+
+ In order to add a new driver to your Samba host, one of two conditions must hold true:
+
+ The account used to connect to the Samba host must have a UID of 0 (i.e., a root account).
+
+ The account used to connect to the Samba host must be named in the printer adminlist.
+
+ Of course, the connected account must still have write access to add files to the subdirectories beneath
+ [print$]. Remember that all file shares are set to “read-only” by default.
+
+Once you have created the required [print$] service and
+associated subdirectories, go to a Windows NT 4.0/200x/XP client workstation. Open Network
+Neighborhood or My Network Places and browse for the Samba host. Once you
+have located the server, navigate to its Printers and Faxes folder. You should see
+an initial listing of printers that matches the printer shares defined on your Samba host.
+
+Have you successfully created the [print$] share in smb.conf, and have your forced Samba
+to re-read its smb.conf file? Good. But you are not yet ready to use the new facility. The client driver
+files need to be installed into this share. So far it is still an empty share. Unfortunately, it is
+not enough to just copy the driver files over. They need to be
+correctly installed so that appropriate
+records for each driver will exist in the Samba internal databases so it can provide the correct
+drivers as they are requested from MS Windows clients. And that is a bit tricky, to say the least. We
+now discuss two alternative ways to install the drivers into [print$]:
+
+ Using the Samba commandline utility rpcclient with its various subcommands (here:
+ adddriver and setdriver) from any UNIX workstation.
+
+ Running a GUI (Printer Properties and Add Printer Wizard)
+ from any Windows NT/200x/XP client workstation.
+
+The latter option is probably the easier one (even if the process may seem a little bit weird at first).
+
+The initial listing of printers in the Samba host's Printers folder accessed from a
+client's Explorer will have no real printer driver assigned to them. By default this driver name is set
+to a null string. This must be changed now. The local Add Printer Wizard (APW), run from
+NT/2000/XP clients, will help us in this task.
-However, the job to set a valid driver for the printer is not a
-straightforward one: You must attempt to view the printer properties
-for the printer to which you want the driver assigned. Open the
-Windows Explorer, open Network Neighbourhood, browse to the Samba
-host, open Samba's Printers folder, right-click the printer icon and
-select . You are now trying to view printer and driver
-properties for a queue which has this default NULL driver
-assigned. This will result in an error message (this is normal here):
- Device settings cannot be displayed. The driver
-for the specified printer is not installed, only spooler properties
-will be displayed. Do you want to install the driver
-now?
-Important:Don't click ! Instead,
-click in the error dialog.
-Only now you will be presented with the printer properties window. From here,
-the way to assign a driver to a printer is open to us. You have now the choice
-either:
- select a driver from the pop-up list of installed
-drivers. Initially this list will be empty.
-Or use the
-Once the APW is started, the procedure is exactly the same as the one
-you are familiar with in Windows (we assume here that you are
-familiar with the printer driver installations procedure on Windows
-NT). Make sure your connection is in fact setup as a user with
-printer admin privileges (if in doubt, use
-smbstatus to check for this). If you wish to
-install printer drivers for client operating systems other than
-Windows NT x86, you will need to use the
-Sharing tab of the printer properties dialog.
+Installation of a valid printer driver is not straightforward. You must attempt
+to view the printer properties for the printer to which you want the driver assigned. Open the Windows
+Explorer, open Network Neighborhood, browse to the Samba host, open Samba's Printers
+folder, right-click on the printer icon and select . You are now trying to
+view printer and driver properties for a queue that has this default NULL driver
+assigned. This will result in the following error message:
+
+ Device settings cannot be displayed. The driver for the specified printer is not installed,
+ only spooler properties will be displayed. Do you want to install the driver now?
+
+Do not click on
+ Select a driver from the pop-up list of installed drivers. Initially this list will be empty.
+
+ Click on
+Once the APW is started, the procedure is exactly the same as the one you are familiar with in Windows (we
+assume here that you are familiar with the printer driver installations procedure on Windows NT). Make sure
+your connection is, in fact, setup as a user with printer admin
+privileges (if in doubt, use smbstatus to check for this). If you wish to install
+printer drivers for client operating systems other than Windows NT x86,
+you will need to use the Sharing tab of the printer properties dialog.
-Assuming you have connected with an administrative (or root) account
-(as named by the printer admin parameter),
-you will also be able to modify other printer properties such as ACLs
-and default device settings using this dialog. For the default device
-settings, please consider the advice given further below.
-
-The second way to install printer drivers into
-[print$] and set them up in a valid way can be
-done from the UNIX command line. This involves four distinct steps:
- gathering the info about the required driver files
-and collecting the files together; deposit the driver files into the
-[print$] share's correct subdirectories
-(possibly by using smbclient); running the rpcclient
-commandline utility once with the adddriver
-subcommand, running rpcclient a second
-time with the setdriver
-subcommand.
-We will provide detailed hints for each of these steps in the next few
-paragraphs.
-
-To find out about the driver files, you have two options: you could
-investigate the driver CD which comes with your printer. Study the
-*.inf file on the CD, if it is contained. This
-may not be the possible, since the *.inf file might be
-missing. Unfortunately, many vendors have now started to use their own
-installation programs. These installations packages are often some
-sort of Windows platform archive format, plus, the files may get
-re-named during the installation process. This makes it extremely
-difficult to identify the driver files you need.
+Assuming you have connected with an administrative (or root) account (as named by the
+printer admin parameter), you will also be able to modify
+other printer properties such as ACLs and default device settings using this dialog. For the default
+device settings, please consider the advice given further in .
+
+The second way to install printer drivers into [print$] and set them
+up in a valid way is to do it from the UNIX command line. This involves four distinct steps:
+
+ Gather info about required driver files and collect the files.
+
+ Deposit the driver files into the [print$] share's correct subdirectories
+ (possibly by using smbclient).
+
+ Run the rpcclient command line utility once with the adddriver
+ subcommand.
+
+ Run rpcclient a second time with the setdriver subcommand.
+
+We provide detailed hints for each of these steps in the paragraphs that follow.
+
+To find out about the driver files, you have two options. You could check the contents of the driver
+CDROM that came with your printer. Study the *.inf files lcoated on the CDROM. This
+may not be possible, since the *.inf file might be missing. Unfortunately, vendors have now started
+to use their own installation programs. These installations packages are often in some Windows platform
+archive format. Additionally, the files may be re-named during the installation process. This makes it
+extremely difficult to identify the driver files required.
-Then you only have the second option: install the driver first on a
-Windows client *locally* and investigate which file names and paths it
-uses after they are installed. (Note, that you need to repeat this
-procedure for every client platform you want to support. We are going
-to show it here for the W32X86 platform only, a
-name used by Microsoft for all WinNT/2k/XP clients...)
+Then you only have the second option. Install the driver locally on a Windows client and
+investigate which file names and paths it uses after they are installed. (You need to repeat
+this procedure for every client platform you want to support. We show it here for the
+W32X86 platform only, a name used by Microsoft for all Windows NT/200x/XP
+clients.)
-A good method to recognize the driver files this is to print the test
-page from the driver's Properties Dialog
-(General tab). Then look at the list of driver
-files named on the printout. You'll need to recognize what Windows
-(and Samba) are calling the Driver File , the
-Data File, the Config File,
-the Help File and (optionally) the
-Dependent Driver Files (this may vary slightly
-for Windows NT). You need to remember all names (or better take a
-note) for the next steps.
+A good method to recognize the driver files is to print the test page from the driver's
+Properties dialog (General tab). Then look at the list of
+driver files named on the printout. You'll need to recognize what Windows (and Samba) are calling the
+Driver File, Data File, Config File,
+Help File and (optionally) the Dependent Driver Files
+(this may vary slightly for Windows NT). You need to take a note of all file names for the next steps.
-Another method to quickly test the driver filenames and related paths
-is provided by the rpcclient utility. Run it with
-enumdrivers or with the
-getdriver subcommand, each in the
-3 level. In the following example,
-TURBO_XP is the name of the Windows PC (in this
-case it was a Windows XP Professional laptop, BTW). I had installed
-the driver locally to TURBO_XP while kde-bitshop is
-the name of the Linux host from which I am working. We could run an
-interactive rpcclient session;
-then we'd get an rpcclient /> prompt and would
-type the subcommands at this prompt. This is left as a good exercise
-to the reader. For now we use rpcclient with the
--c parameter to execute a single subcommand
-line and exit again. This is the method you would use if you want to
-create scripts to automate the procedure for a large number of
-printers and drivers. Note the different quotes used to overcome the
-different spaces in between words:
+Another method to quickly test the driver filenames and related paths is provided by the
+rpcclient utility. Run it with enumdrivers or with the
+getdriver subcommand, each at the 3 info level. In the following example,
+TURBO_XP is the name of the Windows PC (in this case it was a Windows XP Professional
+laptop). I installed the driver locally to TURBO_XP, from a Samba server called KDE-BITSHOP.
+We could run an interactive rpcclient session; then we would get an
+rpcclient /> prompt and would type the subcommands at this prompt. This is left as
+a good exercise to the reader. For now, we use rpcclient with the -c
+parameter to execute a single subcommand line and exit again. This is the method you would use if you
+want to create scripts to automate the procedure for a large number of printers and drivers. Note the
+different quotes used to overcome the different spaces in between words:
-You may notice, that this driver has quite a big number of
-Dependentfiles (I know worse cases however). Also,
-strangely, the Driver File is here tagged as
-Driver Path.... oh, well. Here we don't have yet
-support for the so-called WIN40 architecture
-installed. This name is used by Microsoft for the Win95/98/ME platforms.
-If we want to support these, we need to install the Win95/98/ME driver
-files in addition to those for W32X86
-(i.e. the WinNT72000/XP clients) onto a Windows PC. This PC
-can also host the Win9x drivers, even if itself runs on Windows NT,
-2000 or XP.
+You may notice that this driver has quite a large number of Dependent files
+(there are worse cases, however). Also, strangely, the
+Driver File is tagged here
+Driver Path. We do not yet have support for the so-called
+WIN40 architecture installed. This name is used by Microsoft for the Windows
+9x/Me platforms. If we want to support these, we need to install the Windows 9x/Me driver files in
+addition to those for W32X86 (i.e., the Windows NT72000/XP clients) onto a
+Windows PC. This PC can also host the Windows 9x/Me drivers, even if it runs on Windows NT, 2000 or XP.
-Since the [print$] share is usually accessible
-through the Network Neighbourhood, you can also use the UNC notation
-from Windows Explorer to poke at it. The Win9x driver files will end
-up in subdirectory "0" of the "WIN40" directory. The full path to
-access them will be
-\\WINDOWSHOST\print$\WIN40\0\.
- more recent drivers on Windows 2000 and Windows XP are
-installed into the "3" subdirectory instead of the "2". The version 2
-of drivers, as used in Windows NT, were running in Kernel Mode.
-Windows 2000 changed this. While it still can use the Kernel Mode
-drivers (if this is enabled by the Admin), its native mode for printer
-drivers is User Mode execution. This requires drivers designed for
-this. These type of drivers install into the "3" subdirectory.
-
-Now we need to collect all the driver files we identified. in our
-previous step. Where do we get them from? Well, why not retrieve them
-from the very PC and the same [print$] share
-which we investigated in our last step to identify the files? We can
-use smbclient to do this. We will use the paths and
-names which were leaked to us by getdriver. The
+Since the [print$] share is usually accessible through the Network
+Neighborhood, you can also use the UNC notation from Windows Explorer to poke at it. The Windows
+9x/Me driver files will end up in subdirectory 0 of the WIN40
+directory. The full path to access them will be \\WINDOWSHOST\print$\WIN40\0\.
+
+More recent drivers on Windows 2000 and Windows XP are installed into the “3” subdirectory
+instead of the “2”. The version 2 of drivers, as used in Windows NT, were running in Kernel
+Mode. Windows 2000 changed this. While it still can use the Kernel Mode drivers (if this is enabled by
+the Admin), its native mode for printer drivers is User Mode execution. This requires drivers designed
+for this. These types of drivers install into the “3” subdirectory.
+
+Now we need to collect all the driver files we identified in our previous step. Where do we get them
+from? Well, why not retrieve them from the very PC and the same [print$]
+share that we investigated in our last step to identify the files? We can use smbclient
+to do this. We will use the paths and names that were leaked to us by getdriver. The
listing is edited to include linebreaks for readability:
-After this command is complete, the files are in our current local
-directory. You probably have noticed that this time we passed several
-commands to the -c parameter, separated by semi-colons. This
-effects that all commands are executed in sequence on the remote
-Windows server before smbclient exits again.
+After this command is complete, the files are in our current local directory. You probably have noticed
+that this time we passed several commands to the -c parameter, separated by semi-colons.
+This effects that all commands are executed in sequence on the remote Windows server before smbclient
+exits again.
-Don't forget to repeat the procedure for the WIN40
-architecture should you need to support Win95/98/XP clients. Remember, the
-files for these architectures are in the WIN40/0/ subdir. Once we are
-complete, we can run smbclient ... put to store
-the collected files on the Samba server's
-[print$] share.
-
-So, now we are going to put the driver files into the
-[print$] share. Remember, the UNIX path to this
-share has been defined previously in your
-. You also have created subdirectories
-for the different Windows client types you want to support. Supposing
-your [print$] share maps to the UNIX path
-/etc/samba/drivers/, your driver files should now
-go here:
- for all Windows NT, 2000 and XP clients into
-/etc/samba/drivers/W32X86/ but
-*not*(yet) into the "2" subdir! for all Windows 95, 98 and ME clients into
-/etc/samba/drivers/WIN40/ -- but *not*
-(yet) into the "0" subdir!
-We again use smbclient to transfer the driver files across the
-network. We specify the same files and paths as were leaked to us by
-running getdriver against the original
-Windows install. However, now we are going to
-store the files into a Samba/UNIX print server's
-[print$] share...
+Remember to repeat the procedure for the WIN40 architecture should
+you need to support Windows 9x/Me/XP clients. Remember too, the files for these architectures are in the
+WIN40/0/ subdirectory. Once this is complete, we can run smbclient ...
+put to store the collected files on the Samba server's [print$]
+share.
+
+We are now going to locate the driver files into the [print$]
+share. Remember, the UNIX path to this share has been defined
+previously in your words missing here. You
+also have created subdirectories for the different Windows client types you want to
+support. Supposing your [print$] share maps to the UNIX path
+/etc/samba/drivers/, your driver files should now go here:
+
+ For all Windows NT, 2000 and XP clients into /etc/samba/drivers/W32X86/ but
+ not (yet) into the 2 subdirectory.
+
+ For all Windows 95, 98 and ME clients into /etc/samba/drivers/WIN40/ but not
+ (yet) into the 0 subdirectory.
+
+We again use smbclient to transfer the driver files across the network. We specify the same files
+and paths as were leaked to us by running getdriver against the original
+Windows install. However, now we are going to store the files into a
+Samba/UNIX print server's [print$] share.
-Phewww -- that was a lot of typing! Most drivers are a lot smaller --
-many only having 3 generic PostScript driver files plus 1 PPD. Note,
-that while we did retrieve the files from the "2" subdirectory of the
-"W32X86" directory from the Windows box, we don't
-put them (for now) in this same subdirectory of the Samba box! This
-re-location will automatically be done by the
-adddriver command which we will run shortly (and
-don't forget to also put the files for the Win95/98/ME architecture
-into the WIN40/ subdirectory should you need
-them).
-
-For now we verify that our files are there. This can be done with
-smbclient too (but of course you can log in via SSH
-also and do this through a standard UNIX shell access too):
+
+Whew that was a lot of typing! Most drivers are a lot smaller many only having three generic
+PostScript driver files plus one PPD. While we did retrieve the files from the 2
+subdirectory of the W32X86 directory from the Windows box, we do not put them
+(for now) in this same subdirectory of the Samba box. This relocation will automatically be done by the
+adddriver command, which we will run shortly (and do not forget to also put the files
+for the Windows 9x/Me architecture into the WIN40/ subdirectory should you need them).
+
+For now we verify that our files are there. This can be done with smbclient, too
+(but, of course, you can log in via SSH also and do this through a standard UNIX shell access):
-Notice that there are already driver files present in the
-2 subdir (probably from a previous
-installation). Once the files for the new driver are there too, you
-are still a few steps away from being able to use them on the
-clients. The only thing you could do *now* is to retrieve them from a
-client just like you retrieve ordinary files from a file share, by
-opening print$ in Windows Explorer. But that wouldn't install them per
-Point'n'Print. The reason is: Samba doesn't know yet that these files
-are something special, namely printer driver
-files and it doesn't know yet to which print queue(s) these
-driver files belong.
-
-So, next you must tell Samba about the special category of the files
-you just uploaded into the [print$] share. This
-is done by the adddriver command. It will
-prompt Samba to register the driver files into its internal TDB
-database files. The following command and its output has been edited,
-again, for readability:
+Notice that there are already driver files present in the 2 subdirectory (probably
+from a previous installation). Once the files for the new driver are there too, you are still a few
+steps away from being able to use them on the clients. The only thing you could do now is to retrieve
+them from a client just like you retrieve ordinary files from a file share, by opening print$ in Windows
+Explorer. But that wouldn't install them per Point'n'Print. The reason
+is: Samba does not yet know that
+these files are something special, namely printer driver files and it does not know
+to which print queue(s) these driver files belong.
+
+Next, you must tell Samba about the special category of the files you just uploaded into the
+[print$] share. This is done by the adddriver
+command. It will prompt Samba to register the driver files into its internal TDB database files. The
+following command and its output has been edited, again, for readability:
-After this step the driver should be recognized by Samba on the print
-server. You need to be very careful when typing the command. Don't
-exchange the order of the fields. Some changes would lead to a
-NT_STATUS_UNSUCCESSFUL error
-message. These become obvious. Other changes might install the driver
-files successfully, but render the driver unworkable. So take care!
-Hints about the syntax of the adddriver command are in the man
-page. The CUPS printing chapter of this HOWTO collection provides a
-more detailed description, if you should need it.
-
-One indication for Samba's recognition of the files as driver files is
-the successfully installed message.
-Another one is the fact, that our files have been moved by the
-adddriver command into the 2
-subdirectory. You can check this again with
-smbclient:
+After this step, the driver should be recognized by Samba on the print server. You need to be very
+careful when typing the command. Don't exchange the order of the fields. Some changes would lead to
+an NT_STATUS_UNSUCCESSFUL error message. These become obvious. Other
+changes might install the driver files successfully, but render the driver unworkable. So take care!
+Hints about the syntax of the adddriver command are in the man page. The CUPS printing chapter
+provides a more detailed description, should you need it.
+
+One indication for Samba's recognition of the files as driver files is the successfully
+installed message. Another one is the fact that our files have been moved by the
+adddriver command into the 2 subdirectory. You can check this
+again with smbclient:
-Another verification is that the timestamp of the printing TDB files
-is now updated (and possibly their filesize has increased).
-
-Now the driver should be registered with Samba. We can easily verify
-this, and will do so in a moment. However, this driver is
-not yet associated with a particular
-printer. We may check the driver status of the
-files by at least three methods:
- from any Windows client browse Network Neighbourhood,
-find the Samba host and open the Samba Printers and
-Faxes folder. Select any printer icon, right-click and
-select the printer . Click on the
-Advanced tab. Here is a field indicating the
-driver for that printer. A drop down menu allows you to change that
-driver (be careful to not do this unwittingly.). You can use this
-list to view all drivers know to Samba. Your new one should be amongst
-them. (Each type of client will only see his own architecture's
-list. If you don't have every driver installed for each platform, the
-list will differ if you look at it from Windows95/98/ME or
-WindowsNT/2000/XP.) from a Windows 2000 or XP client (not WinNT) browse
-Network Neighbourhood, search for the Samba
-server and open the server's Printers folder,
-right-click the white background (with no printer highlighted). Select
- . On the
-Drivers tab you will see the new driver listed
-now. This view enables you to also inspect the list of files belonging
-to that driver (this doesn't work on Windows NT, but only on
-Windows 2000 and Windows XP. WinNT doesn't provide the "Drivers"
-tab).. An alternative, much quicker method for Windows
-2000/XP to start this dialog is by typing into a DOS box (you must of
-course adapt the name to your Samba server instead of SAMBA-CUPS):
- rundll32 printui.dll,PrintUIEntry /s /t2 /n\\SAMBA-CUPS from a UNIX prompt run this command (or a variant
-thereof), where SAMBA-CUPS is the name of the Samba
-host and "xxxx" represents the actual Samba password assigned to root:
- rpcclient -U'root%xxxx' -c 'enumdrivers' SAMBA-CUPS
-You will see a listing of all drivers Samba knows about. Your new one
-should be amongst them. But it is only listed under the [Windows NT
-x86] heading, not under [Windows 4.0],
-since we didn't install that part. Or did *you*? -- You will see a listing of
-all drivers Samba knows about. Your new one should be amongst them. In our
-example it is named dm9110. Note that the 3rd column
-shows the other installed drivers twice, for each supported architecture one
-time. Our new driver only shows up for
-Windows NT 4.0 or 2000. To
-have it present for Windows 95, 98 and ME you'll
-have to repeat the whole procedure with the WIN40 architecture and subdirectory.
-
-You can name the driver as you like. If you repeat the
-adddriver step, with the same files as before, but
-with a different driver name, it will work the same:
+Another verification is that the timestamp of the printing TDB files is now updated
+(and possibly their file size has increased).
+
+Now the driver should be registered with Samba. We can easily verify this, and will do so in a
+moment. However, this driver is not yet associated with a particular printer. We may check the driver
+status of the files by at least three methods:
+
+ From any Windows client browse Network Neighborhood, find the Samba host and open the Samba
+ Printers and Faxes folder. Select any printer icon, right-click and select
+ the printer . Click the Advanced
+ tab. Here is a field indicating the driver for that printer. A drop-down menu allows you to
+ change that driver (be careful not to do this unwittingly). You can use this list to view
+ all drivers known to Samba. Your new one should be among them. (Each type of client will only
+ see his own architecture's list. If you do not have every driver installed for each platform,
+ the list will differ if you look at it from Windows95/98/ME or WindowsNT/2000/XP.)
+
+ From a Windows 200x/XP client (not Windows NT) browse Network Neighborhood,
+ search for the Samba server and open the server's Printers folder,
+ right-click on the white background (with no printer highlighted). Select . On the Drivers tab you will see the new driver
+ listed. This view enables you to also inspect the list of files belonging to that driver
+ (this does not work on Windows NT, but only on Windows 2000 and Windows XP; Windows NT does not
+ provide the tab). An
+ alternative and much quicker method for
+ Windows 2000/XP to start this dialog is by typing into a DOS box (you must of course adapt the
+ name to your Samba server instead of SAMBA-CUPS):
+ rundll32 printui.dll,PrintUIEntry /s /t2 /n\\SAMBA-CUPS
+ From a UNIX prompt, run this command (or a variant thereof) where
+ SAMBA-CUPS is the name of the Samba host and xxxx represents the
+ actual Samba password assigned to root:
+ rpcclient -U'root%xxxx' -c 'enumdrivers' SAMBA-CUPS
+ You will see a listing of all drivers Samba knows about. Your new one should be among
+ them. But it is only listed under the [Windows NT x86] heading, not under
+ [Windows 4.0], since you didn't install that part. Or did you?
+ You will see a listing of all drivers Samba knows about. Your new one should be among them. In
+ our example it is named dm9110. Note that the third column shows the other
+ installed drivers twice, one time for each supported architecture. Our new driver only shows up
+ for Windows NT 4.0 or 2000. To have it present for Windows
+ 95, 98 and ME, you'll have to repeat the whole procedure with the WIN40 architecture
+ and subdirectory.
+
+You can name the driver as you like. If you repeat the adddriver step with the same
+files as before but with a different driver name, it will work the same:
-You will also be able to bind that driver to any print queue (however,
-you are responsible yourself that you associate drivers to queues
-which make sense to the target printer). Note, that you can't run the
-rpcclient adddriver command
-repeatedly. Each run "consumes" the files you had put into the
-[print$] share by moving them into the
-respective subdirectories. So you must precede an
-smbclient ... put command before each
-rpcclient ... adddriver" command.
-
-Samba still needs to know which printer's driver
-this is. It needs to create a mapping of the driver to a printer, and
-store this info in its "memory", the TDB files. The rpcclient
-setdriver command achieves exactly this:
+You will be able to bind that driver to any print queue (however, you are responsible that
+you associate drivers to queues that make sense with respect to target printers). You cannot run the
+rpcclient adddriver command repeatedly. Each run consumes the
+files you had put into the [print$] share by moving them into the
+respective subdirectories. So you must execute an smbclient ... put command before
+each rpcclient ... adddriver command.
+
+Samba needs to know which printer owns which driver. Create a mapping of the driver to a printer, and
+store this info in Samba's memory, the TDB files. The rpcclient setdriver command
+achieves exactly this:
-Ahhhhh -- no, I didn't want to do that. Repeat, this time with the
-name I intended:
+Ah, no, I did not want to do that. Repeat, this time with the name I intended:
+The syntax of the command is:
+
-The syntax of the command is rpcclient
--U'root%sambapassword' -c 'setdriver
-"printername"
-"drivername'
-SAMBA-Hostname . --
-Now we have done *most* of the work. But not yet all....
+Now we have done most of the work, but not all of it.
-the setdriver command will only succeed if the printer is
-known to
-Samba already. A bug in 2.2.x prevented Samba from recognizing freshly
-installed printers. You had to restart Samba, or at least send a HUP
-signal to all running smbd processes to work around this:
-kill -HUP `pidof smbd`.
-A famous philosopher said once: “The Proof of the Pudding lies
-in the Eating”. The proof for our setup lies in the printing.
-So let's install the printer driver onto the client PCs. This is not
-as straightforward as it may seem. Read on.
-
-Especially important is the installation onto the first client PC (for
-each architectural platform separately). Once this is done correctly,
-all further clients are easy to setup and shouldn't need further
-attention. What follows is a description for the recommended first
-procedure. You work now from a client workstation. First you should
-guarantee that your connection is not unwittingly mapped to
-bad user "nobody". In a DOS box type:
+The setdriver command will only succeed if the
+printer is already known to Samba. A
+bug in 2.2.x prevented Samba from recognizing freshly installed printers. You had to restart Samba,
+or at least send an HUP signal to all running smbd processes to work around this: kill -HUP
+`pidof smbd`.
+
+As Don Quixote said: “The proof of the pudding is in the eating.” The proof
+for our setup lies in the printing. So let's install the printer driver onto the client PCs. This is
+not as straightforward as it may seem. Read on.
+
+Especially important is the installation onto the first client PC (for each architectural platform
+separately). Once this is done correctly, all further clients are easy to setup and shouldn't need further
+attention. What follows is a description for the recommended first procedure. You work now from a client
+workstation. You should guarantee that your connection is not unwittingly mapped to bad
+user nobody. In a DOS box type:
net use \\SAMBA-SERVER\print$ /user:root
-Replace root, if needed, by another valid
-printer admin user as given in the definition.
-Should you already be connected as a different user, you'll get an error
-message. There is no easy way to get rid of that connection, because
-Windows doesn't seem to know a concept of "logging off" from a share
-connection (don't confuse this with logging off from the local
-workstation; that is a different matter). You can try to close
-all Windows file explorer and Internet Explorer
-windows. As a last resort, you may have to reboot. Make sure there is
-no automatic re-connection set up. It may be easier to go to a
-different workstation and try from there. After you have made sure you
-are connected as a printer admin user (you can check this with the
-smbstatus command on Samba) do this from the
-Windows workstation:
- Open Network
-Neighbourhood Browse to Samba server Open its Printers and
-Faxes folder Highlight and right-click the printer Select
-A new printer (named printername on
-samba-server) should now have appeared in your
-local Printer folder (check --
- --
--- Printers and Faxes).
+Replace root, if needed, by another valid printer admin user as given in
+the definition. Should you already be connected as a different user, you will get an error message. There
+is no easy way to get rid of that connection, because Windows does not seem to know a concept of logging
+off from a share connection (do not confuse this with logging off from the local workstation; that is
+a different matter). You can try to close all Windows file explorer
+and Internet Explorer for Windows. As
+a last resort, you may have to reboot. Make sure there is no automatic reconnection set up. It may be
+easier to go to a different workstation and try from there. After you have made sure you are connected
+as a printer admin user (you can check this with the smbstatus command on Samba),
+do this from the Windows workstation:
+
+ Open Network Neighborhood.
+
+ Browse to Samba server.
+
+ Open its Printers and Faxes folder.
+
+ Highlight and right-click on the printer.
+
+ Select
+A new printer (named printername on Samba-server) should now have
+appeared in your local Printer folder (check --
+ -- -- Printers
+and Faxes).
-Most likely you are now tempted to try and print a test page. After
-all, you now can open the printer properties and on the "General" tab,
-there is a button offering to do just that. But chances are that you
-get an error message saying Unable to print Test
-Page. The reason might be that there is not yet a
-valid Device Mode set for the driver, or that the "Printer Driver
-Data" set is still incomplete.
+Most likely you are now tempted to try to print a test page. After all, you now can open the printer
+properties, and on the tab there is a button offering to do just that. But
+chances are that you get an error message saying Unable to print Test Page. The
+reason might be that there is not yet a valid Device Mode set for the driver, or that the “Printer
+Driver Data” set is still incomplete.
-You must now make sure that a valid "Device Mode" is set for the
-driver. Don't fear -- we will explain now what that means.
-
-In order for a printer to be truly usable by a Windows NT/2K/XP
-client, it must possess:
- a valid Device Mode generated by
-the driver for the printer (defining things like paper size,
-orientation and duplex settings), and a complete set of
-Printer Driver Data generated by the
-driver.
-If either one of these is incomplete, the clients can produce less
-than optimal output at best. In the worst cases, unreadable garbage or
-nothing at all comes from the printer or they produce a harvest of
-error messages when attempting to print. Samba stores the named values
-and all printing related info in its internal TDB database files
-(ntprinters.tdb,
-ntdrivers.tdb, printing.tdb
-and ntforms.tdb).
+You must make sure that a valid Device Mode is set for the
+driver. We now explain what that means.
+
+For a printer to be truly usable by a Windows NT/200x/XP client, it must possess:
+
+ A valid Device Mode generated by the driver for the printer (defining things
+ like paper size, orientation and duplex settings).
+
+ A complete set of Printer Driver Data generated by the driver.
+
+If either of these is incomplete, the clients can produce less than optimal output at best. In the
+worst cases, unreadable garbage or nothing at all comes from the printer or it produces a harvest of
+error messages when attempting to print. Samba stores the named values and all printing related information in
+its internal TDB database files (ntprinters.tdb, ntdrivers.tdb,
+printing.tdb and ntforms.tdb).
-What do these two words stand for? Basically, the Device Mode and the
-set of Printer Driver Data is a collection of settings for all print
-queue properties, initialized in a sensible way. Device Modes and
-Printer Driver Data should initially be set on the print server (that is
-here: the Samba host) to healthy values so that the clients can start
-to use them immediately. How do we set these initial healthy values?
-This can be achieved by accessing the drivers remotely from an NT (or
-2k/XP) client, as is discussed in the next paragraphs.
+What do these two words stand for? Basically, the Device Mode and the set of Printer Driver Data is a
+collection of settings for all print queue properties, initialized in a sensible way. Device Modes and
+Printer Driver Data should initially be set on the print server (the Samba host) to healthy
+values so the clients can start to use them immediately. How do we set these initial healthy values?
+This can be achieved by accessing the drivers remotely from an NT (or 200x/XP) client, as is discussed
+in the following paragraphs.
-Be aware, that a valid Device Mode can only be initiated by a
-printer admin, or root (the reason should be
-obvious). Device Modes can only correctly be set by executing the
-printer driver program itself. Since Samba can not execute this Win32
-platform driver code, it sets this field initially to NULL (which is
-not a valid setting for clients to use). Fortunately, most drivers
-generate themselves the Printer Driver Data that is needed, when they
-are uploaded to the [print$] share with the
-help of the APW or rpcclient.
+Be aware that a valid Device Mode can only be initiated by a
+printer admin, or root
+(the reason should be obvious). Device Modes can only be correctly
+set by executing the printer driver program itself. Since Samba cannot execute this Win32 platform driver
+code, it sets this field initially to NULL (which is not a valid setting for clients to use). Fortunately,
+most drivers automatically generate the Printer Driver Data that is needed when they are uploaded to the
+[print$] share with the help of the APW or rpcclient.
-The generation and setting of a first valid Device Mode however
-requires some "tickling" from a client, to set it on the Samba
-server. The easiest means of doing so is to simply change the page
-orientation on the server's printer. This "executes" enough of the
-printer driver program on the client for the desired effect to happen,
-and feeds back the new Device Mode to our Samba server. You can use the
-native Windows NT/2K/XP printer properties page from a Window client
-for this:
- Browse the Network Neighbourhood Find the Samba server Open the Samba server's Printers and
- Faxes folder Highlight the shared printer in question Right-click the printer (you may already be here, if you
-followed the last section's description) At the bottom of the context menu select
- Go to the Advanced tab; click on
- Change the "Portrait" page setting to "Landscape" (and
-back) (Oh, and make sure to apply
-changes between swapping the page orientation to cause the change to
-actually take effect...). While you're at it, you may optionally also want to
-set the desired printing defaults here, which then apply to all future
-client driver installations on the remaining from now
-on.
-This procedure has executed the printer driver program on the client
-platform and fed back the correct Device Mode to Samba, which now
-stored it in its TDB files. Once the driver is installed on the
-client, you can follow the analogous steps by accessing the
-local Printers folder too if you are
-a Samba printer admin user. From now on printing should work as expected.
+The generation and setting of a first valid Device Mode, however, requires some tickling from a client,
+to set it on the Samba server. The easiest means of doing so is to simply change the page orientation on
+the server's printer. This executes enough of the printer driver program on the client for the desired
+effect to happen, and feeds back the new Device Mode to our Samba server. You can use the native Windows
+NT/200x/XP printer properties page from a Window client for this:
+
+ Browse the Network Neighborhood.
+
+ Find the Samba server.
+
+ Open the Samba server's Printers and Faxes folder.
+
+ Highlight the shared printer in question.
+
+ Right-click on the printer (you may already be here, if you followed the last section's description).
+
+ At the bottom of the context menu select
+ Go to the Advanced tab; click on .
+
+ Change the
+ Make sure to apply changes between swapping the page orientation to cause the change to actually take effect.
+
+ While you are at it, you may also want to set the desired printing defaults here, which then apply to all future
+ client driver installations on the remaining from now on.
+
+This procedure has executed the printer driver program on the client platform and fed back the correct
+Device Mode to Samba, which now stored it in its TDB files. Once the driver is installed on the client,
+you can follow the analogous steps by accessing the local Printers
+folder, too, if you are a Samba printer admin user. From now on, printing should work as expected.
-Samba also includes a service level parameter name default
-devmode for generating a default Device Mode for a
-printer. Some drivers will function well with Samba's default set of
-properties. Others may crash the client's spooler service. So use this
-parameter with caution. It is always better to have the client
-generate a valid device mode for the printer and store it on the
-server for you.
-
-Every further driver may be done by any user, along the lines
-described above: Browse network, open printers folder on Samba server,
-right-click printer and choose Printers and
-Faxes folder.
+Samba includes a service level parameter name default devmode for generating a default
+Device Mode for a printer. Some drivers will function well with Samba's default set of properties. Others
+may crash the client's spooler service. So use this parameter with caution. It is always better to have
+the client generate a valid device mode for the printer and store it on the server for you.
+
+Every additional driver may be installed, along the lines described
+above. Browse network, open the
+Printers folder on Samba server, right-click on Printer and choose
+ . Once this completes (should be not more than a few seconds,
+but could also take a minute, depending on network conditions), you should find the new printer in your
+client workstation local Printers and Faxes folder.
You can also open your local Printers and Faxes folder by
-using this command on Windows 2000 and Windows XP Professional workstations:
- rundll32 shell32.dll,SHHelpShortcuts_RunDLL PrintersFolder
-
+using this command on Windows 200x/XP Professional workstations:
+ rundll32 shell32.dll,SHHelpShortcuts_RunDLL PrintersFolder
or this command on Windows NT 4.0 workstations:
rundll32 shell32.dll,Control_RunDLL MAIN.CPL @2
-You can enter the commands either inside a DOS box window
-or in the field from the
- menu.
-
-After you installed the driver on the Samba server (in its
-[print$] share, you should always make sure
-that your first client installation completes correctly. Make it a habit for
-yourself to build that the very first connection from a client as
-printer admin. This is to make sure that:
- a first valid Device Mode is
-really initialized (see above for more explanation details), and
-that the default print settings of your printer for all
-further client installations are as you want them
-Do this by changing the orientation to landscape, click
-Apply, and then change it back again. Then modify
-the other settings (for example, you don't want the default media size
-set to Letter, when you are all using
-A4, right? You may want to set the printer for
-duplex as the default; etc.).
+You can enter the commands either inside a DOS box window or in the field from the menu.
+
+After you installed the driver on the Samba server (in its [print$]
+share, you should always make sure that your first client installation completes correctly. Make it a
+habit for yourself to build the very first connection from a client as printer admin. This is to make sure that:
+
+ A first valid Device Mode is really initialized (see above for more
+ explanation details).
+
+ The default print settings of your printer for all further client installations are as you want them.
+
+Do this by changing the orientation to landscape, click on Apply, and then change it
+back again. Next, modify the other settings (for example, you do not want the default media size set to
+Letter when you are all using A4, right? You may want to set the
+printer for duplex as the default, and so on).
-To connect as root to a Samba printer, try this command from a Windows
-2K/XP DOS box command prompt:
+To connect as root to a Samba printer, try this command from a Windows 200x/XP DOS box command prompt:
You will be prompted for root's Samba-password; type it, wait a few
-seconds, click on printer admin from the setting.
+seconds, click on , and proceed to set the job options that should be used as defaults by all
+clients. Alternately, instead of root you can name one other member of the printer admin from the setting.
-Now all the other users downloading and installing the driver
-the same way (called Point'n'Print) will
-have the same defaults set for them. If you miss this step you'll
-get a lot of helpdesk calls from your users. But maybe you like to
-talk to people.... ;-)
-
-Your driver is installed. It is ready for
-Point'n'Print installation by the clients
-now. You may have tried to download and use it
-onto your first client machine now. But wait... let's make you
-acquainted first with a few tips and tricks you may find useful. For
-example, suppose you didn't manage to "set the defaults" on the
-printer, as advised in the preceding paragraphs? And your users
-complain about various issues (such as “We need to set the paper
-size for each job from Letter to A4 and it won't store it!”)
-
+ Now all the other users downloading and installing the driver the same way (called
+“Point'n'Print”) will have the same defaults set for them. If you miss this step
+you'll get a lot of Help Desk calls from your users, but maybe you like to talk to people.
+
+Your driver is installed. It is now ready for Point'n'Print
+installation by the clients. You may have tried to download and use it
+onto your first client machine, but
+wait. Let's make sure you are acquainted first with a few tips and tricks you may find useful. For example,
+suppose you did not set the defaults on the printer, as advised in the preceding
+paragraphs. Your users complain about various issues (such as, “We need to set the paper size
+for each job from Letter to A4 and it will not store it.”)
+
The last sentence might be viewed with mixed feelings by some users and
-admins. They have struggled for hours and hours and couldn't arrive at
-a point were their settings seemed to be saved. It is not their
-fault. The confusing thing is this: in the multi-tabbed dialog that pops
-up when you right-click the printer name and select
- “I can't set and save default print options
-for all users on Win2K/XP! Why not?”
-How are you doing it? I bet the wrong way.... (it is not very
-easy to find out, though). There are 3 different ways to bring you to
-a dialog that seems to set everything. All three
-dialogs look the same. Only one of them
-does what you intend.
-Important: you need to be Administrator or Print
-Administrator to do this for all users. Here is how I reproduce it in
-on XP Professional:
-
- The first "wrong" way:
-
- Open the Printers
-folder. Right-click on the printer
-(remoteprinter on cupshost) and
-select in context menu Look at this dialog closely and remember what it looks
-like.
- The second "wrong" way:
+admins. They have struggled for hours and could not arrive at a point
+where their settings seemed to be saved. It is not their fault. The confusing
+thing is that in the multi-tabbed dialog that pops up when you right-click
+on the printer name and select “I can not set and save default print options
+for all users on Windows 200x/XP. Why not?”
+How are you doing it? I bet the wrong way. (It is not easy to find out, though). There are three different
+ways to bring you to a dialog that seems to set everything. All three
+dialogs look the same, but only one
+of them does what you intend. You need to be Administrator or Print Administrator to do this for all
+users. Here is how I reproduce it in an XP Professional:
- Open the Right-click on the printer (remoteprinter on
-cupshost) and select in the context menu
- Click on the General
-tab Click on the button A new dialog opens. Keep this dialog open and go back
-to the parent dialog.
- The third, the "correct" way: (should you do
-this from the beginning, just carry out steps 1. and 2. from second
-"way" above)
-
- Click on the Advanced
-tab. (Hmmm... if everything is "Grayed Out", then you are not logged
-in as a user with enough privileges). Click on the On any of the two new tabs, click on the
-Advanced... button. A new dialog opens. Compare this one to the other,
-identical looking one from "B.5" or A.3".
-
-
-Do you see any difference in the two settings dialogs? I don't
-either. However, only the last one, which you arrived at with steps
-C.1.-6. will permanently save any settings which will then become the
-defaults for new users. If you want all clients to have the same
-defaults, you need to conduct these steps as administrator
-(printer admin in )
-before a client downloads the driver (the clients
-can later set their own per-user defaults by
-following the procedures A.
-or B. above...). (This is new: Windows 2000 and
-Windows XP allow per-user default settings and
-the ones the administrator gives them, before they set up their own).
-The "parents" of the identically looking dialogs have a slight
-difference in their window names: one is called
-Default Print Values for Printer Foo on Server
-Bar" (which is the one you need) and the other is
-called "Print Settings for Printer Foo on Server
-Bar". The last one is the one you arrive at when you
-right-click on the printer and select . This is the one what you were
-taught to use back in the days of Windows NT! So it is only natural to
-try the same way with Win2k or WinXP. You wouldn't dream
-that there is now a different "clicking path" to arrive at an
-identically looking, but functionally different dialog to set defaults
-for all users!
- Try (on Win2000 and WinXP) to run this command (as a user
-with the right privileges):
+The following list needs periods after the letters and numbers:::::::::
+ The first “wrong” way:
+ Open the Printers folder. Right-click on the printer (remoteprinter on cupshost) and
+ select in context menu Look at this dialog closely and remember what it looks like. The second “wrong” way:
+ Open the Right-click on the printer (remoteprinter on
+ cupshost) and select in the context menu
+ Click on the General
+ tab Click on the A new dialog opens. Keep this dialog open and go back
+ to the parent dialog.
+
+ The third and correct way: (should you do this from the beginning, just carry out steps 1
+ and 2 from the second method above).
+ Click on the Advanced
+ tab. (If everything is “grayed out,” then you are not logged
+ in as a user with enough privileges). Click on the On any of the two new tabs,
+ click on the
+ Advanced button. A new dialog opens. Compare
+ this one to the other. Are they
+ identical looking comparing one from
+ “B.5” and one from A.3".
+Do you see any difference in the two settings dialogs? I do not either. However, only the last one, which
+you arrived at with steps C.1 through 6 will permanently save any settings which will then become the defaults
+for new users. If you want all clients to have the same defaults, you need to conduct these steps as
+administrator (printer admin in ) before
+a client downloads the driver (the clients can later set their own per-user defaults
+by following procedures A or B above). Windows 200x/XP allow per-user default settings and the ones the
+administrator gives them, before they set up their own. The parents of the identically-looking dialogs have a slight difference in their window names; one is called Default Print
+Values for Printer Foo on Server Bar" (which is the one you need) and the other is called
+“Print Settings for Printer Foo on Server Bar”. The last one is the one you
+arrive at when you right-click on the printer and select . This
+is the one that you were taught to use back in the days of Windows NT, so it is only natural to try the
+same way with Windows 200x/XP. You would not dream that there is now a different path to arrive at an
+identically looking, but functionally different, dialog to set defaults for all users.
+ Try (on Windows 200x/XP) to run this command (as a user with the right privileges):
rundll32 printui.dll,PrintUIEntry /p /t3 /n\\SAMBA-SERVER\printersharename
-to see the tab with the Printing Defaults...
-button (the one you need). Also run this command:
+To see the tab with the Printing Defaults button (the one you need),also run this command:
rundll32 printui.dll,PrintUIEntry /p /t0 /n\\SAMBA-SERVER\printersharename
-to see the tab with the Printing Preferences...
-button (the one which doesn't set system-wide defaults). You can
-start the commands from inside a DOS box" or from the
--- menu.
-
-One issue that has arisen during the recent development phase of Samba
-is the need to support driver downloads for 100's of printers. Using
-Windows NT APW here is somewhat awkward (to say the least). If you
-don't want to acquire RSS pains from such the printer installation
-clicking orgy alone, you need to think about a non-interactive script.
+To see the tab with the Printing Preferences
+button (the one which does not set system-wide defaults), you can
+start the commands from inside a DOS box" or from -> .
+
+One issue that has arisen during the recent development phase of Samba is the need to support driver
+downloads for hunderds of printers. Using Windows NT APW here is somewhat awkward (to say the least). If
+you do not want to acquire RSS pains from the printer installation clicking orgy alone, you need
+to think about a non-interactive script.
-If more than one printer is using the same driver, the
-rpcclient setdriver command can be used to set the
-driver associated with an installed queue. If the driver is uploaded
-to [print$] once and registered with the
-printing TDBs, it can be used by multiple print queues. In this case
-you just need to repeat the setprinter subcommand
-of rpcclient for every queue (without the need to
-conduct the adddriver again and again). The
-following is an example of how this could be accomplished:
+If more than one printer is using the same driver, the rpcclient setdriver
+command can be used to set the driver associated with an installed queue. If the driver is uploaded to
+[print$] once and registered with the printing TDBs, it can be used by
+multiple print queues. In this case, you just need to repeat the setprinter subcommand of
+rpcclient for every queue (without the need to conduct the adddriver
+repeatedly). The following is an example of how this could be accomplished:
@@ -1661,7 +1428,7 @@ following is an example of how this could be accomplished:
@@ -1678,9 +1445,9 @@ following is an example of how this could be accomplished:
-It may be not easy to recognize: but the first call to
-enumprinters showed the "dm9110" printer with an
-empty string where the driver should have been listed (between the 2
-commas in the "description" field). After the
-setdriver command succeeded, all is well. (The
-CUPS Printing chapter has more info about the installation of printer
-drivers with the help of rpcclient).
-
-By default, Samba exhibits all printer shares defined in
-smb.conf in the
-Printers... folder. Also located in this folder
-is the Windows NT Add Printer Wizard icon. The APW will be shown only
-if:
- ...the connected user is able to successfully execute
-an OpenPrinterEx(\\server) with administrative
-privileges (i.e. root or printer admin).
- Try this from a Windows 2K/XP DOS box command prompt:
-
-runas /netonly /user:root rundll32 printui.dll,PrintUIEntry /p /t0 /n \\SAMBA-SERVER\printersharename
-
-and click on ... contains the setting
-show add printer wizard = yes (the
-default).
+It may not be easy to recognize that the first call to enumprinters showed the
+“dm9110” printer with an empty string where the driver should have been listed (between
+the 2 commas in the description field). After the setdriver command
+succeeded, all is well.
+
+By default, Samba exhibits all printer shares defined in smb.conf in the Printers
+folder. Also located in this folder is the Windows NT Add Printer Wizard icon. The APW will be shown only if:
+
+ The connected user is able to successfully execute an OpenPrinterEx(\\server) with
+ administrative privileges (i.e., root or printer admin).
+ Try this from a Windows 200x/XP DOS box command prompt:
+
+ runas /netonly /user:root rundll32 printui.dll,PrintUIEntry /p /t0 /n \\SAMBA-SERVER\printersharename
+
+ Click on ... contains the setting
+ show add printer wizard = yes (the
+ default).
The APW can do various things:
- upload a new driver to the Samba
-[print$] share; associate an uploaded driver with an existing (but
-still "driverless") print queue; exchange the currently used driver for an existing
-print queue with one that has been uploaded before; add an entirely new printer to the Samba host (only in
-conjunction with a working add printer command;
-a corresponding delete printer command for
-removing entries from the Printers... folder
-may be provided too)
-The last one (add a new printer) requires more effort than the
-previous ones. In order to use the APW to successfully add a printer
-to a Samba server, the add printer command must
-have a defined value. The program hook must successfully add the
-printer to the UNIX print system (i.e. to
-/etc/printcap,
-/etc/cups/printers.conf or other appropriate
-files) and to if necessary.
+
+ Upload a new driver to the Samba [print$] share.
+
+ Associate an uploaded driver with an existing (but still driverless) print queue.
+
+ Exchange the currently used driver for an existing print queue with one that has been uploaded before.
+
+ Add an entirely new printer to the Samba host (only in conjunction with a working
+ add printer command. A corresponding
+ delete printer command for removing entries from the
+ Printers folder may also be provided).
+
+The last one (add a new printer) requires more effort than the previous ones. To use
+the APW to successfully add a printer to a Samba server, the add printer command must have a defined value. The program hook must successfully
+add the printer to the UNIX print system (i.e., to /etc/printcap,
+/etc/cups/printers.conf or other appropriate files) and to smb.conf if necessary.
-When using the APW from a client, if the named printer share does not
-exist, smbd will execute the add printer
-command and reparse to the
-to attempt to locate the new printer share. If the share is still not
-defined, an error of Access Denied is
-returned to the client. Note that the add printer command is executed under the context of the connected
-user, not necessarily a root account. A map to guest = bad user may have connected you unwittingly under the wrong
-privilege; you should check it by using the
-smbstatus command.
-
-Once you are connected with the wrong credentials, there is no means
-to reverse the situation other than to close all Explorer windows, and
-perhaps reboot.
- The net use \\SAMBA-SERVER\sharename
-/user:root gives you an error message: Multiple
-connections to a server or a shared resource by the same user
-utilizing the several user names are not allowed. Disconnect all
-previous connections to the server, resp. the shared resource, and try
-again. Every attempt to "connect a network drive" to
-\\SAMBASERVER\\print$ to z: is countered by the
-pertinacious message. This network folder is currently
-connected under different credentials (username and password).
-Disconnect first any existing connection to this network share in
-order to connect again under a different username and
-password.
-So you close all connections. You try again. You get the same
-message. You check from the Samba side, using
-smbstatus. Yes, there are some more
-connections. You kill them all. The client still gives you the same
-error message. You watch the smbd.log file on a very high debug level
-and try re-connect. Same error message, but not a single line in the
-log. You start to wonder if there was a connection attempt at all. You
-run ethereal and tcpdump while you try to connect. Result: not a
-single byte goes on the wire. Windows still gives the error
-message. You close all Explorer Windows and start it again. You try to
-connect - and this times it works! Windows seems to cache connection
-info somewhere and doesn't keep it up to date (if you are unlucky you
-might need to reboot to get rid of the error message).
-
-You need to be very careful when you take notes about the files and
-belonging to a particular driver. Don't confuse the files for driver
-version "0" (for Win95/98/ME, going into
-[print$]/WIN/0/), driver version "2" (Kernel Mode
-driver for WinNT, going into [print$]/W32X86/2/
-may be used on Win2K/XP too), and driver version
-"3" (non-Kernel Mode driver going into
-[print$]/W32X86/3/ can not
-be used on WinNT). Very often these different driver versions contain
-files carrying the same name; but still the files are very different!
-Also, if you look at them from the Windows Explorer (they reside in
-%WINDOWS%\system32\spool\drivers\W32X86\) you
-will probably see names in capital letters, while an "enumdrivers"
-command from Samba would show mixed or lower case letters. So it is
-easy to confuse them. If you install them manually using
-rpcclient and subcommands, you may even succeed
-without an error message. Only later, when you try install on a
-client, you will encounter error messages like This
-server has no appropriate driver for the printer.
+When using the APW from a client, if the named printer share does not exist, smbd will execute the
+add printer command and reparse to the to attempt to locate the new printer
+share. If the share is still not defined, an error of Access Denied is returned to
+the client. The add printer command is executed
+under the context of the connected user, not necessarily a root account. A map to guest = bad user may have connected you unwittingly under the wrong
+privilege. You should check it by using the smbstatus command.
+
+Once you are connected with the wrong credentials, there is no means to reverse the situation other than
+to close all Explorer Windows, and perhaps reboot.
+
+ The net use \\SAMBA-SERVER\sharename /user:root gives you an error message:
+ “Multiple connections to a server or a shared resource by the same user utilizing
+ the several user names are not allowed. Disconnect all previous connections to the server,
+ resp. the shared resource, and try again.”
+
+ Every attempt to “connect a network drive” to \\SAMBASERVER\\print$
+ to z: is countered by the pertinacious message: “This
+ network folder is currently connected under different credentials (username and password).
+ Disconnect first any existing connection to this network share in order to connect again under
+ a different username and password”.
+
+So you close all connections. You try again. You get the same message. You check from the Samba side,
+using smbstatus. Yes, there are more connections. You kill them all. The client
+still gives you the same error message. You watch the smbd.log file on a high debug level and try
+reconnect. Same error message, but not a single line in the log. You start to wonder if there was a
+connection attempt at all. You run ethereal and tcpdump while you try to connect. Result: not a single
+byte goes on the wire. Windows still gives the error message. You close all Explorer windows and start it
+again. You try to connect and this times it works! Windows seems to cache connection informtion somewhere and
+does not keep it up-to-date (if you are unlucky you might need to reboot to get rid of the error message).
+
+You need to be extremely careful when you take notes about the files and belonging to a particular
+driver. Don't confuse the files for driver version “0” (for Windows 9x/Me, going into
+[print$]/WIN/0/), driver version 2 (Kernel Mode driver for Windows NT,
+going into [print$]/W32X86/2/ may be used on Windows 200x/XP also), and
+driver version “3” (non-Kernel Mode driver going into [print$]/W32X86/3/
+cannot be used on Windows NT). Quite often these different driver versions contain
+files that have the same name but actually are very different. If you look at them from
+the Windows Explorer (they reside in %WINDOWS%\system32\spool\drivers\W32X86\),
+you will probably see names in capital letters, while an enumdrivers command from Samba
+would show mixed or lower case letters. So it is easy to confuse them. If you install them manually using
+rpcclient and subcommands, you may even succeed without an error message. Only later,
+when you try install on a client, you will encounter error messages like This server
+has no appropriate driver for the printer.
-Here is an example. You are invited to look very closely at the
-various files, compare their names and their spelling, and discover
-the differences in the composition of the version-2 and -3 sets
-Note: the version-0 set contained 40 (!)
-Dependentfiles, so I left it out for space
-reasons:
+Here is an example. You are invited to look closely at the various files, compare their names and
+their spelling, and discover the differences in the composition of the version 2 and 3 sets. Note: the
+version 0 set contained 40 Dependentfiles, so I left it out for space reasons:
-If we write the "version 2" files and the "version 3" files
+If we write the “version 2” files and the “version 3” files
into different text files and compare the result, we see this
picture:
-Don't be fooled though! Driver files for each version with identical
+
+Do not be fooled! Driver files for each version with identical
names may be different in their content, as you can see from this size
comparison:
-In my example were even more differences than shown here. Conclusion:
-you must be very careful to select the correct driver files for each
-driver version. Don't rely on the names alone. Don't interchange files
+In my example were even more differences than shown here. Conclusion: you must be careful to select
+the correct driver files for each driver version. Don't rely on the
+names alone and don't interchange files
belonging to different driver versions.
-
-Windows NT/2000 print servers associate a port with each
-printer. These normally take the form of LPT1:,
-COM1:, FILE:, etc. Samba
-must also support the concept of ports associated with a printer. By
-default, only one printer port, named "Samba Printer Port", exists on
-a system. Samba does not really need such a "port" in order to print;
-it rather is a requirement of Windows clients. They insist on being
-told about an available port when they request this info, otherwise
-they throw an error message at you. So Samba fakes the port
+
+Windows NT/2000 print servers associate a port with each printer. These normally take the form of
+LPT1:, COM1:,
+FILE:, and so on. Samba must also
+support the concept of ports associated with a printer. By default, only one printer port, named “Samba
+Printer Port”, exists on a system. Samba does not really need such a “port” in order
+to print; rather it is a requirement of Windows clients. They insist on being told about an available
+port when they request this information, otherwise they throw an error message at you. So Samba fakes the port
information to keep the Windows clients happy.
-Note that Samba does not support the concept of "Printer Pooling"
-internally either. Printer Pooling assigns a logical printer to
-multiple ports as a form of load balancing or fail over.
+Samba does not support the concept of Printer Pooling internally either. Printer
+Pooling assigns a logical printer to multiple ports as a form of load balancing or fail over.
-If you require that multiple ports be defined for some reason or
-another (“My users and my Boss should not know that they are
-working with Samba”), possesses a
-enumports command which can be used to define
-an external program that generates a listing of ports on a system.
-
-So - printing works, but there are still problems. Most jobs print
-well, some don't print at all. Some jobs have problems with fonts,
-which don't look good at all. Some jobs print fast, and some are
-dead-slow. We can't cover it all; but we want to encourage you to read
-the little paragraph about "Avoiding the wrong PostScript Driver
-Settings" in the CUPS Printing part of this document.
-
-The Imprints tool set provides a UNIX equivalent of the
-Windows NT Add Printer Wizard. For complete information, please
-refer to the Imprints web site
-at http://imprints.sourceforge.net/
-as well as the documentation included with the imprints source
-distribution. This section will only provide a brief introduction
-to the features of Imprints.
- Attention! Maintainer required.
-Unfortunately, the Imprints toolset is no longer maintained. As of
-December, 2000, the project is in need of a new maintainer. The most
-important skill to have is decent perl coding and an interest in
-MS-RPC based printing using Samba. If you wish to volunteer, please
-coordinate your efforts on the samba-technical mailing list. The
-toolset is still in usable form; but only for a series of older
-printer models, where there are prepared packages to use. Packages for
-more up to date print devices are needed if Imprints should have a
-future.
+If you require multiple ports be defined for some reason or another (my users and my boss should not know
+that they are working with Samba), configure enumports command
+which can be used to define an external program that generates a listing of ports on a system.
+
+So now the printing works, but there are still problems. Most jobs print well, some do not print at
+all. Some jobs have problems with fonts, which do not look good. Some jobs print fast and some
+are dead-slow. We cannot cover it all, but we want to encourage you to read the brief paragraph about
+“Avoiding the Wrong PostScript Driver Settings” in the CUPS Printing part of this document.
+
+The Imprints tool set provides a UNIX equivalent of the Windows NT Add Printer
+Wizard. For complete information, please refer to the Imprints Web site at
+Unfortunately, the Imprints toolset is no longer maintained. As of December 2000, the project is in
+need of a new maintainer. The most important skill to have is Perl coding and an interest in MS-RPC-based
+printing used in Samba. If you wish to volunteer, please coordinate
+your efforts on the Samba technical
+mailing list. The toolset is still in usable form, but only for a series of older printer models where
+there are prepared packages to use. Packages for more up-to-date print devices are needed if Imprints
+should have a future.
+
Imprints is a collection of tools for supporting these goals:
- Providing a central repository information regarding
-Windows NT and 95/98 printer driver packages Providing the tools necessary for creating the
-Imprints printer driver packages. Providing an installation client which will obtain
-printer drivers from a central internet (or intranet) Imprints Server
-repository and install them on remote Samba and Windows NT4 print
-servers.
-The process of creating printer driver packages is beyond the scope of
-this document (refer to Imprints.txt also included with the Samba
-distribution for more information). In short, an Imprints driver
-package is a gzipped tarball containing the driver files, related INF
-files, and a control file needed by the installation client.
-
-The Imprints server is really a database server that may be queried
-via standard HTTP mechanisms. Each printer entry in the database has
-an associated URL for the actual downloading of the package. Each
+
+ Providing a central repository of information regarding Windows NT and 95/98 printer driver packages.
+
+ Providing the tools necessary for creating the Imprints printer driver packages.
+
+ Providing an installation client that will obtain printer drivers from a central Internet (or intranet) Imprints Server
+ repository and install them on remote Samba and Windows NT4 print servers.
+
+The process of creating printer driver packages is beyond the scope of this document (refer to Imprints.txt
+also included with the Samba distribution for more information). In short, an Imprints driver package
+is a gzipped tarball containing the driver files, related INF files, and a control file needed by the
+installation client.
+
+The Imprints server is really a database server that may be queried via standard HTTP mechanisms. Each
+printer entry in the database has an associated URL for the actual downloading of the package. Each
package is digitally signed via GnuPG which can be used to verify that
-package downloaded is actually the one referred in the Imprints
-database. It is strongly recommended that this security check
-not be disabled.
-
-More information regarding the Imprints installation client is
-available in the Imprints-Client-HOWTO.ps file
-included with the imprints source package.
-
-The Imprints installation client comes in two forms.
- a set of command line Perl scripts a GTK+ based graphical interface to the command line Perl
-scripts
-The installation client (in both forms) provides a means of querying
-the Imprints database server for a matching list of known printer
-model names as well as a means to download and install the drivers on
+the package downloaded is actually
+the one referred in the Imprints database. It is strongly recommended that this security check
+not be disabled.
+
+More information regarding the Imprints installation client is available from the the documentation file
+Imprints-Client-HOWTO.ps that is included with the Imprints source package. The Imprints
+installation client comes in two forms:
+ A set of command line Perl scripts. A GTK+ based graphical interface to the command line Perl scripts.
+The installation client (in both forms) provides a means of querying the Imprints database server for
+a matching list of known printer model names as well as a means to download and install the drivers on
remote Samba and Windows NT print servers.
-The basic installation process is in four steps and perl code is
-wrapped around smbclient and rpcclient
+The basic installation process is in four steps and Perl code is wrapped around smbclient and rpcclient.
- foreach (supported architecture for a given driver)
- rpcclient: Get the appropriate upload directory on the remote server smbclient: Upload the driver files rpcclient: Issues an AddPrinterDriver() MS-RPC
- rpcclient: Issue an AddPrinterEx() MS-RPC to actually create the printer
-One of the problems encountered when implementing the Imprints tool
-set was the name space issues between various supported client
-architectures. For example, Windows NT includes a driver named "Apple
-LaserWriter II NTX v51.8" and Windows 95 calls its version of this
-driver "Apple LaserWriter II NTX"
+ For each supported architecture for a given driver:
+ rpcclient: Get the appropriate upload directory on the remote server. smbclient: Upload the driver files. rpcclient: Issues an AddPrinterDriver() MS-RPC.
+ rpcclient: Issue an AddPrinterEx() MS-RPC to actually create the printer.
+One of the problems encountered when implementing the Imprints tool set was the name space issues between
+various supported client architectures. For example, Windows NT includes a driver named “Apple LaserWriter
+II NTX v51.8” and Windows 95 calls its version of this driver “Apple LaserWriter II NTX”.
-The problem is how to know what client drivers have been uploaded for
-a printer. An astute reader will remember that the Windows NT Printer
-Properties dialog only includes space for one printer driver name. A
-quick look in the Windows NT 4.0 system registry at
+The problem is how to know what client drivers have been uploaded for a printer. An astute reader will
+remember that the Windows NT Printer Properties dialog only includes space for one printer driver name. A
+quick look in the Windows NT 4.0 system registry at:
HKLM\System\CurrentControlSet\Control\Print\Environment
-will reveal that Windows NT always uses the NT driver name. This is
-ok as Windows NT always requires that at least the Windows NT version
-of the printer driver is present. However, Samba does not have the
-requirement internally. Therefore, how can you use the NT driver name
-if is has not already been installed?
-
-The way of sidestepping this limitation is to require that all
-Imprints printer driver packages include both the Intel Windows NT and
-95/98 printer drivers and that NT driver is installed first.
-
-The following MS Knowledge Base article may be of some help if you
-need to handle Windows 2000 clients: How to Add Printers
-with No User Interaction in Windows 2000. ( http://support.microsoft.com/default.aspx?scid=kb;en-us;189105
-). It also applies to Windows XP Professional clients.
+will reveal that Windows NT always uses the NT driver name. This is okay as Windows NT always requires
+that at least the Windows NT version of the printer driver is present. Samba does not have the
+requirement internally, therefore, “How can you use the NT driver name if it has not already been installed?”
-The ideas sketched out below are inspired by this article. It
-describes a commandline method which can be applied to install
-network and local printers and their drivers. This is most useful
-if integrated in Logon Scripts. You can see what options are
-available by typing in a command prompt ("DOS box") this:
+The way of sidestepping this limitation is to require that all Imprints printer driver packages include both the Intel Windows NT and
+95/98 printer drivers and that the NT driver is installed first.
+
+The following MS Knowledge Base article may be of some help if you need to handle Windows 2000
+clients: How to Add Printers with No User Interaction in Windows 2000, ( rundll32 printui.dll,PrintUIEntry /?
-A window pops up which shows you all of the commandline switches
-available. An extensive list of examples is also provided. This is
-only for Win 2k/XP. It doesn't work on WinNT. WinNT has probably some
-other tools in the respective Resource Kit. Here is a suggestion about
-what a client logon script might contain, with a short explanation of
-what the lines actually do (it works if 2k/XP Windows clients access
-printers via Samba, but works for Windows-based print servers too):
+A window pops up that shows you all of the commandline switches available. An extensive list of examples
+is also provided. This is only for Win 200x/XP, it does not work on
+Windows NT. Windows NT probably has
+some other tools in the respective Resource Kit. Here is a suggestion about what a client logon script
+might contain, with a short explanation of what the lines actually do (it works if 200x/XP Windows
+clients access printers via Samba, and works for Windows-based print servers too):
Here is a list of the used commandline parameters:
- deletes a network printer quiet modus names a printer adds a network printer connection sets printer as default printer Line 1 deletes a possibly existing previous network
-printer infotec2105-IPDS (which had used native
-Windows drivers with LPRng that were removed from the server which was
-converted to CUPS). The /q at the end eliminates
-"Confirm" or error dialog boxes popping up. They should not be
-presented to the user logging on. Line 2 adds the new printer
-infotec2105-PS (which actually is same physical
-device but is now run by the new CUPS printing system and associated
-with the CUPS/Adobe PS drivers). The printer and its driver
-must have been added to Samba prior to the user
-logging in (e.g. by a procedure as discussed earlier in this chapter,
-or by running cupsaddsmb). The driver is now
-auto-downloaded to the client PC where the user is about to log
-in. Line 3 sets the default printer to this new network
-printer (there might be several other printers installed with this
-same method and some may be local as well -- so we decide for a
-default printer). The default printer selection may of course be
-different for different users.
-Note that the second line only works if the printer
-infotec2105-PS has an already working print queue
-on "sambacupsserver", and if the printer drivers have successfully been
-uploaded (via APW ,
-smbclient/rpcclient or
-cupsaddsmb) into the
-[print$] driver repository of Samba. Also, some
-Samba versions prior to version 3.0 required a re-start of smbd after
-the printer install and the driver upload, otherwise the script (or
-any other client driver download) would fail.
+ deletes a network printer quiet modus names a printer adds a network printer connection sets printer as default printer
+ Line 1 deletes a possibly existing previous network printer infotec2105-IPDS
+ (which had used native Windows drivers with LPRng that were removed from the server that was
+ converted to CUPS). The /q at the end eliminates Confirm
+ or error dialog boxes from popping up. They should not be presented to the user logging on.
+
+ Line 2 adds the new printer
+ infotec2105-PS (which actually is the same
+ physical device but is now run by the new CUPS printing system and associated with the
+ CUPS/Adobe PS drivers). The printer and its driver must have been added to Samba prior to
+ the user logging in (e.g., by a procedure as discussed earlier in this chapter, or by running
+ cupsaddsmb). The driver is now auto-downloaded to the client PC where the
+ user is about to log in.
+
+ Line 3 sets the default printer to this new network printer (there might be several other
+ printers installed with this same method and some may be local as well, so we decide for a
+ default printer). The default printer selection may, of course, be different for different users.
+
+The second line only works if the printer infotec2105-PS has an already working
+print queue on the cupsserver, and if the
+printer drivers have been successfully uploaded
+(via the APW, smbclient/rpcclient, or cupsaddsmb)
+into the [print$] driver repository of Samba. Some Samba versions
+prior to version 3.0 required a re-start of smbd after the printer install and the driver upload,
+otherwise the script (or any other client driver download) would fail.
-Since there no easy way to test for the existence of an installed
-network printer from the logon script, the suggestion is: don't bother
-checking and just allow the deinstallation/reinstallation to occur
-every time a user logs in; it's really quick anyway (1 to 2 seconds).
+Since there no easy way to test for the existence of an installed network printer from the logon script,
+do not bother checking, just allow the deinstallation/reinstallation to occur every time a user logs in;
+it's really quick anyway (1 to 2 seconds).
The additional benefits for this are:
- It puts in place any printer default setup changes
-automatically at every user logon. It allows for "roaming" users' login into the domain from
-different workstations.
-Since network printers are installed per user this much simplifies the
-process of keeping the installation up-to-date. The extra few seconds
-at logon time will not really be noticeable. Printers can be centrally
-added, changed, and deleted at will on the server with no user
-intervention required on the clients (you just need to keep the logon
-scripts up to date).
-
-The addprinter command can be configured to be a
-shell script or program executed by Samba. It is triggered by running
-the APW from a client against the Samba print server. The APW asks the
-user to fill in several fields (such as printer name, driver to be
-used, comment, port monitor, etc.). These parameters are passed on to
-Samba by the APW. If the addprinter command is designed in a way that
-it can create a new printer (through writing correct printcap entries
-on legacy systems, or execute the lpadmin command
-on more modern systems) and create the associated share in
-, then the APW will in effect really
-create a new printer on Samba and the UNIX print subsystem!
-
-The basic "NT-style" printer driver management has not changed
-considerably in 3.0 over the 2.2.x releases (apart from many small
-improvements). Here migration should be quite easy, especially if you
-followed previous advice to stop using deprecated parameters in your
-setup. For migrations from an existing 2.0.x setup, or if you
-continued "Win9x-style" printing in your Samba 2.2 installations, it
-is more of an effort. Please read the appropriate release notes and
-the HOWTO Collection for 2.2. You can follow several paths. Here are
-possible scenarios for migration:
- You need to study and apply the new Windows NT printer
-and driver support. Previously used parameters printer
-driver file, printer driver and
-printer driver location are no longer
-supported. If you want to take advantage of WinNT printer driver
-support you also need to migrate the Win9x/ME drivers to the new
-setup. An existing printers.def file
- (the one specified in the now removed parameter printer driver file) will work no longer with samba 3. In
-3.0, smbd attempts to locate a Win9x/ME driver files for the printer
-in [print$] and additional settings in the TDB
-and only there; if it fails it will not (as 2.2.x
-used to do) drop down to using a printers.def
-(and all associated parameters). The make_printerdef tool is removed
-and there is no backwards compatibility for this. You need to install a Windows 9x driver into the
-[print$] share for a printer on your Samba
-host. The driver files will be stored in the "WIN40/0" subdirectory of
-[print$], and some other settings and info go
-into the printing-related TDBs. If you want to migrate an existing
-printers.def file into the new setup, the current
-only solution is to use the Windows NT APW to install the NT drivers
-and the 9x drivers. This can be scripted using smbclient and
-rpcclient. See the Imprints installation client at:
-
- http://imprints.sourceforge.net/
-
-for an example. See also the discussion of rpcclient usage in the
-"CUPS Printing" section.
-We will publish an update to this section shortly.
-
-Don't confuse the root password which is valid for the UNIX system
-(and in most cases stored in the form of a one-way hash in a file
-named /etc/shadow) with the password used to
-authenticate against Samba!. Samba doesn't know the UNIX password; for
-root to access Samba resources via Samba-type access, a Samba account
-for root must be created first. This is often done with the
-smbpasswd command.
-Note
Important
Important
[global] printing = bsd load printers = yes [printers] path = /var/spool/samba printable = yes public = yes writable = no [global] printing = bsd load printers = yes [printers] path = /var/spool/samba printable = yes public = yes writable = no
-root# testparm -v | egrep "(lp|print|spool|driver|ports|\[)"
- Load smb config files from /etc/samba/smb.conf.simpleprinting
- Processing section "[homes]"
- Processing section "[printers]"
+root# testparm -s -v | egrep "(lp|print|spool|driver|ports|\[)"
+ Load smb config files from /etc/samba/smb.conf
+ Processing section "[homes]"
+ Processing section "[printers]"
[global]
smb ports = 445 139
@@ -183,73 +156,66 @@ as shown above:
[printers]
path = /var/spool/samba
printable = Yes
-
Note
Note
-root# grep "load printers" /etc/samba/smb.conf
- # load printers = Yes
- # This setting is commented ooouuuuut!!
+root# grep "load printers" /etc/samba/smb.conf
+ # load printers = Yes
+ # This setting is commented out!!
-root# testparm -v /etc/samba/smb.conf | egrep "(load printers)"
+root# testparm -v /etc/samba/smb.conf | egrep "(load printers)"
load printers = Yes
-
-root# grep -A1 "load printers" /etc/samba/smb.conf
+root# grep -A1 "load printers" /etc/samba/smb.conf
load printers = No
- # This setting is what I mean!!
- # load printers = Yes
- # This setting is commented ooouuuuut!!
+ # The above setting is what I want!
+ # load printers = Yes
+ # This setting is commented out!
-root# testparm -v smb.conf.simpleprinting | egrep "(load printers)"
+root# testparm -s -v smb.conf.simpleprinting | egrep "(load printers)"
load printers = No
root# cat /etc/samba/smb.conf-minimal
[printers]
-
-root# testparm -v smb.conf-minimal | egrep "(print|lpq|spool|driver|ports|[)"
- Processing section "[printers]"
+root# testparm -v smb.conf-minimal | egrep "(print|lpq|spool|driver|ports|[)"
+ Processing section "[printers]"
WARNING: [printers] service MUST be printable!
No path in service printers - using /tmp
@@ -272,675 +238,568 @@ would be, if you used this minimalistic file as your real
lpq command = lpq -P%p
printer name =
use client driver = No
+
[printers]
printable = Yes
# This defines LPRng as the printing system" printing = lprng [global] printing = bsd load printers = yes show add printer wizard = yes printcap name = /etc/printcap printer admin = @ntadmin, root total print jobs = 100 lpq cache time = 20 use client driver = no [printers] comment = All Printers printable = yes path = /var/spool/samba browseable = no guest ok = yes public = yes read only = yes writable = no [my_printer_name] comment = Printer with Restricted Access path = /var/spool/samba_my_printer printer admin = kurt browseable = yes printable = yes writeable = no hosts allow = 0.0.0.0 hosts deny = turbo_xp, 10.160.50.23, 10.160.51.60 guest ok = no # This defines LPRng as the printing system printing = lprng [global] printing = bsd load printers = yes show add printer wizard = yes printcap name = /etc/printcap printer admin = @ntadmin, root total print jobs = 100 lpq cache time = 20 use client driver = no [printers] comment = All Printers printable = yes path = /var/spool/samba browseable = no guest ok = yes public = yes read only = yes writable = no [my_printer_name] comment = Printer with Restricted Access path = /var/spool/samba_my_printer printer admin = kurt browseable = yes printable = yes writeable = no hosts allow = 0.0.0.0 hosts deny = turbo_xp, 10.160.50.23, 10.160.51.60 guest ok = no print command = echo Printing %s >> /tmp/print.log; lpr -P %p %s; rm %s print command = /usr/local/samba/bin/myprintscript %p %s print command = /usr/local/samba/bin/myprintscript %p %s [global] # members of the ntadmin group should be able to add drivers and set # printer properties. root is implicitly always a 'printer admin'. printer admin = @ntadmin ... [printers] ... [print$] comment = Printer Driver Download Area path = /etc/samba/drivers browseable = yes guest ok = yes read only = yes write list = @ntadmin, root [global] # members of the ntadmin group should be able to add drivers and set # printer properties. root is implicitly always a 'printer admin'. printer admin = @ntadmin ... [printers] ... [print$] comment = Printer Driver Download Area path = /etc/samba/drivers browseable = yes guest ok = yes read only = yes write list = @ntadmin, root Note
Note
-[print$]--+--
- |--W32X86 # serves drivers to "Windows NT x86"
- |--WIN40 # serves drivers to "Windows 95/98"
- |--W32ALPHA # serves drivers to "Windows NT Alpha_AXP"
- |--W32MIPS # serves drivers to "Windows NT R4000"
- |--W32PPC # serves drivers to "Windows NT PowerPC"
-
Required permissions
Required permissions
root# rpcclient -U'Danka%xxxx' -c \
- 'getdriver "Heidelberg Digimaster 9110 (PS)" 3' TURBO_XP
-cmd = getdriver "Heidelberg Digimaster 9110 (PS)" 3
+ 'getdriver "Heidelberg Digimaster 9110 (PS)" 3' TURBO_XP
+cmd = getdriver "Heidelberg Digimaster 9110 (PS)" 3
[Windows NT x86]
Printer Driver Info 3:
@@ -954,58 +813,47 @@ Printer Driver Info 3:
Dependentfiles: [C:\WINNT\System32\spool\DRIVERS\W32X86\2\Hddm91c1_de.DLL]
Dependentfiles: [C:\WINNT\System32\spool\DRIVERS\W32X86\2\Hddm91c1_de.INI]
- Dependentfiles: [C:\WINNT\System32\spool\DRIVERS\W32X86\2\Hddm91c1KMMin.DLL]
Dependentfiles: [C:\WINNT\System32\spool\DRIVERS\W32X86\2\Hddm91c1_de.dat]
Dependentfiles: [C:\WINNT\System32\spool\DRIVERS\W32X86\2\Hddm91c1_de.cat]
Dependentfiles: [C:\WINNT\System32\spool\DRIVERS\W32X86\2\Hddm91c1_de.def]
Dependentfiles: [C:\WINNT\System32\spool\DRIVERS\W32X86\2\Hddm91c1_de.hre]
Dependentfiles: [C:\WINNT\System32\spool\DRIVERS\W32X86\2\Hddm91c1_de.vnd]
Dependentfiles: [C:\WINNT\System32\spool\DRIVERS\W32X86\2\Hddm91c1_de.hlp]
- Dependentfiles: [C:\WINNT\System32\spool\DRIVERS\W32X86\2\Hddm91c1_de_reg.HLP]
Dependentfiles: [C:\WINNT\System32\spool\DRIVERS\W32X86\2\HDNIS01Aux.dll]
Dependentfiles: [C:\WINNT\System32\spool\DRIVERS\W32X86\2\HDNIS01_de.NTF]
Monitorname: []
Defaultdatatype: []
Note
Note
-root# smbclient //TURBO_XP/print\$ -U'Danka%xxxx' \
- -c 'cd W32X86/2;mget HD*_de.* \
- hd*ppd Hd*_de.* Hddm*dll HDN*Aux.DLL'
+root# smbclient //TURBO_XP/print\$ -U'Danka%xxxx' \
+ -c 'cd W32X86/2;mget HD*_de.* hd*ppd Hd*_de.* Hddm*dll HDN*Aux.DLL'
+
added interface ip=10.160.51.60 bcast=10.160.51.255 nmask=255.255.252.0
Got a positive name query response from 10.160.50.8 ( 10.160.50.8 )
Domain=[DEVELOPMENT] OS=[Windows 5.1] Server=[Windows 2000 LAN Manager]
@@ -1015,43 +863,38 @@ getting file \W32X86\2\Hddm91c1_de.def of size 428 as Hddm91c1_de.def
Get file Hddm91c1_de.DLL? y
getting file \W32X86\2\Hddm91c1_de.DLL of size 876544 as Hddm91c1_de.DLL
[...]
-
- root# smbclient //SAMBA-CUPS/print\$ -U'root%xxxx' -c \
- 'cd W32X86; put HDNIS01_de.DLL; \
+root# smbclient //SAMBA-CUPS/print\$ -U'root%xxxx' -c \
+ 'cd W32X86; put HDNIS01_de.DLL; \
put Hddm91c1_de.ppd; put HDNIS01U_de.DLL; \
put HDNIS01U_de.HLP; put Hddm91c1_de.DLL; \
put Hddm91c1_de.INI; put Hddm91c1KMMin.DLL; \
@@ -1060,6 +903,7 @@ store the files into a Samba/UNIX print s
put Hddm91c1_de.vnd; put Hddm91c1_de.hlp; \
put Hddm91c1_de_reg.HLP; put HDNIS01Aux.dll; \
put HDNIS01_de.NTF'
+
added interface ip=10.160.51.60 bcast=10.160.51.255 nmask=255.255.252.0
Got a positive name query response from 10.160.51.162 ( 10.160.51.162 )
Domain=[CUPS-PRINT] OS=[UNIX] Server=[Samba 2.2.7a]
@@ -1080,30 +924,26 @@ putting file Hddm91c1_de_reg.HLP as \W32X86\Hddm91c1_de_reg.HLP
putting file HDNIS01Aux.dll as \W32X86\HDNIS01Aux.dll
putting file HDNIS01_de.NTF as \W32X86\HDNIS01_de.NTF
root# smbclient //SAMBA-CUPS/print\$ -U 'root%xxxx' \
-c 'cd W32X86; pwd; dir; cd 2; pwd; dir'
added interface ip=10.160.51.60 bcast=10.160.51.255 nmask=255.255.252.0
Got a positive name query response from 10.160.51.162 ( 10.160.51.162 )
-Domain=[CUPS-PRINT] OS=[UNIX] Server=[Samba 2.2.7a]
+Domain=[CUPS-PRINT] OS=[UNIX] Server=[Samba 2.2.8a]
Current directory is \\SAMBA-CUPS\print$\W32X86\
-. D 0 Sun May 4 03:56:35 2003
-.. D 0 Thu Apr 10 23:47:40 2003
+. D 0 Sun May 4 03:56:35 2003
+.. D 0 Thu Apr 10 23:47:40 2003
2 D 0 Sun May 4 03:56:18 2003
HDNIS01Aux.dll A 15356 Sun May 4 03:58:59 2003
Hddm91c1KMMin.DLL A 46966 Sun May 4 03:58:59 2003
@@ -1123,8 +963,8 @@ Hddm91c1_de_reg.HLP A 228417 Sun May 4 03:58:59 2003
40976 blocks of size 262144. 709 blocks available
Current directory is \\SAMBA-CUPS\print$\W32X86\2\
-. D 0 Sun May 4 03:56:18 2003
-.. D 0 Sun May 4 03:56:35 2003
+. D 0 Sun May 4 03:56:18 2003
+.. D 0 Sun May 4 03:56:35 2003
ADOBEPS5.DLL A 434400 Sat May 3 23:18:45 2003
laserjet4.ppd A 9639 Thu Apr 24 01:05:32 2003
ADOBEPSU.DLL A 109568 Sat May 3 23:18:45 2003
@@ -1132,76 +972,64 @@ ADOBEPSU.HLP A 18082 Sat May 3 23:18:45 2003
PDFcreator2.PPD A 15746 Sun Apr 20 22:24:07 2003
40976 blocks of size 262144. 709 blocks available
- root# rpcclient -Uroot%xxxx -c 'adddriver "Windows NT x86" \
-"dm9110:HDNIS01_de.DLL: \
-Hddm91c1_de.ppd:HDNIS01U_de.DLL:HDNIS01U_de.HLP: \
- NULL:RAW:Hddm91c1_de.DLL,Hddm91c1_de.INI, \
- Hddm91c1_de.dat,Hddm91c1_de.def,Hddm91c1_de.hre, \
- Hddm91c1_de.vnd,Hddm91c1_de.hlp,Hddm91c1KMMin.DLL, \
- HDNIS01Aux.dll,HDNIS01_de.NTF, \
- Hddm91c1_de_reg.HLP' SAMBA-CUPS
+root# rpcclient -Uroot%xxxx -c 'adddriver "Windows NT x86" \
+ "dm9110:HDNIS01_de.DLL: \
+ Hddm91c1_de.ppd:HDNIS01U_de.DLL:HDNIS01U_de.HLP: \
+ NULL:RAW:Hddm91c1_de.DLL,Hddm91c1_de.INI, \
+ Hddm91c1_de.dat,Hddm91c1_de.def,Hddm91c1_de.hre, \
+ Hddm91c1_de.vnd,Hddm91c1_de.hlp,Hddm91c1KMMin.DLL, \
+ HDNIS01Aux.dll,HDNIS01_de.NTF, \
+ Hddm91c1_de_reg.HLP' SAMBA-CUPS
-cmd = adddriver "Windows NT x86" \
-"dm9110:HDNIS01_de.DLL:Hddm91c1_de.ppd:HDNIS01U_de.DLL: \
- HDNIS01U_de.HLP:NULL:RAW:Hddm91c1_de.DLL,Hddm91c1_de.INI, \
- Hddm91c1_de.dat,Hddm91c1_de.def,Hddm91c1_de.hre, \
- Hddm91c1_de.vnd,Hddm91c1_de.hlp,Hddm91c1KMMin.DLL, \
- HDNIS01Aux.dll,HDNIS01_de.NTF,Hddm91c1_de_reg.HLP"
+cmd = adddriver "Windows NT x86" \
+ "dm9110:HDNIS01_de.DLL:Hddm91c1_de.ppd:HDNIS01U_de.DLL: \
+ HDNIS01U_de.HLP:NULL:RAW:Hddm91c1_de.DLL,Hddm91c1_de.INI, \
+ Hddm91c1_de.dat,Hddm91c1_de.def,Hddm91c1_de.hre, \
+ Hddm91c1_de.vnd,Hddm91c1_de.hlp,Hddm91c1KMMin.DLL, \
+ HDNIS01Aux.dll,HDNIS01_de.NTF,Hddm91c1_de_reg.HLP"
Printer Driver dm9110 successfully installed.
-
-root# smbclient //SAMBA-CUPS/print\$ -Uroot%xx -c 'cd W32X86;dir;pwd;cd 2;dir;pwd'
+root# smbclient //SAMBA-CUPS/print\$ -Uroot%xx \
+ -c 'cd W32X86;dir;pwd;cd 2;dir;pwd'
added interface ip=10.160.51.162 bcast=10.160.51.255 nmask=255.255.252.0
Domain=[CUPS-PRINT] OS=[UNIX] Server=[Samba 2.2.7a]
Current directory is \\SAMBA-CUPS\print$\W32X86\
- . D 0 Sun May 4 04:32:48 2003
- .. D 0 Thu Apr 10 23:47:40 2003
+ . D 0 Sun May 4 04:32:48 2003
+ .. D 0 Thu Apr 10 23:47:40 2003
2 D 0 Sun May 4 04:32:48 2003
40976 blocks of size 262144. 731 blocks available
Current directory is \\SAMBA-CUPS\print$\W32X86\2\
- . D 0 Sun May 4 04:32:48 2003
- .. D 0 Sun May 4 04:32:48 2003
+ . D 0 Sun May 4 04:32:48 2003
+ .. D 0 Sun May 4 04:32:48 2003
DigiMaster.PPD A 148336 Thu Apr 24 01:07:00 2003
ADOBEPS5.DLL A 434400 Sat May 3 23:18:45 2003
laserjet4.ppd A 9639 Thu Apr 24 01:05:32 2003
@@ -1224,62 +1052,54 @@ subdirectory. You can check this again with
HDNIS01U_de.HLP A 19770 Sun May 4 04:32:18 2003
Hddm91c1_de_reg.HLP A 228417 Sun May 4 04:32:18 2003
40976 blocks of size 262144. 731 blocks available
-
-root# rpcclient -Uroot%xxxx \
- -c 'adddriver "Windows NT x86" \
- "myphantasydrivername:HDNIS01_de.DLL: \
+root# rpcclient -Uroot%xxxx \
+ -c 'adddriver "Windows NT x86" \
+ "mydrivername:HDNIS01_de.DLL: \
Hddm91c1_de.ppd:HDNIS01U_de.DLL:HDNIS01U_de.HLP: \
NULL:RAW:Hddm91c1_de.DLL,Hddm91c1_de.INI, \
Hddm91c1_de.dat,Hddm91c1_de.def,Hddm91c1_de.hre, \
@@ -1287,345 +1107,292 @@ with a different driver name, it will work the same:
HDNIS01Aux.dll,HDNIS01_de.NTF,Hddm91c1_de_reg.HLP' SAMBA-CUPS
- cmd = adddriver "Windows NT x86"
- "myphantasydrivername:HDNIS01_de.DLL:Hddm91c1_de.ppd:HDNIS01U_de.DLL:\
- HDNIS01U_de.HLP:NULL:RAW:Hddm91c1_de.DLL,Hddm91c1_de.INI, \
- Hddm91c1_de.dat,Hddm91c1_de.def,Hddm91c1_de.hre, \
- Hddm91c1_de.vnd,Hddm91c1_de.hlp,Hddm91c1KMMin.DLL, \
- HDNIS01Aux.dll,HDNIS01_de.NTF,Hddm91c1_de_reg.HLP"
-
- Printer Driver myphantasydrivername successfully installed.
+cmd = adddriver "Windows NT x86" \
+ "mydrivername:HDNIS01_de.DLL:Hddm91c1_de.ppd:HDNIS01U_de.DLL:\
+ HDNIS01U_de.HLP:NULL:RAW:Hddm91c1_de.DLL,Hddm91c1_de.INI, \
+ Hddm91c1_de.dat,Hddm91c1_de.def,Hddm91c1_de.hre, \
+ Hddm91c1_de.vnd,Hddm91c1_de.hlp,Hddm91c1KMMin.DLL, \
+ HDNIS01Aux.dll,HDNIS01_de.NTF,Hddm91c1_de_reg.HLP"
+Printer Driver mydrivername successfully installed.
-root# rpcclient -U'root%xxxx' -c 'setdriver dm9110 myphantasydrivername' SAMBA-CUPS
- cmd = setdriver dm9110 myphantasydrivername
- Successfully set dm9110 to driver myphantasydrivername.
+root# rpcclient -U'root%xxxx' -c 'setdriver dm9110 mydrivername' SAMBA-CUPS
+ cmd = setdriver dm9110 mydrivername
+
+Successfully set dm9110 to driver mydrivername.
root# rpcclient -U'root%xxxx' -c 'setdriver dm9110 dm9110' SAMBA-CUPS
cmd = setdriver dm9110 dm9110
- Successfully set dm9110 to driver dm9110.
+Successfully set dm9110 to driver dm9110.
+
+rpcclient -U'root%sambapassword' -c 'setdriver printername \
+ drivername' SAMBA-Hostname.
Note
-C:\> runas /netonly /user:root "rundll32 printui.dll,PrintUIEntry /p /t3 /n
- \\SAMBA-SERVER\printername"
+C:\> runas /netonly /user:root "rundll32 printui.dll,PrintUIEntry /p /t3 /n
+ \\SAMBA-SERVER\printername"
Tip
Tip
root# rpcclient SAMBA-CUPS -U root%secret -c 'enumdrivers'
cmd = enumdrivers
@@ -1644,7 +1411,7 @@ following is an example of how this could be accomplished:
Driver Name: [dm9110]
Printer Driver Info 1:
- Driver Name: [myphantasydrivername]
+ Driver Name: [mydrivername]
[....]
root# rpcclient SAMBA-CUPS -U root%secret -c \
- 'setdriver dm9110 "Heidelberg Digimaster 9110 (PS)"'
+ 'setdriver dm9110 "Heidelberg Digimaster 9110 (PS)"'
cmd = setdriver dm9110 Heidelberg Digimaster 9110 (PPD)
Successfully set dm9110 to driver Heidelberg Digimaster 9110 (PS).
-root# rpcclient SAMBA-CUPS -U root%secret -c 'setdriver dm9110 myphantasydrivername'
- cmd = setdriver dm9110 myphantasydrivername
- Successfully set dm9110 to myphantasydrivername.
+root# rpcclient SAMBA-CUPS -U root%secret -c 'setdriver dm9110 mydrivername'
+ cmd = setdriver dm9110 mydrivername
+ Successfully set dm9110 to mydrivername.
@@ -1688,119 +1455,94 @@ following is an example of how this could be accomplished:
cmd = enumprinters
flags:[0x800000]
name:[\\SAMBA-CUPS\dm9110]
- description:[\\SAMBA-CUPS\dm9110,myphantasydrivername,\
+ description:[\\SAMBA-CUPS\dm9110,mydrivername,\
110ppm HiVolume DANKA Stuttgart]
comment:[110ppm HiVolume DANKA Stuttgart]
[....]
Tip
Tip
root# rpcclient -U 'Administrator%secret' -c 'enumdrivers 3' 10.160.50.8
@@ -1860,7 +1602,7 @@ reasons:
Defaultdatatype: []
@@ -1892,13 +1634,14 @@ picture:
> cns3ggr.dll
root# for i in cns3g.hlp cns3gui.dll cns3g.dll; do \
smbclient //10.160.50.8/print\$ -U 'Administrator%xxxx' \
- -c "cd W32X86/3; dir $i; cd .. ; cd 2; dir $i"; \
+ -c "cd W32X86/3; dir $i; cd .. ; cd 2; dir $i"; \
done
CNS3G.HLP A 122981 Thu May 30 02:31:00 2002
@@ -1909,248 +1652,213 @@ comparison:
CNS3G.DLL A 1145088 Thu May 30 02:31:00 2002
CNS3G.DLL A 15872 Thu May 30 02:31:00 2002
-
-rundll32 printui.dll,PrintUIEntry /dn /n "\\sambacupsserver\infotec2105-IPDS" /q
-rundll32 printui.dll,PrintUIEntry /in /n "\\sambacupsserver\infotec2105-PS"
-rundll32 printui.dll,PrintUIEntry /y /n "\\sambacupsserver\infotec2105-PS"
+rundll32 printui.dll,PrintUIEntry /dn /n "\\cupsserver\infotec2105-IPDS" /q
+rundll32 printui.dll,PrintUIEntry /in /n "\\cupsserver\infotec2105-PS"
+rundll32 printui.dll,PrintUIEntry /y /n "\\cupsserver\infotec2105-PS"
+ It puts in place any printer default setup changes automatically at every user logon. +
+ It allows for “roaming” users' login into the domain from different workstations. +
+Since network printers are installed per user, this much simplifies the process of keeping the installation +up-to-date. The few extra seconds at logon time will not really be noticeable. Printers can be centrally +added, changed and deleted at will on the server with no user intervention required from the clients +(you just need to keep the logon scripts up-to-date). +
+The addprinter command can be configured to be a shell script or program executed by +Samba. It is triggered by running the APW from a client against the Samba print server. The APW asks +the user to fill in several fields (such as printer name, driver to be used, comment, port monitor, +and so on). These parameters are passed on to Samba by the APW. If the addprinter command is designed in a +way that it can create a new printer (through writing correct printcap entries on legacy systems, or +execute the lpadmin command on more modern systems) and create the associated share +in, then the APW will in effect really create a new printer on Samba and the UNIX print subsystem! +
+The basic NT-style printer driver management has not changed considerably in 3.0 over the 2.2.x releases +(apart from many small improvements). Here migration should be quite easy, especially if you followed +previous advice to stop using deprecated parameters in your setup. For migrations from an existing 2.0.x +setup, or if you continued Windows 9x/Me-style printing in your Samba 2.2 installations, it is more of +an effort. Please read the appropriate release notes and the HOWTO Collection for Samba-2.2.x. You can +follow several paths. Here are possible scenarios for migration: +
+ You need to study and apply the new Windows NT printer and driver support. Previously used + parameters printer driver file, printer driver + and printer driver location are no longer supported. +
+ If you want to take advantage of Windows NT printer driver support, you also need to migrate the + Windows 9x/Me drivers to the new setup. +
+ An existing printers.def file (the one specified in the now removed parameter + printer driver file) will no longer work with Samba-3. In 3.0, smbd attempts + to locate a Windows 9x/Me driver files for the printer in [print$] + and additional settings in the TDB and only there; if it fails, it will not + (as 2.2.x used to do) drop down to using a printers.def (and all associated + parameters). The make_printerdef tool is removed and there is no backward compatibility for this. +
You need to install a Windows 9x/Me driver into the + [print$] share for a printer on your Samba + host. The driver files will be stored in the “WIN40/0” subdirectory of + [print$], and some other settings and information go + into the printing-related TDBs.
If you want to migrate an existing + printers.def file into the new setup, the + only current + solution is to use the Windows NT APW to install the NT drivers + and the 9x/Me drivers. This can be scripted using smbclient and + rpcclient. See the Imprints installation client at: +
+
+ for an example. See also the discussion of rpcclient usage in the + “CUPS Printing” section.
+This will be addressed in a later update of this document. If you wish to volunteer your services to help
+document this, please contact
+Do not confuse the root password which is valid for the UNIX system (and in most cases stored in the +form of a one-way hash in a file named /etc/shadow), with the password used to +authenticate against Samba. Samba does not know the UNIX password. Root access to Samba resources +requires that a Samba account for root must first be created. This is done with the smbpasswd +command as follows: +
+root# smbpasswd -a root +New SMB password: secret +Retype new SMB password: secret +