Ein Wiki privater Natur

cupsd

und Debian Trixie
Eigentlich ist das einrichten eines Brother DCP Druckers mittlerweile zur Routine geworden.
Aber nun war es nach einer Neuinstallation wieder soweit, es wollte einfach nicht klappen, Drucker wurde zwar erkannt, nur ließ er sich nicht zum drucken überreden.
Auch via cups http://localhost:631 gab es sogar merkwürdige "Server Errors" wenn ich auf die Verwaltung zugriff.
Ich erspare mir jetzt die ganzen Versuche, die ich benötigte, um die Ursache zu finden.

cupsd lässt sich nicht (re)starten

in den Logs:
journalctl -xe

audit: type=1400 audit(1729266691.849:438): apparmor="DENIED" operation="create" class="net" info="failed type and protocol match" error=-13 profile="/usr/sbin/cups-browsed" pid=1311 comm="cups-browsed" family="unix" sock_type="stream" protocol=0 requested="create" denied="create" addr=none

... und vor allem auch mit /usr/sbin/cupsd dasselbe Problem

Fix: ist einfach, wenn man apparmor installiert hat ...

apt install apparmor-utils
apparmor_status

cupsd ist im DENY Mode

aa-complain /usr/sbin/cupsd

Damit sind die nun nicht mehr denied! und Drucken klappt

Update (Debian Trixie): „Drucker kann nicht lokalisiert werden“ nach Brother-Firmware update

Symptom (typisch nach Firmware-Update):

Drucker wird gefunden, Queue ist da

manchmal klappt ein Testdruck direkt nach Reboot

danach in GNOME/CUPS:
„Der Drucker kann nicht lokalisiert werden.“

Jobs hängen auf „Ausstehend / nicht angeschlossen“

Ursache (wahrscheinlich):

Nicht primär AppArmor, sondern IPP/DNS-SD Auto-Erkennung (dnssd://, ipp://, ipps://) in Kombination mit cups-browsed.
Nach manchen Brother-Firmware-Updates ändern sich die IPP/DNS-SD Ankündigungen oder TLS/Capabilities – CUPS findet den Drucker kurz, verliert ihn dann wieder.

Lösung: Statische Queue statt Auto-Discovery

Die robuste Variante ist: Drucker mit fester IP als Netzwerkdrucker einrichten (keine dnssd:// URL).

Variante A (sehr robust): JetDirect / Port 9100

Gerät: AppSocket/HP JetDirect

URI:
socket://:9100

Beispiel:

sudo lpadmin -p Brother-L3760 -E -v socket://192.168.x.y:9100 -m everywhere
sudo lpoptions -d Brother-L3760
sudo systemctl restart cups
echo "TEST" | lp

Variante B: IPP direkt (ohne DNS-SD)

URI je nach Modell/Firmware oft:

ipp:///ipp/print

oder ipp:///ipp

Wenn IPP wieder zickt: zurück zu Variante A (9100), die ist am wenigsten empfindlich.

cups-browsed deaktivieren (optional, aber oft der Gamechanger)

Wenn cups-browsed dir immer wieder automatisch Queues „umzieht“ oder neu anlegt:

sudo systemctl stop cups-browsed
sudo systemctl disable cups-browsed

Oder komplett entfernen:

sudo apt purge cups-browsed

Einordnung zum alten AppArmor-Abschnitt

Die früheren DENIED-Meldungen sind real, aber nicht zwingend die eigentliche Ursache, wenn das Hauptsymptom „nicht lokalisierbar“ ist.
Wenn das Drucken mit statischer IP/9100 sauber läuft, ist AppArmor hier nicht mehr der Hebel.

Update (Debian Trixie): „Drucker kann nicht lokalisiert werden“ nach Brother-Firmware

Symptom (typisch nach Firmware-Update):

Drucker wird gefunden, Queue ist da

manchmal klappt ein Testdruck direkt nach Reboot

danach in GNOME/CUPS:
„Der Drucker kann nicht lokalisiert werden.“

Jobs hängen auf „Ausstehend / nicht angeschlossen“

Ursache (wahrscheinlich):
Nicht primär AppArmor, sondern IPP/DNS-SD Auto-Erkennung (dnssd://, ipp://, ipps://) in Kombination mit cups-browsed.
Nach manchen Brother-Firmware-Updates ändern sich die IPP/DNS-SD Ankündigungen oder TLS/Capabilities – CUPS findet den Drucker kurz, verliert ihn dann wieder.

Lösung: Statische Queue statt Auto-Discovery

Die robuste Variante ist: Drucker mit fester IP als Netzwerkdrucker einrichten (keine dnssd:// URL).

Variante A (sehr robust): JetDirect / Port 9100

Gerät: AppSocket/HP JetDirect

URI:
socket://:9100

Beispiel:

sudo lpadmin -p Brother-L3760 -E -v socket://192.168.x.y:9100 -m everywhere
sudo lpoptions -d Brother-L3760
sudo systemctl restart cups
echo "TEST" | lp

Variante B: IPP direkt (ohne DNS-SD)

URI je nach Modell/Firmware oft:

ipp:///ipp/print

oder ipp:///ipp

Wenn IPP wieder zickt: zurück zu Variante A (9100), die ist am wenigsten empfindlich.

cups-browsed deaktivieren (optional, aber oft der Gamechanger)

Wenn cups-browsed dir immer wieder automatisch Queues „umzieht“ oder neu anlegt:

sudo systemctl stop cups-browsed
sudo systemctl disable cups-browsed

Oder komplett entfernen:

sudo apt purge cups-browsed

Einordnung zum alten AppArmor-Abschnitt

Die früheren DENIED-Meldungen sind real, aber nicht zwingend die eigentliche Ursache, wenn das Hauptsymptom „nicht lokalisierbar“ ist.
Wenn das Drucken mit statischer IP/9100 sauber läuft, ist AppArmor hier nicht mehr der Hebel.

„Firmware-Updates sind sinnvoll – aber danach sollte man prüfen, ob IPP/DNS-SD weiterhin zuverlässig arbeitet. Bei Problemen empfiehlt sich eine statische Netzwerk-Queue.“