avahi-daemon adds/installs every printer on network

Bug #1753509 reported by cement_head
This bug affects 8 people
Affects Status Importance Assigned to Milestone
cups (Ubuntu)

Bug Description

When connected to a network, avahi-daemon adds & installs all printer on a network without being prompted. This is not desired behaviour. Discovery of the printers is good, but not automatic installation & addition.

ProblemType: Bug
DistroRelease: Ubuntu 16.04
Package: avahi-daemon 0.6.32~rc+dfsg-1ubuntu2
ProcVersionSignature: Ubuntu 4.13.0-36.40~16.04.1-generic 4.13.13
Uname: Linux 4.13.0-36-generic x86_64
ApportVersion: 2.20.1-0ubuntu2.15
Architecture: amd64
CurrentDesktop: Unity
Date: Mon Mar 5 09:29:05 2018
InstallationDate: Installed on 2017-09-29 (157 days ago)
InstallationMedia: Ubuntu 16.04.3 LTS "Xenial Xerus" - Release amd64 (20170801)
 PATH=(custom, no user)
SourcePackage: avahi
UpgradeStatus: No upgrade log present (probably fresh install)

Revision history for this message
cement_head (andorjkiss) wrote :
cement_head (andorjkiss)
summary: - avahi-daemon adds/installs every printer on netwrok
+ avahi-daemon adds/installs every printer on network
affects: avahi (Ubuntu) → cups (Ubuntu)
no longer affects: cups (Ubuntu)
Revision history for this message
Till Kamppeter (till-kamppeter) wrote :

This is not a bug of Avahi, Avahi is only handling the DNS-SD broadcasts. The queues are created by cups-browsed and which queues are exactly created can be configured in /etc/cups/cups-browsed.conf.

The dirctive to control this is "CreateIPPPrinterQueues". Set it to "LocalOnly" or "No".

Revision history for this message
Till Kamppeter (till-kamppeter) wrote :

Note that the default setting for "CreateIPPPrinterQueues" in Ubuntu is "Driverless".

Revision history for this message
klinge (rosgnilk) wrote :

I have the same problem. Setting "CreateIPPPrinterQueues" to "No" doesn't change anything.

I'm running Ubuntu 18.04.2 and under http://localhost:631/printers/ only the manually added printers show up. The gnome settings or avahi or something else keeps constantly adding all the printers in the network (and that is quite annoying.

Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in cups-filters (Ubuntu):
status: New → Confirmed
Revision history for this message
Till Kamppeter (till-kamppeter) wrote :

Could you please try the following:

In a terminal window run the command

sudo systemctl stop cups-browsed

This turns off cups-browsed completely.

Does the problem go away by this?

Changed in cups-filters (Ubuntu):
status: Confirmed → Incomplete
Revision history for this message
Ingo Haase (haase) wrote :

Hallo, same problem here. I set cups.conf to
Browsing Off
BrowseLocalProtocols none

that seems to solve the problem in Cups, but network printers still show up in the gnome printing dialogue. Well... sometimes. When I open the print dialogue from Firefox then there is no unwanted network printer. When I open the printing dialogue from LibreOffice, the unwanted printer is still there.
There also appears to be a significant time gap between changes in the conf files and the occurrence of the error.
You think you have solved the problem, but after 5 minutes the unwanted printer is back. Which makes the error even more annoying.

Revision history for this message
Launchpad Janitor (janitor) wrote :

[Expired for cups-filters (Ubuntu) because there has been no activity for 60 days.]

Changed in cups-filters (Ubuntu):
status: Incomplete → Expired
Revision history for this message
Manny Flores (nraygun) wrote :

Did everyone just give up? I'm still trying to solve this and I have a thread going on over at MX Linux.

Revision history for this message
Gustavo A. Díaz (gdiaz) wrote :

Same happening for me in 18.04. I just removed cups-browsed service. In localhost:631 those "unwanted" printers are gone, but in the rest of applications (like firefox, chrome, etc), still there.

So, no fix for this yet?


Revision history for this message
Jorge Sampaio (jrgsampaio) wrote :

I could get rid of the auto browsing/adding with the following:

firstly stop cups:

   sudo service cups stop

   sudo gedit /etc/cups/cups.conf
(or using any other editor) and comment...
   ## browselocalprotocols dnssd

save and close

   sudo gedit /etc/cups/cups-browsed.conf
and set
   GreateIPPPrintersQueues to No or LocalOnly
as described above
save and close

then stop avahi
   sudo service avahi-daemon stop
   sudo gedit /etc/avahi/avahi-daemon.conf

and insert or uncomment the following line:

save and close

now restart the services

sudo service cups start
sudo service avahi-daemon start

You may have to go on and delete all undesirable printers, one by one, three clicks for each (why they make this so hard? In the campus there are hundreds of printers!). You should not see the printers being re-added as before.

Final test: restart your system and see the list of printers in Settings.

Good luck
Jorge Sampaio

Revision history for this message
Phil Carns (pcarns) wrote :

Thank you for the step by step procedure jrgsampaio. I just followed it with the trivial modification to edit cupsd.conf instead of cups.conf.

Unfortunately, I can't test it until I next travel to a conference with discoverable printers on the network, so I have no idea if it worked yet.

