Printer queues with Samba and CUPS

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.

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.

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.

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.