“No suitable Destination Host found by cups-browsed”

Question

I am running Ubuntu 18.04.2 Desktop on my laptop.

I have installed CUPS to a Raspberry Pi running Raspbian. My Mac will consistently print to this printer without any problems.

From Ubuntu Desktop I am only able to print to the printer ~1 minute after a reboot of Ubuntu Desktop. After that time documents will not print.

When I visit ‘localhost:631’ from Ubuntu Desktop the status is listed as ‘Idle - “No suitable Destination Host found by cups-browsed”’ (see attached).

Images can be seen here https://i.sstatic.net/GF2JC.jpg

Answer 1

You dont need to remove anything or add your printer manually. Just do this:

systemctl stop cups-browsed
systemctl start cups-browsed

or simplifying:

systemctl restart cups-browsed

I did the full start and stop, and it worked for me.

Answer 2

I was able to get my printer working. This seems to be some sort of bug in cups-browsed, which is a program that tries to automatically install every printer on the network. After removing cups-browsed I was able to manually add the printer, and was able to print without rebooting before hand.

First: uninstall cups-browsed

sudo apt-get purge --autoremove cups-browsed

Next: Restart your computer

Finally manually add your printer

1. In Ubuntu 18.04 go to settings -> devices -> printers.
2. Click on 'Additional Printer Settings'.
3. Click on Add
4. Under Network Printers select Find Network Printer. Enter the IP Address that your server running CUPS has. Once you follow the steps to install your printer you should be able to print consistently without rebooting.

Answer 3

I have a similar answer to @burnedfaceless that I came upon somewhat by accident. Since I was not comfortable removing a service that came with the system (Pop!_OS 20.04), I ran

systemctl stop cups-browsed

I then manually searched for and added the printer via Settings > Printers > Add...

At that point I was able to print normally, and only the one, manually-added, instance of my printer was visible. To test this further, I rebooted, expecting cups-browsed to restart itself (it did) and a second instance of the same printer to appear via the cups-browsed service (it did not, happily). So far so good. I am not sure why cups-browsed did not automatically add its own instance of the printer, but glad it did not.

One difference I have noted since doing this is that if I run:

lpstat -t
scheduler is running
system default destination: <short printer name>
device for <short printer name>: dnssd://<full url-encoded printer name>._ipp._tcp.local/?uuid=e...

If I recall correctly, the device URI was implicitclass://<printer name>, or something like that, when cups-browsed added it. Now it is dnssd://.... Perhaps this makes sense to someone who understands CUPS and/or systemd much better than I do.

Answer 4

Restart and even reinstall cups-browsed did not help me. Only solved this by assigning printer fixed IP address in the router settings and then added new printer manually with address ips://fixed-printer-ip-address/ips and selected proper driver.

Answer 5

I suffered for a long time with setting up the pantum BM5100ADW printer. The test page prints, print jobs go through but the printer does not print. Reloading or disabling cups-browsed did not resolve the issue. Only setting a fixed IP and connecting via AppSocket helped.

Answer 6

This happened to me, too. I'd previously been able to print easily with mDNS (aka Avahi aka Bonjour), but recently found I couldn't print from my laptop -- even though I could SSH to the CUPS print server and print a test page just fine, could see the CUPS IPP service on port 631 (which you can just browse to in a web browser), and could even see the mDNS record being correctly broadcast. I couldn't get cups-browsed to resolve the hostname, when I ran cups-browsed -v in terminal I saw it looking at the mDNS broadcast data but also reporting:

Printer ipps://<model_name> @ ._ipps._tcp.local/cups (.local, IP not determined)

Eventually I realized I'd reconfigured /etc/nsswitch.conf, essentially bringing this upon myself. I had updated the hosts: line to put [!UNAVAIL=return] before the mdns4_minimal entry, meaning that systemd-resolved would try /etc/hosts and normal DNS, but quit before turning to mDNS. I moved [!UNAVAIL=return] after mdns4_minimal, restarted networking with sudo systemctl status networking.service, and then was able to see it getting resolved by mDNS correctly.

You can't use standard DNS tools to validate this, but you can use avahi-browse --all or avahi-discover to see what's being broadcast via mDNS, and then you can use ping <hostname>.local to test whether <hostname> is resolvable via mDNS.

Answer 7

I had similar issues. Right after a fresh install I could print just fine, as well as after updating, but eventually after personalizing my install, network printing would break. USB printing was never a problem. Turns out the issue was my VPN (Mullvad). Once I realized this and changed the setting in Mullvad to allow local devices, all is well.

Answer 8

cups-browsed comes with the Ubuntu family and other distros because it makes nearby printers appear 'like magic' when you participate in a network. Some networked printers don't integrate with cups-browsed's methods quite so well, but there is an alternative to simply killing or removing this service, by configuring it to suit your situation. You can use BrowseFilter to tell the service you want to take manual control of certain printers, and still enjoy the automatic behaviour for others.

To remove a specific printer from automatic discovery and control

sudo vi /etc/cups/cups-browsed.conf

or use the editor of your choice, to insert the configuration entry

BrowseFilter NOT host MyPrinterName.local

then save the file. The configuration file gives you quite a few ideas for alternative BrowseFilter stanzas, which you can also read in the project source. Now restart the service with the new config and give it a few moments.

sudo systemctl restart cups-browsed

It is possible that the old auto-discovered printer may remain, if the BrowseFilter tells cups-browsed to ignore the device (which it had previously created) – you may simply delete that.

Now you can create the device manually, either using your OS Printers setup app or using 'cups web' on http://localhost:631/ choosing Administration / Add Printer where you will be presented with locally browsed printers to install - following the defaults often worked for me. I actually prefer to use the command line

# Create the new printer using IPP Everywhere protocol
lpadmin -p Name_Make_Model -E -v "ipp://MyPrinterName.local/ipp/print" -m everywhere
# Check the printer is there
lpstat -v

That should sort the problem on a given printer, but leave you free to enjoy automatic printer recognition for other devices and other networks. If you have not managed to get the BrowseFilter stanza quite right, you can diagnose by re-editing the cups-browsed.conf to set the DebugLogging file option in conf, restarting the service then

cat /var/log/cups-browsed/cups-browsed.log

I had a specific issue with a printer that would not wake from sleep for a few minutes when it was the implicitclass device autocreated by cups-browsed. Cups web shows the printer error Processing - "No suitable destination host found by cups-browsed, retrying later" and there would be several minutes delay before the printer would spring into action. However it worked fine, awaking immediately, when I created it manually as an ipp device using this technique.

Answer 9

The systemctl stop cups-browsed / systemctl start cups-browsed answer worked for me, but it became a nuisance doing that every time I restarted my laptop. So assuming stopping and starting worked because at system startup something wasn't ready I tried adding: ExecStartPre=-/bin/sleep 30 as the first line of the [Service] section of /lib/systemd/system/cups-browsed.service to delay start of cups-browsed by 30 seconds. Since doing this I haven't had any problems and the printer has always been available. I suspect that 30 seconds is over-kill, but It hasn't caused any problems so far.

Update: I have now reduced the delay to 5 seconds - works fine, printer has never been unavailable since making this change.