On Fedora, the printer app can't start if /etc/nsswitch is a symbolic link.

[ppywlkiqletw]

When using authselect on Fedora, the file /etc/nsswitch is a symbolic link to /etc/authselect/nsswitch.conf. When starting the printer app you get this status

× snap.ghostscript-printer-app.ghostscript-printer-app-server.service - Service for snap application ghostscript-printer-app.ghostscript-printer-app-server
     Loaded: loaded (/etc/systemd/system/snap.ghostscript-printer-app.ghostscript-printer-app-server.service; disabled; vendor preset: disabled)
    Drop-In: /etc/systemd/system/snap.ghostscript-printer-app.ghostscript-printer-app-server.service.d
             └─override.conf
     Active: failed (Result: exit-code) since Wed 2021-11-17 07:28:07 CET; 21s ago
    Process: 1368 ExecStart=/usr/bin/snap run ghostscript-printer-app.ghostscript-printer-app-server (code=exited, status=1/FAILURE)
   Main PID: 1368 (code=exited, status=1/FAILURE)
        CPU: 117ms

Nov 17 07:28:07 mybox systemd[1]: snap.ghostscript-printer-app.ghostscript-printer-app-server.service: Scheduled restart job, restart counter is at 5.
Nov 17 07:28:07 mybox systemd[1]: Stopped Service for snap application ghostscript-printer-app.ghostscript-printer-app-server.
Nov 17 07:28:07 mybox systemd[1]: snap.ghostscript-printer-app.ghostscript-printer-app-server.service: Start request repeated too quickly.
Nov 17 07:28:07 mybox systemd[1]: snap.ghostscript-printer-app.ghostscript-printer-app-server.service: Failed with result 'exit-code'.
Nov 17 07:28:07 mybox systemd[1]: Failed to start Service for snap application ghostscript-printer-app.ghostscript-printer-app-server.

After removing the symbolic link and copying the file /etc/authselect/nsswitch.conf to /etc/nsswitch.conf, the printer app can start normally.

-- Villy

[zdohnal]

Explanation regarding being /etc/nsswitch.conf a symlink - the file is controlled by authselect package, which is a tool to configure system identity and authentication sources and providers by selecting a specific profile (a set of files that describes how the resulting system configuration will look like). authselect is used by default since 2016-2017. To keep it simple with explanation, user is now expected to run authselect commands to get changes into /etc/authselect/nsswitch.conf (f.e. authselect select sssd which activates sssd profile) or make changes into /etc/authselect/user-nsswitch.conf and then call authselect apply-changes to get changes into /etc/authselect/nsswitch.conf.

I see snapcraft.yaml uses:

# Make resolution of ".local" host names (Zero-Conf/mDNS/DNS-SD)
# working: Mirror nsswitch.conf with added mDNS look-up support into
# /etc/nsswitch.conf
# See: https://forum.snapcraft.io/t/how-can-i-lookup-host-name-from-snap-core-using-avahi-mdns/
layout:
  /etc/nsswitch.conf:
    bind-file: $SNAP/etc/nsswitch.conf

which causes the problem on systems with authselect. snapd couldn't follow the link if the file is a symlink, could it? Otherwise snapcraft.yaml would have to be changed to reflect both destinations or have a authselect-OS specific snapcraft.yaml...

[ppywlkiqletw]

I see now that core20/1169/etc/nsswitch.conf now has the mdns4_minimal entry so the nsswitch.conf in the printer apps may no longer be necessary.

[tillkamppeter]

@zdohnal @ppywlkiqletw OK, thank you very much for all this info. So I will remove the nsswitch.conf awkwardness from all the Printer Applications at OpenPrinting as it is not needed any more.

[ppywlkiqletw]

If core20/1169/etc/nsswitch.conf is bind-mounted on /etc/nsswitch.conf, there might still be a problem? A test with the new printer app will show if that is the case.

[tillkamppeter]

I am rebuilding now without the layout entry in snapcraft.yaml check whether it works for me (regression test on system without nsswitch.conf symlink) and then upload all OpenPrinting Snaps to the Snap Store, with the awkwardness removed. If this then still not works for you, the problem is not only in the OpenPrinting Snaps but in every Snap using core20 and needing working nsswitch.conf, meaning that it has to be reported to the manitainers of core20 and/or snapd.

