Remote printing doesn't work

I updated from Leap 15.1 to Leap 15.3 and all my remote queues stopped working. I use two printers on my desktop computer that are shared by means of IPP. I noticed this problem after upgrading my notebook that uses these queues remotely. I hoped that upgrading the desktop (server) computer will help, but it did not help.

I send jobs to the printer from my notebook(s), and they are marked as finished with no error message (I checked it from /var/log/cups/error_log file and from cups network interface). But the server computer doesn’t even receive these jobs, there is no trace of them there. The firewall on the server computer is off, and I tried to stop the firewall on my notebooks. No effect.


Take a look in ‘/usr/lib/YaST2/bin/’ – some test scripts are located in that directory – the documentation is here – <>.

  • For example, to test the TCP/IP connectivity –
 # /usr/lib/YaST2/bin/test_remote_socket «***HOST***» «***PORT***»
  • To test the IPP functionality –
 # /usr/lib/YaST2/bin/test_remote_ipp «***HOST***» «***QUEUE***»

Thanks, but the results of the YaST tools don’t look suspicious:

lashkevi@asus-lashk:~> /usr/lib/YaST2/bin/test_remote_socket uulashk.local 631

Port '631' on host 'uulashk.local' accepts data
lashkevi@asus-lashk:~> /usr/lib/YaST2/bin/test_remote_ipp uulashk.local ml2015

Connection possible to IPP port 631 on host 'uulashk.local'

Testing queue 'ml2015' on host 'uulashk.local':
request id is ml2015-11028 (0 file(s))

Queue 'ml2015' on host 'uulashk.local' accepts print jobs
lashkevi@asus-lashk:~> /usr/lib/YaST2/bin/test_remote_ipp uulashk.local dj1515

Connection possible to IPP port 631 on host 'uulashk.local'

Testing queue 'dj1515' on host 'uulashk.local':
request id is dj1515-11029 (0 file(s))

Queue 'dj1515' on host 'uulashk.local' accepts print jobs

Everything looks normal, except the jobs do not appear in the printers’ queues on the server side.

Removed and reinstalled the printers on the server. No use.

Check that cupsd.conf hasn’t been overwritten (during the upgrade) perhaps. On the server, check the <location> directive allows access from the clients, and that CUPS is listening on the IP address connected to your LAN.

Useful reference:

Sorry to interfere without actually being helpful…

I’m afraid it is not supported to do the direct upgrade. On top of the “usual” recommendations for step-by-step upgrades, there is explicit advice not to skip 15.2:

Warning: Do not skip a release when upgrading! Example: do not upgrade from 15.1 to 15.3. Instead, from 15.1 upgrade to 15.2, and only then from 15.2 to upgrade to 15.3.

Note: for 15.3 specifically only the upgrade from a fully updated 15.2 is supported. See the Release Notes, chapter 2.1 (Seamless upgrade from openSUSE Leap 15.2).

I don’t know if that has anything to do with your issues - and it’ll probably too late for you unless you can & want to do a snapper rollback to a pre-upgrade snapshot. But it may be worth noting for others planning their upgrades.

The server’s /etc/cups/cupsd.conf:

# Only listen for connections from the local machine.
Listen *:631
Listen localhost:631
Listen /var/run/cups/cups.sock
<Location />
Allow @LOCAL
Order allow,deny

But I am afraid that the trouble is on the client’s side, since it appeared after updating the system on my laptop.

Ok, and did you read kasi042**'**s advice?

It is surely not a step-by-step upgrade. For 15 years of using SUSE Linux I never did it and I am not intended to do it in future. Any upgrade is a huge waist of time, and I do it as infrequent as possible.

I checked the completeness of the list of cups packages on both sides. The configuration files /etc/cups/cupsd.conf and /etc/cups/cups-browsed did not change during the upgrades. Moreover, the cups version (2.2.7) did not change (only cups-filters version changed, in fact). So I think there IS a problem in the distribution. But before filing a bug, I want to make sure, that I there is no my fault in the problem and that I understand its nature. (Unfortunately, each distribution except SUSE 9.3 had certain irregular problems. Usually I cured them by replacing packages by those from the experimental' or community’ repositories.)

Solved. As I expected, it was an issue of cups-filters-1.25.0 (or its build). I installed cups-filters-1.28.8 from just now appeared repository Printing for Leap 15.3 to the laptop, and now everything works. Hope, it will be useful to anyone who will encounter this problem. And tomorrow I will file a bug.

Thanks for sharing your finding.

Hi all
I had (almost) the same Problem on OpenSuse 15.3 with cups packages off official suse repos, ie.

cups: 2.2.7-3.26.1-x86-64
cupsfilters: 1.24.0-3.3.1-x86-64

I added the repo for Opensuse 15.3: Printing_15.3
then used Yast Softwaremanagment with the option to allow vendor change, searched for “cups” and marked all packages with more recent coming from repo Printing to be upgraded both on client and server side and Tadaa! It Works!

Pitty only, that these problems seem to bypass the mainstream packages.

So: Thanks a ton michael.lashkevich, for pointing me to the correct solution in your post #10](

Greez chris

PS: forgot to mention: after installing from Printing_15.3 repo, restart cups and cups-browsed on server and clients:

systemctl restart cups
systemctl restart cups-browsed