5

I've successfully got Samba and CUPS working together to give nice, consistent printing interfaces with just the Postscript drivers to Windows clients both IA32 and x64 of any variants since 95. The printing related parts of smb.conf are:

[global]
   load printers = yes
   printing = cups
   printcap name = cups

And later these shares:

[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

This successfully enumerates all of the CUPS printers and clients can print fine.

The problem I'm having though is that Windows clients almost never see any jobs in the queue other than their own jobs and only for a very short period, presumably whilst the job is spooling to the server. This has the knock on effect that if someone wants to cancel one of their jobs they either power off the printer(!) or ask me to do it.

I was under the impression that the combination of printing = cups and printcap name = cups in [global] alleviated the need to use settings like lpq command to make queue management functionality available since it used libcups directly. On a test server though setting a sensible value for lpq command changes the observed behaviour slightly such that pressing F5 to refresh a queue in windows displays the job(s) momentarily, before they disappear again. What am I missing?

I suspected at one point it was related to the read only setting on the [printers] share. What does the read only = yes part of the [printers] share mean? Is it related to queue administration tasks? I can't see any observable difference when changing it either way, but I'd like to understand rather than just guess! Presumably it's something different to what it means in the usual file share context since the [printers] share has some printing related magic going on behind the scenes. I can't find any specific documentation on this related to printer shares though.

Flexo
  • 588
  • 9
  • 23
  • Doesn't directly answer your question, but in all windows environments that I manage, the print jobs (even when they're quite a few pages) spool so quickly through the software and then to the printer, there's no way for the user to catch them in time in the print queue to cancel them. When purchasing a printer, I always look for one with a dedicated 'Cancel Job' button on the top. Having said that, there is the rare instance when a job breaks the queue and causes everything else to stop, and the user needs to cancel that job to resume normal print operations. – Dom Oct 08 '11 at 07:03
  • @Dom - I can see the jobs for quite a while via CUPS (e.g. with `lpq`) on the UNIX side, it's just the Windows clients that seem to be lacking any sort of "global" view of the printer status. – Flexo Oct 09 '11 at 07:43

4 Answers4

1

I had exactly the same problem as in your description.

It turns out to be a privacy policy setting in cups.

In your cupsd.conf try

JobPrivateValues none

instead of

JobPrivateValues default

By default for an unauthenticated IPP Get-Jobs request cups does not return the attributes job-name and job-originating-user-name. But they are required by samba to successfully return the queue.
https://git.samba.org/?p=samba.git;a=blob;f=source3/printing/print_cups.c#l1378

To see if you have the same problem you can tell samba to talk to cups over network so you can use wireshark to dump the ipp traffic.

In smb.conf use e.g.

cups server = localhost

Now open the the printer on a Windows client and try to display the queue. Capture the resulting traffic between samba and cups and compare it with the traffic generated from a local command like

lpstat -h localhost -o

( If you don't use -h then lpstat uses a unix-socket to talk to cups and nothing ist captured.
For Windows clients samba caches the queue for 30 seconds so it could take a while before samba talks to cups - see lpq cache time in smb.conf. )

In the latter capture I saw the job-name and job-originating-user-name attributes. These were missing the Windows capture. After modifying cupsd.conf as said these attributes where also in the Windows capture and the queue was displayed on the Windows client.

Jörg Schulz
  • 150
  • 4
1

The local windows spool simply delivers it to the remote spool.

I guess in order for your wish to work (that everybody sees everyone queued stuff) will only work with some Windows Printing Queue, but i am far from a windows expert. I'd look into IPP, i am also not sure if lpd was designed to send the queue back to the client, but rather to only submit your things to the server.

Franz Bettag
  • 927
  • 8
  • 7
  • Really? I thought the Windows view of the printer queue via Samba should mirror the global view of the printer queue as seen by the Samba server, e.g. if I ran `lpq` on the Samba server and see 3 jobs I'd see 3 jobs by looking at the queue via `\\server\queue` in Widows. – Flexo Oct 09 '11 at 07:36
1

You could try using IPP from windows (define network printers as http://server:631/printers/printer-name and use Generic printer with Microsoft Imagesetter).

I don't remember if it lists all jobs until they are dequeued -- I configure my printers to abort failed jobs on CUPS.

Hubert Kario
  • 6,361
  • 6
  • 36
  • 65
0

Isn't it possible to setup CUPS so that clients can view and/or cancel their own jobs via the web interface via a specific cancel policy?

http://cupsServerIP:631

http://www.cups.org/documentation.php/policies.html

dtbnguyen
  • 322
  • 1
  • 6