[tillkamppeter]

I have removed the nsswitch.conf workaround in the Ghostscript Printer Application now (commit 67a1962c) and the Snap Store is rebuilding it. As soon as you get the update, test and tell us whether it solves your problem.

[ppywlkiqletw]

The good news is that the printer application now starts properly.

However, for my usb printer it is unreliable. Sometimes it works and sometimes not. I don't know if the errors reported from /usr/libexec/snapd/snap-device-helper could have anything to do with it. Nor do I have any idea what that program is supposed to do.

-
Nov 18 13:07:08 mybox systemd-udevd[380]: usb2: Process '/usr/libexec/snapd/snap-device-helper add snap_ghostscript-printer-app_ghostscript-printer-app /devices/pci0000:00/0000:00:1d.0/usb2 189:128' failed with exit code 1.
Nov 18 13:07:08 mybox systemd-udevd[374]: usb5: Process '/usr/libexec/snapd/snap-device-helper add snap_ghostscript-printer-app_ghostscript-printer-app /devices/pci0000:00/0000:00:1d.3/usb5 189:512' failed with exit code 1.
Nov 18 13:07:08 mybox systemd-udevd[381]: usb4: Process '/usr/libexec/snapd/snap-device-helper add snap_ghostscript-printer-app_ghostscript-printer-app /devices/pci0000:00/0000:00:1d.2/usb4 189:384' failed with exit code 1.
Nov 18 13:07:08 mybox systemd-udevd[380]: usb2: Process '/usr/libexec/snapd/snap-device-helper add snap_ghostscript-printer-app_ghostscript-printer-app-server /devices/pci0000:00/0000:00:1d.0/usb2 189:128' failed with exit code 1.
Nov 18 13:07:08 mybox systemd-udevd[390]: usb1: Process '/usr/libexec/snapd/snap-device-helper add snap_ghostscript-printer-app_ghostscript-printer-app /devices/pci0000:00/0000:00:1d.7/usb1 189:0' failed with exit code 1.
Nov 18 13:07:08 mybox systemd-udevd[378]: usb3: Process '/usr/libexec/snapd/snap-device-helper add snap_ghostscript-printer-app_ghostscript-printer-app /devices/pci0000:00/0000:00:1d.1/usb3 189:256' failed with exit code 1.

[tillkamppeter]

I have tested the new version of the Printer Application Snap now with all 4 options to connect the device (USB, network via SNMP discovery, network via DNS-SD discovery, manually entered the ZeroConf hostname of the printer). All works. This is a regression test as it worked on my system already before, but now we have at least the improvement that the Snap installs and runs its daemon on systems where nsswitch,conf is a symlink.

Have you also tried to set up a network-connected printer using the Ghostscript Printer Application? Have you also tried to connect your Brother printer via network and whether it works this way with the Ghostscript Printer Application?

I simply want to know whether it is at least OK for network printers now. Independent of this it naturally also should work with USB printers.

Please check the following:

1. Run lsusb repeatedly, does the output always show your printer?
2. Run sudo /usr/lib/cups/backend/usb repeatedly, does it always show an entry for your printer (with the device ID)? Or run /snap/ghostscript-printer-app/current/usr/lib/ghostscript-printer-app/backend/usb instead, it is also the CUPS backend for USB.
3. Where did the error messages appear which you are showing in your last message here? In /var/log/syslog? Are there also any messages containing audit or DENIED which are related to USB and your printer?
4. Is there an ipp-usb process running on your system? If yes, your printer is most probably driverless (IPP printer emulated on localhost:60000) and should appear in CUPS without being set up with a Printer Application. The ipp-usb process is occupying the USB connection of the printer to do its work, you cannot do classic access with a Printer Application in parallel.
5. Could you run sudo lsusb -vvv > lsusb.txt and post the output here? This can give us more helpful information (like for example whether the printer has a 7/1/4 USB interface which would mean IPP-over-USB).
6. Please also check whether moving the printer or its cable influences whether your printer is accessible or not (cable/connector defect?).

