Re: CUPS “server-error-internal-error” failure when trying to connect to a network printer on Linux Mint 20.3
This actually applies to Ubuntu 20.04 focal too, but I’m posting here just because, well, I’m using Mint.
Got that rather unhelpful error message when trying to set up my Lexmark network printer – which installs just fine on Linux Mint 18.3.
This was a subtle one. Lots of online refs to that cryptic error message – some going all the way back to 2004 (!). Also many solutions which all come down to using the “AppSocket/HP Jet Direct” connection where you specify explicitly the printer’s IP address and port 9100. This connection method does work.
But the other options (Driverless IPP and DNS-SD) always fail with that cryptic error message.
Inspecting more detailed messages in /var/log/cups/error_log gives clues about not being able to get the ppd file from the printer itself.
Further investigations suggest the Avahi-daemon is not configured correctly to support dns-sd name resolution (e.g. when network names that have .local in the URL are used to poll the printer).
Apparently the real problem (and a solution) can be found here:
https://wiki.archlinux.org/title/avahi#systemd-resolved_prevents_nss-mdns_from_working
where it states:
nss-mdns only works if the DNS server listed in /etc/resolv.conf returns NXDOMAIN to SOA queries for the “local” domain.[1] Even if systemd-resolved is configured with MulticastDNS=no in resolved.conf(5), it will not return NXDOMAIN for these queries. See systemd issue 21659.
A solution is to use the full mdns NSS module instead of mdns_minimal and create /etc/mdns.allow to allow only the “local” domain. For example:
/etc/nsswitch.conf
hosts: mymachines mdns [NOTFOUND=return] resolve [!UNAVAIL=return] files myhostname dns
/etc/mdns.allow
.local.
.local
After editing /etc/nsswitch.conf to replace the existing “mdns4_minimal” with simply “mdns” and then creating a new /etc/mdns.allow file containing only the two lines above, the printer can now be added using all three connection options.
Note that after changing these files, each time I ran
sudo service network-manager restart
to make sure the changed files were re-read.
Renaming mdns.allow to something different restores the broken behavior, pretty much proving to me that systemd issue 21659 is the root cause of this problem.
In Ubuntu 20.04 it is identified as bug 1950850; see here for a good explanation if you care about details: