Hi! If your scanner shares / shows up on Linux but the printer doesn’t, and you suspect an Avahi conflict, you’re describing a very specific class of issues: mDNS/DNS-SD discovery is partially working (enough for scanning) but the print service advertisement or consumption is broken or “shadowed.”

On Linux, scanners and printers often show up through different service types even when they’re the same MFP (multi-function printer). For example:
• Scanning may appear via eSCL/AirScan (often seen with sane-airscan) or WSD/WS-Scan.
• Printing usually relies on IPP/IPPS discovery via DNS-SD (Bonjour/mDNS) that Avahi handles, and then CUPS (sometimes with help from cups-browsed) decides whether to create a queue or present a temporary one.

The confusing part (and why people search “Linux scanner works printer doesn’t”, “cups-browsed not creating printers”, “Avahi mDNS conflict”) is that your desktop UI may show a scanner in Simple Scan, but the printer list stays empty — even though the network is fine.

I can narrow this down fast, but I need a few details because there are multiple “Avahi conflict” patterns (and we don’t want you toggling random services). Quick questions:
1) Is this a network printer (Wi-Fi/Ethernet) or USB connected to the Linux box (or to a router/NAS)?
2) Distro + desktop: Ubuntu/Fedora/Arch/Mint? GNOME/KDE? (Discovery behaves differently.)
3) Does the printer appear on other devices (Windows/macOS/iPhone)? And does Linux see it if you add it by IP/IPP manually?
4) Are you using ipp-usb/ippusbxd or any “driverless over USB” stack? That can create duplicate DNS-SD services that confuse CUPS, while scanning still looks fine.

While we diagnose, here are related fixes we often end up applying (not doing them yet — just mapping the territory): CUPS service discovery, Avahi DBus/daemon state, cups-browsed filtering, .local resolution (nss-mdns), and firewall rules for UDP 5353 / multicast.

That’s exactly the right instinct: we should avoid “turn off avahi” as a first move, because it can fix one symptom and quietly break discovery elsewhere (especially driverless scanning). Instead, we verify which part of DNS-SD is failing and which component is “winning” the announcements.

In Ubuntu, printing can involve a few layers at once:
• avahi-daemon handles mDNS/DNS-SD on the network.
• CUPS uses IPP/IPPS services to present printers.
• cups-browsed (if installed/enabled) can create local queues for discovered printers — helpful in some setups, confusing in others, especially when multiple service records exist.
• For MFPs, scanning might be visible through sane-airscan (AirScan/eSCL) even if printing isn’t visible via IPP.

Let’s do a safe “what does the network actually advertise?” check — without changing anything. The goal is to confirm whether your printer is broadcasting:
• an IPP print service (what CUPS needs), and/or
• only a scanner service (which explains your symptom).

Two things commonly cause the “scanner shows, printer doesn’t” split on Ubuntu:
1) The printer is advertising IPP, but your Linux box can’t consume it due to .local name resolution or firewall/multicast restrictions (still letting some scanner discovery through).
2) The printer is advertising multiple or conflicting DNS-SD services (for example, a vendor stack + a driverless stack), and CUPS ends up ignoring the one that would actually work.

Before we go deeper, one quick reality check: does your printer appear in your router’s device list (has an IP), and can you open its web interface in a browser? If yes, the problem is almost certainly service discovery and queue creation, not the printer itself.

Also: if you’ve ever run into odd behavior like “options missing in PPD/driver,” this other guide can be related after discovery is fixed: Stapling / hole-punch options missing — add finisher in driver/PPD.

Great — that isolates it: the device is reachable and functional; Ubuntu just isn’t building a print path automatically. And yes: systemd-resolved vs Avahi comes up a lot because people assume “mDNS is mDNS,” but CUPS’s discovery expectations can be picky depending on how name resolution and DNS-SD libraries are wired on the distro.

Here’s the key idea (in plain English):
Scanning discovery can succeed even when printing discovery fails because the protocols differ and the desktop apps handle them differently. Simple Scan may find an eSCL/AirScan endpoint (sometimes even by direct IP), while CUPS is looking for an IPP service record it trusts enough to present in print dialogs or to create a queue (especially if cups-browsed is filtering).

Common long-tail symptoms you might recognize:
• “Ubuntu scanner detected but printer not found”
• “CUPS no printers found on network”
• “cups-browsed not creating queue” / “No suitable destination host”
• “Avahi conflict ipp-usb duplicates” (especially if the device is sometimes USB-connected elsewhere)

We’ll keep this safe: the first phase is evidence collection (no changes). The second phase is targeted correction (minimal changes, and we preserve scanning).

If you want to do this the quick way (and avoid 20 different forum guesses), jump into chat and paste three outputs: what Ubuntu sees for print services, what it sees for scan services, and what CUPS thinks about destinations. That combination tells me within minutes whether it’s (a) missing DNS-SD records, (b) .local resolution, (c) cups-browsed filters, or (d) duplicate/competing advertisements.

Related (often requested once printing works again): Type 3 vs Type 4 print drivers — which one to pick in Windows 11 (useful if you’re also managing a Windows print path in the same environment).

Totally fair. Here’s a non-scary explanation of the Avahi conflict angle without throwing a wall of commands at you.