[tillkamppeter]

Also what is the output of

snap connections | grep ghostscript-printer-app

Do you have any other Snaps which are supposed to communicate with USB devices? Do they work correctly for you?

[ppywlkiqletw]

I have tested the new version of the Printer Application Snap now with all 4 options to connect the device (USB, network via SNMP discovery, network via DNS-SD discovery, manually entered the ZeroConf hostname of the printer). All works. This is a regression test as it worked on my system already before, but now we have at least the improvement that the Snap installs and runs its daemon on systems where nsswitch,conf is a symlink.

Have you also tried to set up a network-connected printer using the Ghostscript Printer Application? Have you also tried to connect your Brother printer via network and whether it works this way with the Ghostscript Printer Application?

The printer is USB only.

https://support.brother.com/g/b/spec.aspx?c=us_ot&lang=en&prod=hl2130_all

I simply want to know whether it is at least OK for network printers now. Independent of this it naturally also should work with USB printers.

Please check the following:

1. Run `lsusb` repeatedly, does the output always show your printer?

2. Run `sudo /usr/lib/cups/backend/usb` repeatedly, does it always show an entry for your printer (with the device ID)? Or run `/snap/ghostscript-printer-app/current/usr/lib/ghostscript-printer-app/backend/usb` instead, it is also the CUPS backend for USB.

It never had any problems with current cups, thus sudo /usr/lib/cups/backend/usb as well a lpinfo -v ghostscript-printer-app devices mostly works.

The record layout it a bit different on Fedora compared to Ubunto.

[root@mybox current]# /var/lib/snapd/snap/ghostscript-printer-app/current/usr/lib/ghostscript-printer-app/backend/usb
DEBUG: Loading USB quirks from "/usr/share/cups/usb".
DEBUG: Loaded 98 quirks.
DEBUG: list_devices
DEBUG: libusb_get_device_list=7
DEBUG2: iSerialNumber="C4N971702"
DEBUG2: Printer found with device ID: MFG:Brother;CMD:PJL,HBP;MDL:HL-2130 series;CLS:PRINTER;CID:Brother Laser Type1; Device URI: usb://Brother/HL-2130%20series?serial=C4N971702
direct usb://Brother/HL-2130%20series?serial=C4N971702 "Brother HL-2130 series" "Brother HL-2130 series" "MFG:Brother;CMD:PJL,HBP;MDL:HL-2130 series;CLS:PRINTER;CID:Brother Laser Type1;" ""
[root@mybox current]# 

3. Where did the error messages appear which you are showing in your last message here? In `/var/log/syslog`? Are there also any messages containing `audit` or `DENIED` which are related to USB and your printer?

It is all journal on Fedora.

There used to be SELinux errors, but I run that in permissive mode so that doesn't affect any programs. The required permissions has now been installed, so no more SELinux errors.

I don't see any other errors.

4. Is there an `ipp-usb` process running on your system? If yes, your printer is most probably driverless (IPP printer emulated on `localhost:60000`) and should appear in CUPS without being set up with a Printer Application. The `ipp-usb` process is occupying the USB connection of the printer to do its work, you cannot do classic access with a Printer Application in parallel.

I am pretty sure that ipp-usb has not been running.

5. Could you run `sudo lsusb -vvv > lsusb.txt` and post the output here? This can give us more helpful information (like for example whether the printer has a 7/1/4 USB interface which would mean IPP-over-USB).

Bus 001 Device 005: ID 04f9:003f Brother Industries, Ltd HL-2130 series Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 0 bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 64 idVendor 0x04f9 Brother Industries, Ltd idProduct 0x003f bcdDevice 1.00 iManufacturer 1 Brother iProduct 2 HL-2130 series iSerial 3 C4N971702 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 0x0020 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xc0 Self Powered MaxPower 2mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 7 Printer bInterfaceSubClass 1 Printer bInterfaceProtocol 2 Bidirectional iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x01 EP 1 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 1 Device Qualifier (for other device speed): bLength 10 bDescriptorType 6 bcdUSB 2.00 bDeviceClass 0 bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 64 bNumConfigurations 1 Device Status: 0x0001 Self Powered

