Timeline for Store Windows print driver on Samba for a CUPS print server
Current License: CC BY-SA 3.0
11 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Mar 7, 2018 at 2:43 | comment | added | 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.
|
|
| Mar 7, 2018 at 2:38 | comment | added | Kurt Pfeifle | 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... | |
| Mar 7, 2018 at 2:34 | comment | added | 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. | |
| Mar 7, 2018 at 2:28 | comment | added | Kurt Pfeifle | 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. | |
| Mar 7, 2018 at 2:15 | comment | added | Kurt Pfeifle |
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"....
|
|
| Mar 7, 2018 at 2:14 | comment | added | 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. | |
| Mar 7, 2018 at 2:11 | comment | added | 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. | |
| Mar 7, 2018 at 1:41 | comment | added | Kurt Pfeifle | @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... | |
| Mar 7, 2018 at 1:39 | comment | added | 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. | |
| Apr 3, 2017 at 21:06 | history | edited | Kurt Pfeifle | CC BY-SA 3.0 |
added 71 characters in body
|
| Apr 3, 2017 at 17:56 | history | answered | Kurt Pfeifle | CC BY-SA 3.0 |