Avahi’s job is basically: “announce services and listen for services.” A multifunction printer may announce several services at once (print + scan + web UI). Conflicts happen when:
• Two different components announce the *same* printer differently.
Example patterns: a vendor driver stack announces one DNS-SD record while a driverless stack announces another; CUPS picks the “wrong” one or ignores both.

• The printer advertises services, but the client can’t resolve or reach the service target.
It might see “there is a printer” but fail on the next step because the service points to a .local hostname the client can’t resolve correctly, or multicast traffic is blocked. That can still leave scanning working (because scanning may be configured by IP or discovered differently).

• cups-browsed changes what you see.
cups-browsed can “materialize” discovered remote printers into local queues. If it’s filtering, timing out, or encountering ambiguous records, you get “nothing shows up” even though Avahi is actually seeing something.

About ipp-usb / ippusbxd: these are common in “driverless over USB” setups and can create printer services on the machine they run on. In mixed environments (e.g., device used by different hosts), you can end up with duplicate advertisements, which looks like “scanner is fine, printer is missing/ghosting.” We can check if it’s even present without touching anything — and we won’t disable it blindly.

If you do want a guided path, we can keep it minimal and safe in chat. I’ll ask for one quick confirmation per step and stop as soon as we identify the conflict source (Avahi vs cups-browsed vs name resolution vs firewall).

(If you’re also dealing with “printer won’t wake / disappears,” this can be related after discovery is restored: Wireless printer not waking up for AirPrint job — sleep policy tweak.)

Yes — that’s a real-world pattern. Printer discovery uses multicast DNS (mDNS) and DNS-SD announcements (commonly over UDP 5353), while scanning can still work if your scanner app is using an already-known IP endpoint or a different discovery method that slips through your current rules.

Here’s how it can look in practice (common long-tail searches):
• “Ubuntu ufw blocks mdns” → printer never appears, but the device is reachable by IP.
• “scanner works printer not discovered” → because the scanner frontend caches the device, while printers rely on dynamic discovery lists.

The tricky part is: opening “everything” is not a good idea. You want the minimum network permissions so Avahi can do its job and CUPS can reach IPP, without exposing extra services.

If you message me in the live chat with: your Ubuntu version, whether you use UFW, and whether the printer is Wi-Fi or Ethernet, I’ll tell you exactly which discovery path is failing (mDNS visibility vs IPP reachability vs queue creation) and what the safest minimal fix is — without risking your scanner setup.

(If you’re printing PDFs and seeing odd “scrambled preview” issues later, unrelated but common: Print preview scrambled — clear garbled PDF output.)

You’re thinking about it correctly: “driverless” for scanning and “driverless” for printing are related but not identical.

Driverless scanning on Linux is often handled by sane-airscan (AirScan/eSCL) or WSD backends — your scanner showing up strongly suggests you already have a working discovery + protocol path for scanning.

Driverless printing usually means the printer supports IPP Everywhere (or AirPrint/Mopria) and CUPS can talk to it over IPP without a vendor driver/PPD. In many homes, that works out-of-the-box. But when it doesn’t, it’s usually not “missing driver,” it’s one of these:
• the printer’s DNS-SD print service isn’t visible to the Linux host,
• the service is visible but points to a target name the client can’t resolve (.local / NSS / resolver path),
• cups-browsed is present and filtering / timing out / creating queues inconsistently,
• duplicate service records exist (the “Avahi conflict” scenario).

So yes, you might end up adding a queue manually if discovery is broken — but I don’t recommend doing that as a “first fix,” because it can mask the underlying mDNS conflict and you can end up with disappearing printers, duplicated queues, or weird “works once then vanishes” behavior.

If you want maximum conversion-proof results, the best move is: identify which layer is failing (Avahi visibility, name resolution, cups-browsed queue creation, or CUPS policy). That’s exactly the part we handle fastest in the live chat.

Absolutely — here’s the one-message checklist that lets me pinpoint a Linux scanner shares but printer doesn’t / Avahi conflict case quickly (and safely). You can paste this into chat:

1) Environment
• Ubuntu version (e.g., 22.04/24.04) + desktop (GNOME/KDE)
• Printer/MFP brand + model
• Connection: Wi-Fi / Ethernet / USB / via router/NAS

2) What works vs doesn’t
• Scanner app used (Simple Scan, XSane, etc.) and whether it’s sane-airscan/eSCL or something else
• Printing from Windows/macOS works? (yes/no)
• Can you open printer web UI by IP? (yes/no)

3) Discovery symptoms
• Do you ever see “temporary” printer entries appear and vanish?
• Is cups-browsed installed/enabled? (if you’re unsure, just say “not sure”)
• Do you run UFW or another firewall? (yes/no)

With that, I can tell you which bucket you’re in (DNS-SD not visible, .local resolution mismatch, cups-browsed conflict, or duplicate service ads) and then walk you through the minimal fix that preserves scanning. If needed, we can also sanity-check CUPS configuration issues that cause hidden behavior (like policy blocks) — similar in spirit to this: Driver signature error — bypass securely (different OS, same idea: do the safe minimum, not random “turn it off” changes).

Perfect — and we’ll protect scanning. In these cases, the “bad fix” is changing Avahi globally; the “good fix” is identifying the exact conflict (DNS-SD service records, queue creation behavior, or name resolution) and adjusting only what’s necessary.

If you paste the checklist into live chat, I’ll respond with a targeted plan that keeps sane-airscan (or your scanner backend) working while we restore driverless IPP printing visibility in CUPS.