Cups can not see network printers

I have taken as a starting point and modified it to use an Ubuntu image running on an intel NUC.

But, try as I might, I can not get cups to detect any printers on my network. (Attaching the printer via usb is fine.)

If I ssh into the machine I can run avahi-browse and see the printer. But it is not shown in the web interface.

Also, running lpinfo -v from the command line does not show dnssd as a protocol for cups.

I have put a copy of the project on github at

Any help/hints would be appreciated.



Are you sure it doesn’t work? :smile: I suppose you would know… LOL It’s just that I tried pushing your repo (phillup/balena-cups-test) to an Intel NUC device, and it immediately listed my WiFi printer on the local network:

You actually did a good job! :+1: The only change I did was to replace all occurrences of your IP address in cups/cupsd.conf:

Your config: Allow from
My config: Allow from all

If if helps you, this I what got from lpinfo and avahi-browse using your repo’s container:

root@b1878c6:/# lpinfo -v
network ipp
network https
network socket
network beh
network http
network lpd
network ipp14
network ipps
network lpd://
root@b1878c6:/# avahi-browse -a
+   eno1 IPv6 EPSON XP-700 Series                           UNIX Printer         local
+   eno1 IPv4 EPSON XP-700 Series                           UNIX Printer         local
+   eno1 IPv6 EPSON XP-700 Series                           PDL Printer          local
+   eno1 IPv4 EPSON XP-700 Series                           PDL Printer          local
+   eno1 IPv6 EPSON XP-700 Series                           _scanner._tcp        local
+   eno1 IPv4 EPSON XP-700 Series                           _scanner._tcp        local
+   eno1 IPv6 EPSON XP-700 Series                           Internet Printer     local
+   eno1 IPv4 EPSON XP-700 Series                           Internet Printer     local
+   eno1 IPv6 EPSON XP-700 Series                           Microsoft Windows Network local
+   eno1 IPv4 EPSON XP-700 Series                           Microsoft Windows Network local
+ resin-dns IPv4 b1878c6                                       SSH Remote Terminal  local
+   eno1 IPv4 b1878c6                                       SSH Remote Terminal  local
+   eno1 IPv4 EPSON XP-700 Series                           Web Site             local
+   eno1 IPv6 EPSON XP-700 Series                           Web Site             local

That is very interesting, and thanks for trying it out!

I think tho that it is working for you because the printer does ipp which you can see in lpinfo is supported. (tho it is showing up as a lpd device… maybe shared from another cups instance?)

The printer I am trying to use is only accessible via dnssd. It is an old laserjet with a usb dongle plugged into an Airport Express.

On the working systems it shows up with a dnssd uri like shown in the Device URIs section of

Specifically, dnssd://Hewlett-Packard%20HP%20LaserJet%204MP._pdl-datastream._tcp.local./

This works if I do something like:

DOCKER_API_VERSION=1.22 DOCKER_HOST=tcp:// docker-compose up --build

mounting dbus as a volume. But, does not work with any other deployment method. (and that is the only change needed)

I have this working in a dockerized version of our application. (Where I can modify the host as needed) But we are trying to move it over to Balena for easier deployment.

I noticed in the debug output for cups when clicking on the add printer button that it iterats over each connection method and shows this when trying to do dnssd:

[CGI] Unable to create Avahi client

I think this is related to why I can’t see this particular printer.

Thanks for you help.


A bit more info.

I got cups fully working in a dockerized container about a year ago. So, parts of how I got it working are a bit fuzzy.

The problem I had back then was that cups saw the printer during the add printer phase. But could not find the printer when printing. (using balena I can not see it during the add printer phase)

I just ran avahi-browse -a -v -t -r in the balena container to get a picture of what it is seeing from the command line. And I noticed the ip address of the printer is self assigned.

That made me remember a bit about my solution from long ago.

On the host device I had to run avahi-autoipd -D --force-bind $wap where $wap was the device for my wireless access point. This allowed the containers avahi to see the local network that the host saw.

So, that may be the big fly in the ointment… this is a printer that is purely available via bonjour and has a self assigned ip address.



Hey Philip,

Just to make sure I understand, the same code from your repo lists your printer when you run it locally, but then fails on Balena? You were mentioning the “[CGI] Unable to create Avahi client” warning. If it works on your local machine, do you get the warning?

If I modify the compose file to map dbus

- /var/run/dbus:/var/run/dbus

then do

DOCKER_API_VERSION=1.22 DOCKER_HOST=tcp:// docker-compose up

where that ip address is a belena device in dev/local mode

then it builds and runs the container and I can see the network printer.

If I deploy using

balena push --no-cache

(without modifying the compose file… it won’t work with the bind mount) then I can NOT see the network printer.

Both instances are running on the same balena device.

I’ll check in a bit when I can about the debug statement.



Can you try the following?

Ok, I have confirmed that when running using

DOCKER_HOST=tcp:// docker-compose up --build

on a balena host in dev/local mode that the error in cups is not there, instead I get:

D [10/Jul/2019:18:26:46 +0000] [cups-deviced] Found device \"dnssd://Hewlett-Packard%20HP%20LaserJet%204MP._pdl-datastream._tcp.local/\"...

This is with the exact same docker compose file at with the following addition:

  - /var/run/dbus:/var/run/dbus

@jviotti - as you can see in the code from the repo, your suggested changes are already there.



p.s. To be clear about one thing: I am running the above command on my local machine.

The ip address in that command is an intel NUC running the balena OS.

This causes the code to be sent to the docker instance on the balena device where it is built and run.

So, in this case, the supervisor does not start the container and none of the balena magic happens. That is why I add the bind mount… to get access to dbus.

When I use the balena cli to push or deploy the image, it does not work. This leads me to think the problem originates in some way with dbus access inside the container under balena.

Hi @resinio30 , the only thing that stands out to me here is that with the compose up command you have the bind mount /var/run/dbus:/var/run/dbus, but in balenaOS the supervisor will do /run/dbus:/host/run/dbus . Perhaps if you have a symlink in your container from /host/run/dbus to /var/run/dbus things might work?

1 Like

Thanks so much @shaunmulligan … this got me over the hump.

Creating the symlink got me to the point where it would see the network printer.

Afterwards, it would create the printer but could not find it during the print process.

I needed to add a config for avahi-daemon that disabled dbus and start it up. (this was so it could find the printer when it needs to print)

Then, I also needed to create a route for local-link addresses. (this was so it could actually route the packets to the self assigned network address space)

The complete and working code can be found at

Thanks to all for your suggestions and help,