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.