>     6. Please also check whether moving the printer or its cable influences whether your printer is accessible or not (cable/connector defect?).

It works perfectly with current cups and has done for many years.

However, it seems to depend on whether the printer has gone to sleep.  It seem that if  turn to printer off and then on so it starts making noise .  I then restart the Ghostscript printer app, and I can print.  Once the printer goes to sleep it doesn't work any more.  The old cups still works and can wake up the printer and print stuff.

A new issue.  The ghostscript printer app no longer wants to terminate when told to do so by systemd.  That used to work a few days ago.  Eventually, systemd send to big SIGKILL to force it to stop.

[tillkamppeter]

See also this discussion about the nsswitch.conf workaround.

[tillkamppeter]

For me

sudo snap stop ghostscript-printer-app

usually works but can sometimes have a delay of around 1 minute, probably if there is ome jobe hanging because the printer is disconnected or turned off.

To investigate why the printer falling into sleep mode makes it unaccessible for the Printer Application, I need more information (my HP does not have such a problem).

The Ghostscript Printer Application as it comes fromthe Snap Store uses the same backends as CUPS uses (but its own copies, so that the Printer Application does not need CUPS on the system), so usually a printer with works with CUPS should work with any of OpenPrinting's Printer Application (naturally the one containing the correct driver).

What can happen when a printer goes to sleep and wakes up again is that the USB device number changes (second nymber in lsusb output lines), but this should not affect the USB CUPS backend as the backend always walks through all USB devices (does the equivalent of lsusb -vvv and grabs the device IDs from the printers) and selects the device of which the model name and the serial number are in the device URI. The device URI you see in the state file of the Printer Application, /var/snap/ghostscript-printer-app/common/ghostscript-printer-app.state. Could you attach your state file (do not forget to attach a copy renamed with .txt file name extension added).

[ppywlkiqletw]

Also what is the output of

snap connections | grep ghostscript-printer-app

[root@mybox selinux]# snap connections | grep ghostscript-printer-app
avahi-control  ghostscript-printer-app:avahi-control  :avahi-control  -
home           ghostscript-printer-app:home           :home           -
network        ghostscript-printer-app:network        :network        -
network-bind   ghostscript-printer-app:network-bind   :network-bind   -
raw-usb        ghostscript-printer-app:raw-usb        :raw-usb        -
[root@mybox selinux]# snap list --all
Name                     Version   Rev    Tracking       Publisher      Notes
core20                   20211115  1242   latest/stable  canonical✓     base
ghostscript-printer-app  1.0       189    latest/edge    openprinting✓  -
snapd                    2.52.1    13640  latest/stable  canonical✓     snapd
[root@mybox selinux]# 

Do you have any other Snaps which are supposed to communicate with USB devices? Do they work correctly for you?

[ppywlkiqletw]

For me

sudo snap stop ghostscript-printer-app

usually works but can sometimes have a delay of around 1 minute, probably if there is ome jobe hanging because the printer is disconnected or turned off.

You might need to have someone else test this on a Fedora system.

To investigate why the printer falling into sleep mode makes it unaccessible for the Printer Application, I need more information (my HP does not have such a problem).

Actually the printer sleep mod is not an issue as I stated before. Important is, I now believe, that the printer has to be turned on before starting the printer app.

I managed to strace the backend in the act and I see following unexplainable permission error.

openat(AT_FDCWD, "/dev/bus/usb/001/004", O_RDWR|O_CLOEXEC) = -1 EPERM (Operation not permitted)
openat(AT_FDCWD, "/dev/bus/usb/001/004", O_RDWR|O_CLOEXEC) = -1 EPERM (Operation not permitted)
openat(AT_FDCWD, "/dev/bus/usb/001/004", O_RDWR|O_CLOEXEC) = -1 EPERM (Operation not permitted)
openat(AT_FDCWD, "/dev/bus/usb/001/004", O_RDWR|O_CLOEXEC) = -1 EPERM (Operation not permitted)
openat(AT_FDCWD, "/dev/bus/usb/001/004", O_RDWR|O_CLOEXEC) = -1 EPERM (Operation not permitted)
openat(AT_FDCWD, "/dev/bus/usb/001/004", O_RDWR|O_CLOEXEC) = -1 EPERM (Operation not permitted)
openat(AT_FDCWD, "/dev/bus/usb/001/004", O_RDWR|O_CLOEXEC) = -1 EPERM (Operation not permitted)