I definitely wish this were easier. It would make sense to have an explicit "find printers" capability, followed by a checkbox list to confirm which ones you actually want to add. Having them automatically appear in your list (and stay there, long after you have disconnected from the network where those printers existed!) is not helpful at all, and in fact makes it too easy to send jobs to the wrong printer, which can be be a very serious problem if you have sensitive material in your printout.

Revision history for this message
Jiri Lebl (jiri-lebl) wrote :

This is one of the most stupid default behaviors I have encountered. Out of the several colleagues and family members who use linux (it is used quite a bit in a university environment), they are ALL (down to the last one) very annoyed at this behavior. The problem is that you have your laptop open, and "Becca" from your calculus class comes in to your office and opens her Macbook, and my laptop adds a printer. Then "Chad" (he's not even in your class) just opens their Macbook in the hallway, and you gain a new printer again. After a couple of months, it is a couple of hundred added printers, though they are all grayed out in the list when trying to print. Even though Chad will never visit the department again, his macbook is in my printer list forever. Just picking one of the actual working printers becomes difficult since it involves scrolling through a long list of gray printers to find the one nongray one in the middle. Deleting them is actually quite annoying to do through the GUI and it is not at all obvious.

I got rid of the browsing feature on my laptop. But not all of my linux-using colleagues are very technically savvy. They are using linux because that's what mathematicians often use, as it has all the software we need. But this is a "feature" that made using linux harder, not easier, for them. It doesn't actually discover the actual department printers at all, you still have to set those up manually.

And I actually think the browsing feature could be useful, but it can't permanently add random configuration just because it appeared on the network at some point. That is not a feature, that is a bug. Plus it is not "browsing" that would mean it is temporary, what it is doing is adding permanent configuration. So the naming is misleading at best. Browsing means that you are looking through the currently available printers. What it is doing is "Harvesting".

Revision history for this message
Wladimir Mutel (mwg) wrote :

This bug surely does not belong to "cups-filters" package. And probably it does not belong to Avahi. And to CUPS either. This bug does belong to GTK library and GTK apps which do not provide an option like "list only local CUPS printers, not everything Avahi has sniffed on the network".

Avahi is right in its actions, and there are other software relying on its "enable-dbus" option.
GTK as library is wrong in having this option enabled by default, and probably some of GTK apps have now learned to override this option properly (that is, in usable and understandable way for an end user).

Revision history for this message
Wladimir Mutel (mwg) wrote :
Revision history for this message
Mathias Weyland (launchpad-weyland) wrote :

lp:1477106 is another bug where this is being discussed (but didn't get much attention). I agree that this is due to somewhat broken behaviour of gtk3 and not cups-filter or avahi. In any case, an updated GTK 3 patch for Focal is available in the following for those who came here with this problem:


Revision history for this message
Till Kamppeter (till-kamppeter) wrote :

Mathias Weyland (launchpad-weyland), thanks for the link to the patched GTK, thispatch is generally a good idea as it is not a good idea of a print dialog talking directly to IPP printers, circumventing CUPS.

The problems are the following:

1. A typical desktop application sends the data to get printed in PDF format, but not all IPP printers understand PDF. The driverless IPP standards only require one of the four print data formats PDF, Apple Raster, PWG Raster, and PCLm. As PDF is a complex vector graphics format and the other 3 are simple raster formats, cheap printers usually do not understand PDF, so the dialog sending a job directly to the printer would not work here. When printing through a CUPS queue, CUPS detects which format the printer understands and converts if needed.

2. An essential functionality when printing from a desktop application is spooling, storing the print job on disk when receiving it, so the the dialog can close quickly and allow the user continuing to work in his application. Many, especially cheaper IPP printers do not have such capability, the dialog itself also does not spool AFAIK. Spooling is usually a task of CUPS (CUPS is a so-called print spooler). Therefoe printing should always go through CUPS.

Revision history for this message
ghomem (gustavo) wrote :

This is a problem when running a set of desktops with a traditional CUPS server that advertises its printers. The desktops should see only the server queues but by default they get duplicated (or even multiplicated entries) because the printers also advertise themselves.

The setting suggested by Till on cups-browsed.conf

CreateIPPPrinterQueues No

does not seem to have any effect. The undesired printers remain visible and listable with

lpstat -e

Applications like Libreoffice and oKular will show a list of redundant printers, which is, of course, confusing.

Revision history for this message
Till Kamppeter (till-kamppeter) wrote :

The problem you mention is a known CUPS problem and in the works:


affects: cups-filters (Ubuntu) → cups (Ubuntu)
Changed in cups (Ubuntu):
status: Expired → Triaged
importance: Undecided → High
Revision history for this message
Walt DeMoss (waltdemoss) wrote (last edit ):

I have had the same problem since 20.04. Now on 22.04. for me it is solved by using deny-interfaces in the avahi-daemon.conf file. I just eliminate the interfaces that are adding the printers I don't need. Here I have denied my wifi usb dongle and my ZeroTier network connection.

Revision history for this message
Aleksandar Pavić (acosonic) wrote :

I can confirm here that I have sucessfully installed only 2 local printers on cups, and I can see only them in cups admin.

But on Gnome's settings printers, there are all printers on my network.

I am in a corporate lan with like 30 printers in my print dialogue...

So gnome is getting data from avahi instead of cups... I guess this setting should be configurable, maybe someone doesn't want printers from avahi...

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

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