Store Windows print driver on Samba for a CUPS print server

Question

I'm trying to setup a (Debian) print server for both my Windows and Linux (Ubuntu) workstations.

What I aim to have:

• Printers are configured on print server's CUPS. Queue are created and managed (pause, transfer, etc.) here (id. the web GUI).
• Windows and Linux workstations uses the print server to print: they don't need to know the printers IP address.
• Windows workstations are able to set print settings (duplex, color, collation, stapling, booklet, hole punch, etc.) as they could had they installed the Windows drivers the "standard" way (double click on .exe, direct communication with printer).
• Print drivers are offered to Windows workstations by the print server itself (Samba calls this Point'n'Print).
• No user password (for now, might change in the future).

Note: from now on and unless specified otherwise, "CUPS" will refer to the CUPS daemon running on the print server I aim to build.

What I got working currently:

• Printers were added to CUPS using ipp:// or socket:// and the PPD files from the printer manufacturer (or HPLIP). Printing from CUPS works (test print page via the web GUI).
• Linux workstation can add a printer locally using Ubuntu "add printer" wizard to look for printers that are shared via CUPS: just have to type the print server FQDN/IP.
• Printers are listed on \print-server\ browsed from a Windows workstation.
• Printers are listed via smbclient -L print-server -N ran from a Linux workstation.

Currently not working:

• Cannot add the Windows printer driver to CUPS using the "printmanagement.msc" MMC (I get a "access denied" error). So Samba's Point'n'Print will not work.

I understand there is an issue on authentication that prevent Windows from reading/writing files to install drivers on the Samba server. I have managed to make Samba asks for user/password when accessing \print-server\ from a Windows workstation but neither the UNIX root password nor a normal UNIX user worked.

Currently weirdly working:

• If I manually provide the printer drivers to Windows workstation (since "Point'n'Print" is not working) when adding printer from \print-server\, user/workstation print settings are not always taken into account.

  It seems CUPS default options interfere with the workstation's ones: I set duplex printing off by default on CUPS but want it to work if the user tick the checkbox on it's printing settings.

  Where should I go to make CUPS use user's settings?

• I have some encoding issues: some printed pages have unusual and random letter spacings.

  Is there some settings that can improve compatibility for any document (PDF, Word, image, etc.)?

Environment:

• No Windows domain involved: no Active Directory, no Microsoft/Samba primary/secondary domain controller at all.
• Debian v8.2 "Jessie"
• Samba v4.1 (fresh install, no other shares)
• CUPS v1.7
• Windows workstations: Windows 7 & 8
• Linux workstations: Ubuntu 14.04
• Printers are: Xerox and HP
• HPLIP v3.14.6