crw-rw-r--. 1 root lp system_u:object_r:usb_device_t:s0 189, 3 Nov 19 08:45 /dev/bus/usb/001/004

Bus 001 Device 004: ID 04f9:003f Brother Industries, Ltd HL-2130 series
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 002: ID 093a:2510 Pixart Imaging, Inc. Optical Mouse
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
~                                                               

[ppywlkiqletw]

ghostscript-printer-app.state

DNSSDName Ghostscript Printer Application
Contact
DefaultPrinterID 1
NextPrinterID 5
UUID urn:uuid:a43326c1-7f4b-31b8-6456-52277159a782
<Printer did="MFG:Brother;MDL:HL-2140 Foomatic/hl1250;CMD:PWG,URF,application/vnd.printer-specific,PDF,PS,JPEG,PNG;" driver="brother--hl-2140--hl-1250-en" id="1" name="testprinter" uri="cups:usb://Brother/HL-2130%20series?serial=C4N971702">
DNSSDName testprinter
Contact
MaxActiveJobs 0
MaxCompletedJobs 100
NextJobId 20
ImpressionsCompleted 0
identify-actions-default sound
media-col-default bottom="1270" left="635" length="29700" name="iso_a4_210x297mm" right="635" source="auto" top="1270" type="stationery" width="21000"
media-col-ready0 bottom="1270" left="635" length="29700" name="iso_a4_210x297mm" right="635" source="top" top="1270" type="stationery" width="21000"
media-col-ready1 bottom="1270" left="635" length="29700" name="iso_a4_210x297mm" right="635" source="bottom" top="1270" type="stationery" width="21000"
media-col-ready2 bottom="1270" left="635" length="29700" name="iso_a4_210x297mm" right="635" source="auto" top="1270" type="stationery" width="21000"
media-col-ready3 bottom="1270" left="635" length="29700" name="iso_a4_210x297mm" right="635" source="dual" top="1270" type="stationery" width="21000"
media-col-ready4 bottom="1270" left="635" length="29700" name="iso_a4_210x297mm" right="635" source="manual" top="1270" type="stationery" width="21000"
orientation-requested-default none
print-color-mode-default monochrome
print-content-optimize-default auto
print-quality-default normal
print-scaling-default auto
sides-default one-sided
printer-resolution-default 300x300dpi
economy-mode-default automatic-selection
resolution-default automatic-selection
Job completed="1637307920" created="1637307899" format="application/pdf" id="19" impressions="1" name="(stdin)" processing="1637307899" state="9" username="root"
Job completed="1637307182" created="1637306933" format="application/pdf" id="18" impressions="1" name="(stdin)" processing="1637306933" state="9" username="root"
Job completed="1637302268" created="1637302246" format="application/pdf" id="17" impressions="1" name="(stdin)" processing="1637302246" state="9" username="root"
Job completed="1637249918" created="1637248543" format="application/pdf" id="16" impressions="1" name="(stdin)" processing="1637248543" state="8" username="vek"
Job completed="1637244251" created="1637244249" format="application/pdf" id="15" impressions="1" name="(stdin)" processing="1637244249" state="9" username="vek"
Job created="1637241714" filename="/var/snap/ghostscript-printer-app/common/spool/p00001j000000014-_stdin_.pdf" format="application/pdf" id="14" impressions="1" name="(stdin)" processing="1637241714" state="5" username="root"
Job completed="1637240152" created="1637240150" format="application/pdf" id="13" impressions="1" name="(stdin)" processing="1637240150" state="9" username="root"
Job completed="1637240033" created="1637238184" format="application/pdf" id="12" impressions="1" name="(stdin)" processing="1637238184" state="7" username="root"
Job completed="1637237955" created="1637237834" format="application/pdf" id="11" impressions="1" name="(stdin)" processing="1637237834" state="7" username="root"
Job completed="1637237782" created="1637237749" format="application/pdf" id="10" impressions="1" name="(stdin)" processing="1637237749" state="9" username="root"
Job completed="1637051420" created="1637051394" format="application/pdf" id="9" impressions="1" name="(stdin)" processing="1637051394" state="9" username="root"
Job completed="1637051235" created="1637051235" format="application/octet-stream" id="8" name="printcap" processing="1637051235" state="8" username="root"
Job completed="1637005944" created="1637005941" format="application/pdf" id="7" impressions="1" name="Test Page" processing="1637005941" state="9" username="vek"
Job completed="1636992652" created="1636992650" format="application/pdf" id="6" impressions="1" name="Test Page" processing="1636992650" state="9" username="vek"
Job completed="1636990494" created="1636988733" format="application/pdf" id="5" impressions="1" name="Test Page" processing="1636988733" state="7" username="vek"
Job completed="1636987588" created="1636987586" format="application/pdf" id="4" impressions="1" name="MopriaTestPage.pdf" processing="1636987586" state="9" username="SM-A105FN"
Job created="1636984291" filename="/var/snap/ghostscript-printer-app/common/spool/p00001j000000003-test_page.pdf" format="application/pdf" id="3" impressions="1" name="Test Page" processing="1636984291" state="8" username="root"
Job completed="1636982263" created="1636982261" format="application/pdf" id="2" impressions="1" name="Test Page" processing="1636982261" state="9" username="guest"
Job completed="1636981470" created="1636981463" format="application/pdf" id="1" impressions="1" name="Test Page" processing="1636981463" state="9" username="guest"
</Printer>

