no print queues displayed in pure client mode

Can you attach the /etc/cups/cupsd.conf of the server?

Can you open a browser on the client and go to

http://<IP address of server>:631/

with <IP address of server> replaced by the server's IP address? This should show the server's administration web interface. Can you also browse around there, like showing the printer's entries, jobs, ...?

I have attached the cupsd.conf. Curiously, it contains a "Browsing Off" setting -- could that be the problem? If so, I wonder why I was able to view the list before...

Also, I am able to view and browse the web interface, show printer statuses, jobs, etc. I get a 403 error trying to access the admin section -- that was to be expected though.

FYI: For now, I have worked around the problem by manually adding the remote printer queue.

Browsing settings in cupsd.conf are not important, they are only important for CUPS daemons on client and server talk to each other and so the client's daemon gets the server's queues. You specify the server in client.conf which makes the client directly talking to the server's CUPS daemon and not to the local CUPS daemon. With this configuration you can even stop the local CUPS daemon as the applications do not talk to it. If there are no access permission problems the client should see the server's print queues.

What you have to check:

1. Make sure that your router (DHCP server) always assigns the same IP address to your server and to your clients.

2. Is the host name or IP in the client.conf the correct one of the server. In case of a host name, does the client resolve the name correctly (run "host <NAME>") and check whether the correct IP address gets found.

3. In cupsd.conf you choose explicit IP addresses for the clients which are allowed to connect. Check whether the addresses are correct. Run "ifconfig" on the client to find out which IP address it has. Try also allowing access to the whole local network by using @LOCAL istead of a concrete IP address.

4. Is there nothing like a firewall or similar in the way?

Thanks for the reply Till, and for the enlightenment on the meaning of the browsing options. Now for your questions:

1. Yes, I have double-checked that I get the same IP every time (my MAC address is hard-linked on the DHCP server to always obtain the same fixed IP and reverse DNS entry). The server also has a fixed IP that did not change since my upgrade to 12.10.

