no print queues displayed in pure client mode

Bug #1069671 reported by Sascha Steinbiss on 2012-10-22
This bug affects 13 people
Affects Status Importance Assigned to Milestone
cups (Ubuntu)
Till Kamppeter
Till Kamppeter

Bug Description

Package: cups
Version: 1.6.1-0ubuntu11

On 12.10, in pure client mode (ServerName set in client.conf -- see attachment) I am unable to get any remote printers from our university print server.
That is, trying to print from Firefox, only the default PDF printer is shown. I would have expected a large number of queues to be displayed.
I have consulted out sysadmin to obtain more information about the server -- apparently it runs CUPS 1.2.7 on SuSE.
Please find attached the requested nmap output (I had to remove the server IP and hostname by the sysadmin's request).
I have also asked the sysadmin for a server error log, which I have also attached to this bug report. It shows my unsuccessful access attempts.

The same setup worked fine in 12.04. Did I miss something?

-- System Information:
Debian Release: wheezy/sid
  APT prefers quantal-updates
  APT policy: (500, 'quantal-updates'), (500, 'quantal-security'), (500, 'quantal-proposed'), (500, 'quantal'), (100, 'quantal-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.5.0-18-generic (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages cups depends on:
ii adduser 3.113+nmu1ubuntu1
ii bc 1.06.95-4
ii cups-client 1.6.1-0ubuntu11
ii cups-common 1.6.1-0ubuntu11
ii cups-filters 1.0.24-2
ii cups-ppdc 1.6.1-0ubuntu11
ii debconf [debconf-2.0] 1.5.46ubuntu1
ii dpkg 1.16.7ubuntu6
ii ghostscript 9.06~dfsg-0ubuntu4
ii libavahi-client3 0.6.31-1ubuntu2
ii libavahi-common3 0.6.31-1ubuntu2
ii libc6 2.15-0ubuntu20
ii libcups2 1.6.1-0ubuntu11
ii libcupscgi1 1.6.1-0ubuntu11
ii libcupsimage2 1.6.1-0ubuntu11
ii libcupsmime1 1.6.1-0ubuntu11
ii libcupsppdc1 1.6.1-0ubuntu11
ii libdbus-1-3 1.6.4-1ubuntu4
ii libgcc1 1:4.7.2-2ubuntu1
ii libgnutls26 2.12.14-5ubuntu4
ii libgssapi-krb5-2 1.10.1+dfsg-2
ii libkrb5-3 1.10.1+dfsg-2
ii libpam0g 1.1.3-7ubuntu3
ii libpaper1 1.1.24+nmu2
ii libstdc++6 4.7.2-2ubuntu1
ii libusb-1.0-0 2:1.0.12-2
ii lsb-base 4.0-0ubuntu26
ii poppler-utils 0.20.4-0ubuntu1
ii procps 1:3.3.3-2ubuntu3
ii ssl-cert 1.0.32
ii upstart [upstart-job] 1.5-0ubuntu9

Versions of packages cups recommends:
ii avahi-daemon 0.6.31-1ubuntu2
ii colord 0.1.21-1ubuntu2
ii foomatic-filters 4.0.17-1
ii ghostscript-cups 9.06~dfsg-0ubuntu4
ii printer-driver-gutenprint 5.2.9-1ubuntu1

Versions of packages cups suggests:
ii cups-bsd 1.6.1-0ubuntu11
pn cups-pdf <none>
ii foomatic-db-compressed-ppds [foomatic-db] 20120823-0ubuntu4
ii hplip 3.12.6-3ubuntu4
ii printer-driver-hpcups 3.12.6-3ubuntu4
ii smbclient 2:3.6.6-3ubuntu5
ii udev 175-0ubuntu13

-- debconf information:
  cupsys/raw-print: true
  cupsys/backend: ipp, ipp14, lpd, socket, usb, snmp, dnssd

Sascha Steinbiss (satta) wrote :
Sascha Steinbiss (satta) wrote :
Sascha Steinbiss (satta) wrote :
Till Kamppeter (till-kamppeter) wrote :

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, ...?

Changed in cups (Ubuntu):
status: New → Incomplete
importance: Undecided → Medium
Sascha Steinbiss (satta) wrote :

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.

Till Kamppeter (till-kamppeter) wrote :

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?

Sascha Steinbiss (satta) wrote :

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.

Till Kamppeter (till-kamppeter) wrote :

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.

Günther Raidl (raidl) wrote :

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

Sascha Steinbiss (satta) wrote :

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://
device for donau2ps: ipp://
device for donaups: ipp://
device for eFax: socket://federsee:19100
device for elbe2ps: lpd://
device for elbeps: lpd://
device for maggia2ps: ipp://
device for maggiabw2ps: ipp://
device for maggiaps: ipp://
device for maggiatps: 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/

Guido (guido-selva) wrote :

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).

Ool (0ol) wrote :

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.

Günther Raidl (raidl) wrote :

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

Sascha Steinbiss (satta) wrote :

No change for me either. :/

James Montaldi (j-montaldi-4) wrote :

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.

James Montaldi (j-montaldi-4) wrote :

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!

Sascha Steinbiss (satta) wrote :

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 Thanks.

der_vegi (m-may) wrote :

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).

der_vegi (m-may) wrote :

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.

James Montaldi (j-montaldi-4) wrote :

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.

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)

Sascha Steinbiss (satta) wrote :

Added strace/ltrace output to the upstream bugtracker.

James Montaldi (j-montaldi-4) wrote :

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.


der_vegi (m-may) wrote :

It looks like the reason for this bug has been found upstream in the bug report 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.

Changed in cups (Ubuntu):
status: Incomplete → Confirmed
Changed in cups (Ubuntu Quantal):
status: New → Confirmed
importance: Undecided → Medium
assignee: nobody → Till Kamppeter (till-kamppeter)
Changed in cups (Ubuntu):
assignee: nobody → Till Kamppeter (till-kamppeter)
milestone: none → ubuntu-13.04-feature-freeze
Changed in cups (Ubuntu Quantal):
milestone: none → quantal-updates
Amos (a-storkey) wrote :

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!

Amos (a-storkey) wrote :

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.

Changed in cups (Ubuntu):
status: Confirmed → In Progress
Changed in cups (Ubuntu Quantal):
status: Confirmed → Triaged

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.

Changed in cups (Ubuntu):
status: In Progress → Fix Committed
Launchpad Janitor (janitor) wrote :

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

Changed in cups (Ubuntu):
status: Fix Committed → Fix Released
Daniel Richard G. (skunk) wrote :

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
    WARNING: gnome-keyring:: couldn't connect to: /run/user/dgomez/keyring-VYcpvh/pkcs11: No such file or directory
    defprint is ready
    no entries

    $ 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
    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 "". It never calls cupsSetServer().

In CUPS 1.6.2 in Raring this should be completely fixed.

Daniel Richard G. (skunk) wrote :

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

I put it into Raring yesterday.

Daniel Richard G. (skunk) wrote :

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:

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:

Reece Pollack (reece-pollack) wrote :

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?

Reece Pollack (reece-pollack) wrote :

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

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.

Rolf Leggewie (r0lf) wrote :

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".

Changed in cups (Ubuntu Quantal):
status: Triaged → Won't Fix
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.