[ppywlkiqletw]

For me

sudo snap stop ghostscript-printer-app

usually works but can sometimes have a delay of around 1 minute, probably if there is ome jobe hanging because the printer is disconnected or turned off.

I found in the service file:

TimeoutStopSec=30

This means the systemd will use the big SIGKILL after 30 seconds, way before the 60 second delay when it thinks there are jobs active.

[ppywlkiqletw]

Closing: The original issue is fixed, Thanks.

[tillkamppeter]

To find out about your USB problem I need some more information. Could you

1. Do tests with once starting the Printer Application and then turning on the printer and second first turning on the printer and after that starting the Printer Application? Do several tests. Does it work for one case and not for the other? If so, for which does it work, for which not? Make sure to remove all old jobs which did not print from the queue.
2. The "operation not permitted" errors happen exactly when? When starting the Printer Application? When printing a job? ...

[ppywlkiqletw]

To find out about your USB problem I need some more information. Could you

I think this issue has more to do with how snapd is working in Fedora than by the printer apps them selves. I have opened a ticket with the Fedora snapd: https://bugzilla.redhat.com/show_bug.cgi?id=2025264

I suggest we wait and see if that brings anything.

1. Do tests with once starting the Printer Application and then turning on the printer and second first turning on the printer and after that starting the Printer Application? Do several tests. Does it work for one case and not for the other? If so, for which does it work, for which not? Make sure to remove all old jobs which did not print from the queue.

When turning on the printer, the names /dev/bus/usb/001/004 /dev/usb/lp0 shows up and become available. They are then accessible by the snap application. If these names are created after the snap application has started, it seems that permission to use them is denied. That is all dark magic of the snap systems.

Also consider that Fedora is now cgroup2 only now, and that is not yet the case for Ubuntu. And Fedora has no apparmor, if that is important.

2. The "operation not permitted" errors happen exactly when? When starting the Printer Application? When printing a job? ...

The EPERM error is happening in the program backend/usb, and is repeated several time, and after that I am not sure.
Notice, the name /dev/bus/usb/001/004 did not exist when the printer app service was started. Also, backend/usb has been working for many years for plain CUPS without problem.

So, I think this is a Fedora problem which needs fixing elsewhere.

-- Villy

[ppywlkiqletw]

For the usb printer to work in all cases it just needs this little fix as described in the pull request.

https://github.com/systemd/systemd/pull/21576

The problem in snap-device-helper has been fixed, and it just needs an additional permission from systemd to actually work.