2. Yes, it is correct -- I also double-checked. I have used an IP address to ensure that DNS is not the problem (see attachment #2) and the address is the correct one for the CUPS server.

3. Yes, the IP address of my client is within one of the IP ranges given in the "Allow" directive.
Unfortunately, I am afraid I cannot change the CUPS server settings here (e.g. to @LOCAL) -- it is a production print server in a medium-sized research institution network and all changes would have to go through the sysadmins, who are keeping permissions naturally tight.

4. Not for hosts on the internal /24 network -- from outside only SSH access through a bastion host is supported. But I tried printing from the internal network of course.

What strikes me most is that everything worked fine on 12.04 and the problem suddenly appeared only after my 12.10 install. According to the sysadmins, nothing was changed at the same time on the server or network side -- so I just assumed it was a subtle CUPS 1.6 change in client configuration I missed.

Can you attch the /etc/cups/printers.conf of your print server and also the output of "lpstat -v" run in a terminal on the server.

I just want to confirm that the exact same situation applies to me: All my printer configuration consists of adding the print server to /etc/cups/client.conf and pre 12.10 that worked perfectly. Now, my printer dialogues don't show a thing, AND (not sure if the bug-originator tested this) trying to open the printer settings dialogue from the System Settings results in "bad client error" from cups.

I have the very same problem, exactly as stated in the mails above!

The requested printers.conf is attached.

# lpstat -v
device for adige2ps: lpd://adige
device for adigeps: lpd://adige
device for adigetps: lpd://adige
device for alster: socket://alster.zbh.uni-hamburg.de:9100/
device for donau2ps: ipp://donau.zbh.uni-hamburg.de/ipp
device for donaups: ipp://donau.zbh.uni-hamburg.de/ipp
device for eFax: socket://federsee:19100
device for elbe2ps: lpd://elbe.zbh.uni-hamburg.de/elbe
device for elbeps: lpd://elbe.zbh.uni-hamburg.de/elbe
device for maggia2ps: ipp://maggia.zbh.uni-hamburg.de:631/ipp
device for maggiabw2ps: ipp://maggia.zbh.uni-hamburg.de/maggia
device for maggiaps: ipp://maggia.zbh.uni-hamburg.de/ipp
device for maggiatps: ipp://maggia.zbh.uni-hamburg.de:631/ipp
device for nahe2ps: lpd://nahe
device for naheps: lpd://nahe
device for nahetps: lpd://nahe
device for pinau2ps: lpd://pinau
device for pinaups: lpd://pinau
device for pinautps: lpd://pinau
device for rhone: lpd://rhone
device for rhone2ps: lpd://rhone/
device for rhonebw2ps: lpd://rhone/
device for rhonepcl: lpd://rhone
device for rhoneps: lpd://rhone
device for rhonetps: lpd://rhone
device for tiber2ps: socket://tiber:9100/
device for tiberps: socket://tiber:9100
device for tibert: socket://tiber:9100/

I have exactly the same problem.

Everything worked fine on 12.04 and the problem suddenly appeared on 12.10 (nothing changed on the CUPS server).

I have the same problem too.
with a release-upgrade (12.04=>12.10 or with the 12.10 liveCD

Server run Common UNIX Printing System 1.3.8 And work fine for ~200 others GNU/LINUX clients (major part is Ubuntu 12.04 10.04 , and some Debian Squeeze and Fedora)

Can you try to move your client.conf? Put it into your home directory as ~/.cups/client.conf and remove /etc/cups/client.conf. Have you access to the server's printers now?

Make also sure that if you want to use /etc/cups/client.conf that you do not have ~/.cups/client.conf, as if you have ~/.cups/client.conf, even empty, /etc/cups/client.conf will never get read.

Unfortunately, moving client.conf to ~/.cups as described above doesn't change anything concerning this problem in my case.

No change for me either. :/

I have exactly the same problem described here, and it manifested _during_ the upgrade to 12.10 (I was still using my computer with 12.04 while installing the upgrade, and suddenly could no longer see the print queues when hitting Ctrl-P in Acroread or Firefox).
I have also moved client.conf to ~/.cups (and rebooted) but it makes no difference. I can also browse the printer server through IP:631 as described above.

Reported upstream as https://www.cups.org/str.php?L4231.

I don't know if this is relevant, but if I enter lpq in the terminal, I get
WARNING: gnome-keyring:: couldn't connect to: /run/user/james/keyring-u2yoge/pkcs11: No such file or directory
And listing that directory gives only one entry, a socket file called control=

I have a default printer set in ~/.cups/lpoptions

As I said, I have no idea if this is relevant!

Thanks. I just read your upstream bug report and I have to add a bit of clarification: If I have a client.conf in place, I don't even see my local queues, there is just nothing.
To see my local queues I have to rename the client.conf.

Everyone who is affected, pleas follow the instructions of mike's comment in the upstream bug report https://www.cups.org/str.php?L4231. Thanks.

Same problem here, cups-server in a medium-sized institution. No problems in 12.04, after upgrade to 12.10, the connection to the cups-server does not work any more. Attaching the troubleshooting (from the troubleshooting-dialogue after purging cups from my system and reinstalling it).

I don't know, if that helps: If I downgrade cups* to 1.5 from precise, I still cannot see any printers. As soon as I downgrade libcups2 to 1.5, however, it works.

der_vegi, the cups package contains the CUPS daemon and the libcups2 package the code for the clients (like print dialogs) to access CUPS. If you set a CUPS server via client.conf all clients using libcups2 directly talk to the server's CUPS daemon and the local CUPS daemon does not get used any more. So replacing the local CUPS daemon has no effect as it is not used. The bug is in libcups2, in the code for the client to switch to the external server according to client.conf and it seems that the bug appeared with the transition from CUPS 1.5.x to 1.6.x.

Please also follow the instructions of my comment #22.

I uploaded my reports to the cups site as suggested, but I have no response or update. Can some one else uplaod their's too, to see if we do have the same problem.
James

ps If I enter lpq I get the error warning
WARNING: gnome-keyring:: couldn't connect to: /run/user/james/keyring-Ii2RXp/pkcs11: No such file or directory

This looks more like an ubuntu problem, not a cups one. But I don't really know what the relevance of the gnome-keyring is, nor of pkcs11 (for what it's worth, I use kubuntu, not gnome, though I do have both desktops installed)

Added strace/ltrace output to the upstream bugtracker.

Well - I've got fed up not being able to print, so have downgraded to Ubuntu 12.04.
Please update this page to say the problem's solved when it is, and I'll upgrade again.

James

It looks like the reason for this bug has been found upstream in the bug report https://www.cups.org/str.php?L4231 mentioned above. CUPS 1.6.1 uses IPP 2.0 by default failing to talk to older CUPS servers. You can now also find a workaround-patch there.

der_vegi, the upstream developer is working on a fix. As soon as the working fix is available, I will apply it to the Ubuntu package of CUPS and also issue a Stable Release Update (SRU) for Quantal.

Excellent. It seems a fix is now available that includes a version tag, which seems like a good solution. It would be great if this could be applied to the Ubuntu CUPS package and then all will be solved!

Till - you suggested you would apply this fix to the Ubuntu package? This fix has now been updated the CUPS sv repository. Could you push it out to Ubuntu CUPS when you get a chance? Thanks.

I have applied the upstream fix to the Debian GIT repository of CUPS now, so that it gets into Raring with the next CUPS package.

This bug was fixed in the package cups - 1.6.1-2

---------------
cups (1.6.1-2) experimental; urgency=low

  [ Till Kamppeter ]
  * In upstart, let the CUPS daemon start after avahi-daemon, to assure
    that the Bonjour broadcasting of shared printers works.
  * Import upstream patch to add support for specifying the IPP version
    of a remote CUPS server in /etc/cups/client.conf (LP: #1069671),
    refresh the other ones affected.

  [ Didier Raboud ]
  * Cherry-pick more upstream enhancements:
    - Add french translation (CUPS STR: #4247)
  * Refresh po4a translations
  * Merge the 1.5.3-2.14 Debian release.
  * Correct Replaces/Breaks versions of cups-daemon against cups to cope
    with recent Ubuntu releases (LP: #1099242).
  * Make sure /e/cups/raw.{convs,types} are deleted during purge.
    (Closes: #698213)
  * Take manpage translations out of the manpage-translations patch to
    ease external contributions to the .po files.
  * Add usb-backend quirk for Epson Stylus Photo 750 (Closes: #697970)

  [ Helge Kreutzmann ]
  * Update German manpages translation. (Closes: #698965)

  [ Julien Patriarca ]
  * Update French manpages translation. (Closes: #700295)

  [ Vincent McIntyre ]
  * Document the way to make sure LPD support, as provided by cups-bsd,
    is kept enabled across upgrades. (Closes: #671347)

 -- Didier Raboud <email address hidden> Thu, 14 Feb 2013 21:35:20 +0100

The IPP-version patch does not appear to (fully) fix the problem.

I'm testing a build of 1.6.1-2 on Quantal. It works if I specify the server hostname (with version directive) on the command line, but not if I specify same via the CUPS_SERVER environment variable or /etc/cups/client.conf:

    $ lpq -h cups-server.example.com/version=1.1
    WARNING: gnome-keyring:: couldn't connect to: /run/user/dgomez/keyring-VYcpvh/pkcs11: No such file or directory
    defprint is ready
    no entries

    $ CUPS_SERVER=cups-server.example.com/version=1.1 lpq
    WARNING: gnome-keyring:: couldn't connect to: /run/user/dgomez/keyring-VYcpvh/pkcs11: No such file or directory
    lpq: Unable to connect to server.

    $ cat /etc/cups/client.conf
    ServerName cups-server.example.com/version=1.1
    Encryption Required
    $ lpq
    WARNING: gnome-keyring:: couldn't connect to: /run/user/dgomez/keyring-VYcpvh/pkcs11: No such file or directory
    lpq: Unable to connect to server.

I traced through the code a bit, and found that in the latter two cases, CUPS is actually doing a DNS lookup on "cups-server.example.com/version=1.1". It never calls cupsSetServer().

In CUPS 1.6.2 in Raring this should be completely fixed.

Ah, I see upstream just released 1.6.2. Will try it once it hits Raring.

I put it into Raring yesterday.

I've tested 1.6.2 in a Quantal install, and confirmed that appending "/version=1.1" to ServerName in /etc/cups/client.conf works as intended.

The new option still needs to be documented, and I've filed a Debian bug to this end:

    http://bugs.debian.org/704238

I'd also note that when the client can't talk with the server, it may behave oddly. I just added a comment to this older Debian bug, which I believe may be due to the same underlying issue:

    http://bugs.debian.org/695601

It's been over a month since this was fixed in Raring, and almost a month since someone tested it on Quantal.

When will a backport to Quantal be available as a package?

To answer my own question (since no one else bothered), here's a PPA providing CUPS "1.6.2-1ubuntu2~quantal~ppa0":

https://launchpad.net/~teward/+archive/cups-backports/

Installed on my x86_64 system running Linux Mint 14 (Nadia) XFCE it solves my problem with a minimum of upgrade ripples or other disruption.

quantal has seen the end of its life and is no longer receiving any updates. Marking the quantal task for this ticket as "Won't Fix".