smb.conf (all package's default settings):

[global]
   workgroup = MYWORKGRP
   dns proxy = no
   log file = /var/log/samba/log.%m
   max log size = 1000
   syslog = 0
   panic action = /usr/share/samba/panic-action %d
   server role = standalone server
   passdb backend = tdbsam
   obey pam restrictions = yes
   unix password sync = yes
   passwd program = /usr/bin/passwd %u
   passwd chat = *Enter\snew\s*\spassword:* %n\n *Retype\snew\s*\spassword:* %n\n *password\supdated\ssuccessfully* .
   pam password change = yes
   map to guest = bad user
   usershare allow guests = yes
[homes]
   comment = Home Directories
   browseable = no
   read only = yes
   create mask = 0700
   directory mask = 0700
   valid users = %S
[printers]
   comment = All Printers
   browseable = no
   path = /var/spool/samba
   printable = yes
   guest ok = no
   read only = yes
   create mask = 0700
[print$]
   comment = Printer Drivers
   path = /var/lib/samba/printers
   browseable = yes
   read only = yes
   guest ok = no

From what I read, many uses Samba to share files and printers on a Windows network so I am pretty sure I am missing something somewhere...

Solution

1.

So your first problem seems to be this:

Currently not working:

• Cannot add the Windows printer driver to CUPS using the "printmanagement.msc" MMC (I get a "access denied" error). So Samba's Point'n'Print will not work.

Note, that the Windows clients do not retrieve their printer drivers from CUPS, and CUPS itself cannot communicate with the Windows clients directly.

Only Samba can do that, so Windows clients will retrieve their printer drivers from Samba. Samba poses as a Windows print server for the clients, and Samba will also provide a special share (listed [print$] in smb.conf) for clients to auto-install the drivers from. (You should try to use the UNC path of \\myserver\print$ or \\myworkstation\print$ in Windows explorer and see the drivers from any host which shares a printer.)

Windows users need a special privilege in to administer printers and configuring/uploading drivers. This privilege was named SePrintOperatorPrivilege by Microsoft.

Samba implements the SMB set of Windows networking protocols and procedures so Windows clients can use its services.

Hence, only users which have this privilege granted can upload and preconfigure printer drivers to a Samba server, just like it would be the case for a Windows print server.

Typically, you would want to grant the privilege to the Domain Admins group, plus, maybe another Domain Group you may have called Our Printer Admins. I now assume your domain name is MYDOMAIN.

To grant the named user groups that right, execute the following commands:

  net rpc rights grant "MYDOMAIN\Domain Admins" \
     SePrintOperatorPrivilege -U "MYDOMAIN\administrator"

  net rpc rights grant "MYDOMAIN\Our Printer Admins" \
     SePrintOperatorPrivilege -U "MYDOMAIN\administrator"

  net rpc rights grant "MYDOMAIN\User54321" \
     SePrintOperatorPrivilege -U "MYDOMAIN\administrator"

In each case you'll be prompted to supply the domain admin password:

  Enter MYDOMAIN\administrator's password:

If you know this password and everything works, you'll see this confirmation:

  Successfully granted rights.

Of course, you could grant this privilege to one or more individual domain users (example above: MYDOMAIN\User54321) too. But this is not recommended. Better grant the privilege to a group instead of individual accounts. This enables you to add and revoke the privilege by updating the group membership.

To list all users and groups having the SePrintOperatorPrivilege privilege granted, enter:

  net rpc rights list privileges SePrintOperatorPrivilege\
     -U "MYDOMAIN\administrator"

You should see the following output:

  SePrintOperatorPrivilege:
     BUILTIN\Administrators
     MYDOMAIN\Domain Admins
     MYDOMAIN\Our Printer Admins
     MYDOMAIN\User54321

You've now created the pre-condition that users listed above can upload and install printer drivers to your Samba server.

---

(Update: Just had a closer look at the smb.conf you quoted above... Replace MYDOMAIN\ with MYWORKGRP\ for the commands I gave, or skip it altogether and just use a user name or a group name known to Samba. You could possibly also temporarily try guest ok = yes inside the [print$] stanza. Don't forget to set it back to no once your drivers are in place...)

---

2.

Your second problem seems to be:

It seems CUPS default options interfere with the workstation's ones: I set duplex printing off by default on CUPS but want it to work if the user tick the checkbox on it's printing settings.

Where should I go to make CUPS use user's settings?

CUPS by default does not "filter" print jobs it gets handed over by Samba. It processes them as "raw" jobs and just passes them to the real print hardware device.

So if the driver is correctly installed on the Windows print clients, whatever job options they click, should be honored by the printer, regardless of default settings which may be configured into CUPS for CUPS-local printing...

You cannot "make" CUPS use user's settings -- CUPS will just pass them through.

Comments

[Admin]

easy work around is to tell the windows box that it's a postscript printer and let the other box do all the rendering

[Admin]

How do you that? Specify a special printer driver? How will the Windows box know about every supported printing features (duplex, booklet, stapling, etc.)?

[Admin]

do a web search on samba windows print driver

[Admin]

This link should work for you. But I haven't succeed yet. wiki.samba.org/index.php/…

[jduncanator]

The answer to the second problem isn't always true. If you have set the print queue up as a raw queue, then this will hold, as the print queue simply forwards the print job to the printer directly, without modifying it. If you setup the print queue with PPD's provided by the manufacturer on the CUPS server itself, then CUPS exposes the printer as a simple PostScript printer and will potentially interfere with the settings chosen by the user in their local driver options. If you want to have full control from the client workstation, you are best to use a raw print queue.

[user755506]

@jduncanator: Note my usage of the "default" keyword.... Also note that the context of this question is "Samba". In which case we don't see the job transferred from Windows client to CUPS server via IPP, but via SMB. In which case most of your arguments aren't true. You seemed to have had IPP in mind, not looking left nor right...

[jduncanator]

When using CUPS as the backend, the print job is never transferred directly to the printer, it always goes through CUPS (otherwise you would not be able to manage the queue via CUPS), regardless of how it gets there. CUPS allows creation of raw printers (i.e., no print file format translation) as well as smart printers (i.e., CUPS does file format conversion as required for the printer). When using a "smart printer" (eg. one with a PPD file attached), CUPS will try to interpret the supplied print job and submit it to the printer in the format described by the PPD format.

[jduncanator]

From the description provided in the question, it sounds like the OP has created a "smart printer" by providing a PPD file and having the option to set default print options available to them. Smart printers are usually used with generic PostScript print drivers on the client that are not manufacturer specific (the specifics of the printer are handled by CUPS). Of course, you can use the manufacturer drivers, but as the majority of the options are handled by CUPS, the options you set in the manufacturer drivers may not always carry over to the final job.

[user755506]

Thanks for trying to teach me about CUPS/Samba printing, Young Padawan. However, I STILL advise you to try what the union of "silent" default settings with the ones you did possibly override in your smb.conf in Samba are: run testparm -sv | grep --color -Ei '(print|driv|spool|devmode)' to see if there are surprises. Some Samba versions or some Linux distros ship default settings where in a print command = ... mentions "raw"....

[user755506]

Whatever you do and think -- make sure you check the behavior of your CUPS server. Look in the log of an arriving job which comes from a Windows client that is NOT using IPP, but SMB. Set in your cupsd.conf the LogLevel Debug. Then look for lines containing "Auto-typing file..." and the following. You will see s.th. like "Request file type is <something>". If you see 'something' as 'application/postscript' then you are right. For all other cases you are wrong.

[jduncanator]

I definitely agree, it's certainly not always the case, however, a lot of manufacturers provide PostScript drivers by default, and if the user on Windows has installed the PostScript driver, the job will be submitted as PostScript to CUPS, where the job may be interpreted and converted to the format specified in the PPD, and any of the options chosen on the client may be modified or overridden. I have run into this specific issue recently, and in our instance the solution was to use a Raw print queue, as we did not have the need to provide printer descriptions to Linux clients.

[user755506]

The job will ONLY be interpreted if the request file type is 'application/postscript'. It will NOT be interpreted if the request file type is 'application/vnd.cups-postscript' or 'application/vnd.pcl' or 'application/octet-stream' or anything else. And if you had the problem with Linux clients, you are now talking a different topic. Linux clients by default use IPP, not SMB. There the behavior of CUPS is different...

[jduncanator]

It seemed like he was having issues with the CUPS default options overriding set options in the driver only on Windows, where he manually installed the manufacturers drivers for the printer that was shared via Samba. If he is using the PostScript drivers they will (most likely) be submitting them as application/postscript (they were in our case), and CUPS will be interpreting the request. If I've missed something in the initial question that mentions otherwise, I apologize, I was only trying to provide help based on my experience with non-raw queues and Windows clients.