Estimated reading time: 3 minutes

If you've been following me for a while, you know that I have a weakness for efficiency applied to everyday life. Some time ago I already talked to you about Boomaga, that amazing open source software that serves as “virtual printer” and allows you to do spectacular things, how to merge multiple documents into a single stream, rearrange pages e, above all, manage the front/back (duplex) intelligently even when native software is acting up.

I recently decided to put it to the test again on my trusty one Linux only, installing it this time via Flatpak. Everything seemed perfect: I launch a couple of prints to consolidate them, Boomaga opens regularly, it shows me the previews flawlessly, I select my network printer (una HP Smart Tank 7000) and set up the duplex system. I click on “Print” and… nothingness. Absolute silence.

Going to peek into the control panel of CUPS (the Linux print server), I found myself facing a dead end that was as frustrating as it was common: “The printer cannot be located”.

What had happened? And how is it resolved? I'll explain everything to you.

The origin of the problem: Sandbox and Network Ghosts

When you come across this error, the fault is almost always one “double bottleneck” which involves Flatpak security and how Linux handles network printers.

1. Flatpak isolation

Flatpak packages are great because they run inside one “sandbox” (an environment isolated from the rest of the system). The downside is that, if not properly trained, they cannot communicate with the outside. In my case, Boomaga did not have permission to access the local network or speak directly to the host system's CUPS print server.

If you often find yourself struggling with isolated application permissions, I remind you that in the past I wrote a detailed guide on how to manage Flatpak permissions graphically with Flatseal (a life-saving tool for these scenarios).

2. The trap of the protocol dnssd://

Going to check the printer configuration on CUPS (at the address http://localhost:631), I noticed that the default connection was registered with a string like this: dnssd://HP%20Smart%20Tank%207000...local/

This means that the system tries to search for the printer using the mDNS/Bonjour protocol (addresses that end in .local). If your Linux distribution does not have the name resolution daemon active (or if Flatpak blocks it), the printer suddenly becomes a ghost. It becomes invisible even to native applications like Evince!

The Solution: Break down barriers and get to the point

To definitively resolve and restart double-sided printing on Boomaga, There are two steps to follow.

Step 1: Open the Flatpak cages

We have to explicitly tell Flatpak that Boomaga has permission to use the network and the printing system. We can do it comfortably from the terminal with a single command override:

flatpak override --user --socket=cups --share=network io.github.Boomaga

Note: if you use Flatseal, you can activate the voices “Network” and “CUPS print system” directly from its graphical interface.

Step 2: Taming CUPS with the AppSocket (Direct IP)

To eliminate address uncertainty at its root .local, the best strategy is to assign the printer a static IP and reconfigure it in CUPS via the protocol AppSocket / HP JetDirect.

1. Retrieve your printer's IP address (for example from the display of the same or by making a ping of its network name). Let's assume it is 192.168.1.50.
2. Open your browser to http://localhost:631, go to the tab Printers and select your HP printer.
3. In the drop-down menu Administration, click on Modify Printer.
4. Under the voice Other Network Printers, select AppSocket/HP JetDirect and press Continue.
5. In the field Connection, enter the direct IP address using this precise syntax: socket://192.168.1.50
6. Continue by confirming the drivers already present and save the changes.

The verdict

Bypassing protocol network ballets dnssd and giving Flatpak the access keys to CUPS, the gear is turning again. Now I can send any document to Boomaga, manage the preview, decide on the layout and launch printing: the HP ST7000 receives the signal in one millisecond, printing in perfect front/back without getting lost in the web.

And have you ever had similar problems with Linux printers and Flatpak packages? Let me know in the comments!