After a @world upgrade the printer attached to a USB device has stopped to work. The error message in /var/log/cups/error.log shows: libusb_get_device_list=16 Failed to open device, code: -3 I have tried the different combinations of cups and cups-filters stable and unstable with no differences. It turns out that Mageia has a bug reported for the same issue: https://bugs.mageia.org/show_bug.cgi?id=10475 suggesting to use CUPS with acl, but I have also acl enabled as use flag and does not work. The solution in my case is to manually change the permissions: # chmod a+rw /dev/bus/usb/001/003 And then the printer works again. May it be udev related? # emerge --info Portage 2.3.13 (python 3.5.4-final-0, default/linux/amd64/17.0/desktop, gcc-6.4.0, glibc-2.25-r9, 4.14.11-gentoo-xfim x86_64) ================================================================= System uname: Linux-4.14.11-gentoo-xfim-x86_64-Intel-R-_Core-TM-_i5-4200U_CPU_@_1.60GHz-with-gentoo-2.4.1 KiB Mem: 8058576 total, 6426040 free KiB Swap: 2047996 total, 2047996 free Timestamp of repository gentoo: Mon, 15 Jan 2018 08:15:01 +0000 Head commit of repository gentoo: f6c020d92b3358675e3aec13e4164e48561ec4a3 sh bash 4.4_p12 ld GNU ld (Gentoo 2.29.1 p3) 2.29.1 app-shells/bash: 4.4_p12::gentoo dev-java/java-config: 2.2.0-r3::gentoo dev-lang/perl: 5.26.9999::gentoo dev-lang/python: 2.7.14-r1::gentoo, 3.5.4-r1::gentoo dev-util/cmake: 3.9.6::gentoo dev-util/pkgconfig: 0.29.2::gentoo sys-apps/baselayout: 2.4.1-r2::gentoo sys-apps/openrc: 0.34.11::gentoo sys-apps/sandbox: 2.10-r4::gentoo sys-devel/autoconf: 2.13::gentoo, 2.69-r4::gentoo sys-devel/automake: 1.11.6-r2::gentoo, 1.15.1-r1::gentoo sys-devel/binutils: 2.29.1-r1::gentoo sys-devel/gcc: 6.4.0::gentoo sys-devel/gcc-config: 1.8-r1::gentoo sys-devel/libtool: 2.4.6-r3::gentoo sys-devel/make: 4.2.1::gentoo sys-kernel/linux-headers: 4.14::gentoo (virtual/os-headers) sys-libs/glibc: 2.25-r9::gentoo Repositories: gentoo location: /usr/portage sync-type: rsync sync-uri: rsync://rsync.de.gentoo.org/gentoo-portage/ priority: -1000 sync-rsync-extra-opts: ACCEPT_KEYWORDS="amd64" ACCEPT_LICENSE="* -@EULA" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=native -O2 -pipe -fomit-frame-pointer" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/gnupg/qualified.txt" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/dconf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/php/apache2-php7.1/ext-active/ /etc/php/cgi-php7.1/ext-active/ /etc/php/cli-php7.1/ext-active/ /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo /etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c" CXXFLAGS="-march=native -O2 -pipe -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" EMERGE_DEFAULT_OPTS="--quiet-build=y" FCFLAGS="-O2 -pipe" FEATURES="assume-digests binpkg-logs config-protect-if-modified distlocks ebuild-locks fixlafiles merge-sync multilib-strict news parallel-fetch preserve-libs protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync xattr" FFLAGS="-O2 -pipe" GENTOO_MIRRORS="http://ftp.uni-erlangen.de/pub/mirrors/gentoo" LANG="ca_AD.utf8" LDFLAGS="-Wl,-O1 -Wl,--as-needed" LINGUAS="ca en es_ES en_GB de" MAKEOPTS="-j5" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --omit-dir-times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --exclude=/.git" PORTAGE_TMPDIR="/var/tmp" USE="R X a52 aac acl acpi aes aes-ni alsa amd64 avx avx2 berkdb blas branding bzip2 cairo cdda cdr cleartype cli consolekit corefonts crypt cups custom-optimization cxx dbus diff djvu dri dts dvd dvdr emboss encode exif fam firefox flac fma3 fontconfig fortran gdbm gif glamor gpm gtk iconv infinality int64 javafx jpeg jpeg2k lapack laptop latex lcms ldap libinput libnotify linguas_ca linguas_en lm_sensors loop-aes mad mmx mmxext mng modules mp3 mp4 mpeg multilib ncurses nls nptl ntlm ogg opengl openmp pam pango pcre pdf png policykit popcnt ppds qt3support qt5 readline sdl seccomp sna spell sse sse2 sse3 sse4 sse4_1 sse4_2 ssl ssse3 startup-notification svg t1lib tcpd tiff tools truetype type3 udev udisks unicode upower usb vaapi vim vim-pager vim-syntax vorbis wxwidgets x264 xattr xcb xml xv xvid zlib" ABI_X86="64" ALSA_CARDS="hda-intel" APACHE2_MODULES="authn_core authz_core socache_shmcb unixd actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CALLIGRA_FEATURES="kexi words flow plan sheets stage tables krita karbon braindump author" CAMERAS="canon ptp2" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" CPU_FLAGS_X86="aes avx avx2 fma3 mmx mmxext popcnt sse sse2 sse3 sse4_1 sse4_2 ssse3" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock isync itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf skytraq superstar2 timing tsip tripmate tnt ublox ubx" INPUT_DEVICES="libinput" KERNEL="linux" L10N="ca en-GB en-US es-ES de" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php5-6 php7-0" POSTGRES_TARGETS="postgres9_5" PYTHON_SINGLE_TARGET="python3_5" PYTHON_TARGETS="python2_7 python3_5" RUBY_TARGETS="ruby22" SANE_BACKENDS="hp hp3500 hp3900 hp4200 hp5400 hp5590 hpljm1005" USERLAND="GNU" VIDEO_CARDS="intel" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account" Unset: CC, CPPFLAGS, CTARGET, CXX, INSTALL_MASK, LC_ALL, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
I got bit with this bug. Quick search show a few permissions bugs for cups. In my case, it was the combo of two bugs hitting me at the same time. The first one was fixed by downgrading a binary only driver from canon that stop the segfaulting. Took me hours and furpulling trying to figure out why I could not print and why I could not add a usb printer to cups. Then found this bug. chmod a+rw /dev/bus/usb/004/006 fixed it for me. Before: # ls -la /dev/bus/usb/004/006 crw-rw----+ 1 root usb 189, 389 Feb 5 18:28 /dev/bus/usb/004/006 # lpinfo -v file cups-brf:/ network http network beh network lpd network https network ipp network socket network ipps network smb After: # ls -la /dev/bus/usb/004/006 crw-rw-rw-+ 1 root usb 189, 389 Feb 5 18:28 /dev/bus/usb/004/006 # lpinfo -v file cups-brf:/ network http network beh network lpd network https network ipp network socket network ipps direct usb://Canon/MF3010?serial=1118Q000607C&interface=1 network smb
Can an admin edit my comment and remove or edit the sercial #? I did not realized what I did until now. Whoops.
This bit me too. What is worse is that if the printer was not already setup or you deleted it as part of a troubleshooting step, CUPS will not see it at all. I have added an entry to the wiki's troubleshooting section describing a better way of fixing the permissions than running `chmod a+rw ...`. The chmod method will cause anyone to be able to print, rather than just members of the lp group. In my case, I am using a Samsung printer with a currently out of tree binary driver and installed the Android SDK. It turns out that if the android-sdk is installed when using a Samsung printer, udev rules are installed in `/lib64/udev/rules.d/80-android.rules` that will change the group ownership of Samsung printers' character devices to the android group. Those udev rules modify the permissions of any device whose vendor ID matches 4 different vendor IDs. It is not clear to me if Samsung's printers share the same vendor IDs as Samsung phones or if this is a case of overzealous udev rules. I have not checked and likely would be unable to confirm it either way. In any case, this caused printing to fail with the statement that the printer is busy on my system and caused attempts to recreate the printer to fail with it not appearing at all. Running `/usr/libexec/cups/backend/usb` as root showed no problem, because the program was running as root rather than as a regular user in the lp group. One option to deal with this is to add udev rules for printers that override rules placed for the android sdk or other things. We have a list of hardware ids for printers in sys-apps/hwids that we could use to generate that list, although it would be much easier if udev/eudev just had its own rule that targetted anything with the USB class code printer: http://www.usb.org/developers/defined_class Unfortunately, I do not see a way to do that. I am putting the udev and eudev teams on CC. I have also filed bug #653324 to request better error reporting.
It occurs to me that we probably could use a helper program to detect such things. Even a helper script that parses the output of lsusb (e.g. for example `lsusb -v -d 04e8:3297`) would work. We might want `udevadm info /dev/bus/usb/002/060` tell us the USB device class to make writing rules easier for everyone, but I suspect that the eudev/udev teams will tell us to go that route. I would like to hear their thoughts on this though. Also, I am not on the printing team. I am just providing my unsolicited opinion because this affected me. The decision is their call, not mine.
Here is a generic udev rule that could go into /etc/udev/rules.d/0-usb-printer.rules without worry of being overridden by later rules: SUBSYSTEMS=="usb", PROGRAM=="/bin/sh -c 'if /usr/bin/test -e /sys/$devpath/*/bInterfaceClass; then cat /sys/$devpath/*/bInterfaceClass; fi'", RESULT=="07" MODE:="0660", GROUP:="lp" It is ugly, but it works. The := is used instead of = to prevent anything from changing the mode and group values.
USB printers are covered by this existing rule in 50-udev-default.rules. SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", ENV{ID_USB_INTERFACES}=="*:0701??:*", GROUP="lp" This rule might be adjusted or copied to override the android rule. Though I suspect the android rule is broken here.
(In reply to Mike Gilbert from comment #6) > USB printers are covered by this existing rule in 50-udev-default.rules. > > SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", > ENV{ID_USB_INTERFACES}=="*:0701??:*", GROUP="lp" > > This rule might be adjusted or copied to override the android rule. Though I > suspect the android rule is broken here. Changing the rule to this should work: SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", ENV{ID_USB_INTERFACES}=="*:0701??:*", MODE:="0660",GROUP:="lp" I agree about the Android rule likely being broken, although I doubt that the Android rules are the only source of this issue. I read somewhere that I cannot find at the moment that someone with a brother printer appeared to be affected too. There could be other things setting these permissions incorrectly. :/
(In reply to Richard Yao from comment #7) > (In reply to Mike Gilbert from comment #6) > > USB printers are covered by this existing rule in 50-udev-default.rules. > > > > SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", > > ENV{ID_USB_INTERFACES}=="*:0701??:*", GROUP="lp" > > > > This rule might be adjusted or copied to override the android rule. Though I > > suspect the android rule is broken here. > > Changing the rule to this should work: > > SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", > ENV{ID_USB_INTERFACES}=="*:0701??:*", MODE:="0660",GROUP:="lp" > > I agree about the Android rule likely being broken, although I doubt that > the Android rules are the only source of this issue. I read somewhere that I > cannot find at the moment that someone with a brother printer appeared to be > affected too. There could be other things setting these permissions > incorrectly. :/ I can confirm that this new rule works for me, although instead of changing the default /lib64/udev/rules.d/50-udev-default.rules I have opted for adding a new file with this rule in /etc/udev/rules.d/50-usb_printer.rules (How should we proceed: shall someone close the bug or we wait until it is solved by udev?)
(In reply to Xavier Fernández i Marín from comment #8) > I can confirm that this new rule works for me, although instead of changing > the default /lib64/udev/rules.d/50-udev-default.rules I have opted for > adding a new file with this rule in /etc/udev/rules.d/50-usb_printer.rules > > (How should we proceed: shall someone close the bug or we wait until it is > solved by udev?) This bug probably should have been given to the udev/eudev guys, but given that there are two of them, it is not clear to whom it should be assigned. Anyway, lets keep it open until we hear from them. By the way, what does `lsusb` print for your printer? It would be nice if we could find out what is causing the permissions to be set incorrectly on your system, but I do not know a simple generic procedure for finding that out. In lieu of that, the line of output from `lsusb` for your printer would be useful to know.
udev rules must be written conservatively enough to not interfere with each other. If rules are clobbering each others settings, the rules that overreach should be fixed. I don't think think there is anything wrong with the 50-udev-default.rules here. The problem is with whatever rules file is overriding. If that's the android sdk package, this bug should be re-assigned to them. I don't know if Xavier has confirmed which package is installing a conflicting udev rule on his system.
(In reply to Mike Gilbert from comment #10) > udev rules must be written conservatively enough to not interfere with each > other. If rules are clobbering each others settings, the rules that > overreach should be fixed. > > I don't think think there is anything wrong with the 50-udev-default.rules > here. The problem is with whatever rules file is overriding. If that's the > android sdk package, this bug should be re-assigned to them. > > I don't know if Xavier has confirmed which package is installing a > conflicting udev rule on his system. He has not. That is why I asked him for his lsusb output so that I can check.
(In reply to Richard Yao from comment #11) > (In reply to Mike Gilbert from comment #10) > > udev rules must be written conservatively enough to not interfere with each > > other. If rules are clobbering each others settings, the rules that > > overreach should be fixed. > > > > I don't think think there is anything wrong with the 50-udev-default.rules > > here. The problem is with whatever rules file is overriding. If that's the > > android sdk package, this bug should be re-assigned to them. > > > > I don't know if Xavier has confirmed which package is installing a > > conflicting udev rule on his system. > > He has not. That is why I asked him for his lsusb output so that I can check. This is my lsusb: Bus 001 Device 006: ID 06bc:0269 Oki Data Corp. Interestingly enough, when I opened the bug my old laptop was running an sdk installation. But I recently switched machines and the new one was also having the problem even if it is a fresh installation with no sdk stuff. Does this help?
(In reply to Xavier Fernández i Marín from comment #12) > This is my lsusb: > Bus 001 Device 006: ID 06bc:0269 Oki Data Corp. > > Interestingly enough, when I opened the bug my old laptop was running an sdk > installation. But I recently switched machines and the new one was also > having the problem even if it is a fresh installation with no sdk stuff. > Does this help? That confirms my conjecture that the Android SDK did not cause your problem. Unfortunately, it does not tell us what did. Would you tarball the following directories and attach it to this bug: /etc/udev/rules.d /run/udev/rules.d /usr/lib/udev/rules.d We should be able to work out what did affect your printer's permissions with that.
Created attachment 528044 [details] udev rules
Here it goes the attachment. I honestly don't know how this works, but may I remind you of the bug in Mageia that I pointed out in my first message? May it be related to that? Is it the same case? https://bugs.mageia.org/show_bug.cgi?id=10475 Thank you in any case.
I got hit by the same issue. Here is my setting: cups-2.2.7 eudev-3.2.5 no special printer drivers Bus 001 Device 003: ID 04e8:3276 Samsung Electronics Co., Ltd ML-3050/ML-3051 Laser Printer ls -l /dev/bus/usb/001/003 crw-rw---- 1 root usb 189, 2 Jun 25 18:07 /dev/bus/usb/001/003 /run/udev/rules.d/ 61-dev-root-link.rules contents: ACTION=="add|change", SUBSYSTEM=="block", ENV{MAJOR}=="8", ENV{MINOR}=="1", SYMLINK+="root" /etc/udev/rules.d/ 80-net-name-slot.rules (empty) /usr/lib/udev/rules.d empty Changing group to "lp" solved the issue for me.
Same problem here, this time with a Brother MFC: Bus 001 Device 004: ID 04f9:02d0 Brother Industries, Ltd DCP-1510 cups-2.2.8-r1 eudev-3.2.5 ls -l /dev/bus/usb/001/004 crw-rw---- 1 root usb 189, 3 Jul 5 08:02 /dev/bus/usb/001/004 Changing the group to lp worked for me, too. I don't really know how this is supposed to work, but it looks like the group that is set by the generic rule for usb-devices in /lib/udev/rules.d/40-gentoo.rules: # Gentoo specific usb group SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", GROUP="usb" is not replaced by the printer-rule in /lib/udev/rules.d/70-printers.rules: # Low-level USB device add trigger ACTION=="add", SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", ENV{ID_USB_INTERFACES}=="*:0701??:*", TAG+="systemd", ENV{SYSTEMD_WANTS}="configure-printer@usb-$env{BUSNUM}-$env{DEVNUM}.service"
The dev-util/android-sdk-update-manager package could be updated to include a udev rules file that's more granular in approach. One example of that would be to add a list of idProduct as well as idVendor tags, as shown at https://github.com/M0Rf30/android-udev-rules/blob/master/51-android.rules This bug has plagued me for months, almost a year now, with a Samsung printer and cups.
I am also affected. Unable to print, cupsd page indicated processing since... "Waiting for printer to become available." # lsusb | fgrep Samsung Bus 002 Device 007: ID 04e8:3252 Samsung Electronics Co., Ltd # ls -la /dev/bus/usb/002/007 crw-rw---- 1 root usb 189, 134 Nov 5 20:47 /dev/bus/usb/002/007 I did the following: # chgrp lp /dev/bus/usb/002/007 # ls -la /dev/bus/usb/002/007 crw-rw---- 1 root lp 189, 134 Nov 5 20:56 /dev/bus/usb/002/007 Printer now works perfectly. /var/log/cups/error_log shows multiple lines of: D [05/Nov/2018:20:56:10 +0000] [Job 476] Printing on printer with URI: usb://Samsung/ML-2250 D [05/Nov/2018:20:56:10 +0000] [Job 476] libusb_get_device_list=8 D [05/Nov/2018:20:56:10 +0000] [Job 476] Failed to open device, code: -3 D [05/Nov/2018:20:56:10 +0000] [Job 476] Waiting for printer to become available. D [05/Nov/2018:20:56:10 +0000] [Job 476] libusb_get_device_list=8 D [05/Nov/2018:20:56:10 +0000] [Job 476] Failed to open device, code: -3 D [05/Nov/2018:20:56:10 +0000] [Job 476] Waiting for printer to become available. D [05/Nov/2018:20:56:10 +0000] [Job 476] libusb_get_device_list=8 D [05/Nov/2018:20:56:10 +0000] [Job 476] Failed to open device, code: -3 I do not have the Android SDK installed. I've had it in the past, by directly downloading from Google, but not the package. I've checked and I don't have the /lib64/udev/rules.d/80-android.rules file.
This /may/ be related to VirtualBox. Or libmtp. Or one of the other files listed below: udevadm test /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.1 2>&1 | fgrep .rules: RUN '/lib/udev/VBoxCreateUSBNode.sh $major $minor $attr{bDeviceClass}' /lib64/udev/rules.d/10-virtualbox.rules:5 GROUP 85 /lib64/udev/rules.d/40-gentoo.rules:7 IMPORT builtin 'usb_id' /lib64/udev/rules.d/50-udev-default.rules:13 IMPORT builtin 'hwdb' /lib64/udev/rules.d/50-udev-default.rules:13 MODE 0664 /lib64/udev/rules.d/50-udev-default.rules:43 GROUP 7 /lib64/udev/rules.d/50-udev-default.rules:55 PROGRAM 'mtp-probe /sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.1 2 9' /lib64/udev/rules.d/69-libmtp.rules:2465 Note the RUN action above. The relevant lines on these files are: 005:/lib64/udev/rules.d/10-virtualbox.rules SUBSYSTEM=="usb", ACTION!="remove", ENV{DEVTYPE}=="usb_device", RUN="/lib/udev/VBoxCreateUSBNode.sh $major $minor $attr{bDeviceClass}" 007:/lib64/udev/rules.d/40-gentoo.rules SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", GROUP="usb" 013:/lib64/udev/rules.d/50-udev-default.rules SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", IMPORT{builtin}="usb_id", IMPORT{builtin}="hwdb --subsystem=usb" 013:/lib64/udev/rules.d/50-udev-default.rules SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", IMPORT{builtin}="usb_id", IMPORT{builtin}="hwdb --subsystem=usb" 043:/lib64/udev/rules.d/50-udev-default.rules SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", MODE="0664" 055:/lib64/udev/rules.d/50-udev-default.rules SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", ENV{ID_USB_INTERFACES}=="*:0701??:*", GROUP="lp" 2465:/lib64/udev/rules.d/69-libmtp.rules ENV{ID_MTP_DEVICE}!="1", ENV{MTP_NO_PROBE}!="1", ENV{COLOR_MEASUREMENT_DEVICE}!="1", ENV{libsane_matched}!="yes", ATTR{bDeviceClass}=="00|02|06|ef|ff", PROGRAM="mtp-probe /sys$env{DEVPATH} $attr{busnum} $attr{devnum}", RESULT=="1", SYMLINK+="libmtp-%k", ENV{ID_MTP_DEVICE}="1", ENV{ID_MEDIA_PLAYER}="1", GROUP="plugdev", MODE="0660"
I also just noticed that /lib/udev/rules.d/70-printers.rules is: # Low-level USB device add trigger ACTION=="add", SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", ENV{ID_USB_INTERFACES}=="*:0701??:*", TAG+="systemd", ENV{SYSTEMD_WANTS}="configure-printer@usb-$env{BUSNUM}-$env{DEVNUM}.service" # Low-level USB device remove trigger ACTION=="remove", SUBSYSTEM=="usb", ENV{ID_USB_INTERFACES}=="*:0701*:*", RUN+="udev-configure-printer remove %p" I do not have systemd installed (OpenRC). Furthermore, I have the "systemd" USE flag disabled globally. Is this file broken for non-systemd users, or is this working as intended?
I ran into the same issue with my USB printer using eudev: The udev rules assign the group 'usb' to the printer's device file, although it should get the group 'lp' (and, in consequence, printing does not work using CUPS). From what I see on my system, the issue is caused by the 'bind' events that were introduced in the Linux kernel with version 4.14, and here's why: When plugging my USB printer in, the kernel generates two events: First, an "add" event, and directly after that a "bind" event (seen with 'udevadm monitor'). For the "add" event, the rules from 50-udev-default.rules kick in and assign group 'lp' to the printer's device file (see https://github.com/gentoo/eudev/blob/fa0ea89c147584ae3c5c5acf13273f75ce182753/rules/50-udev-default.rules#L57). However, for the following 'bind' event the rules from 50-udev-default.rules do *not* kick in, as those rules are skipped for all actions except 'add' (see https://github.com/gentoo/eudev/blob/fa0ea89c147584ae3c5c5acf13273f75ce182753/rules/50-udev-default.rules#L16). In consequence, the rules from the file 40-gentoo.rules kick in and assign group 'usb' to the printer's device file (see https://github.com/gentoo/gentoo/blob/3d16edacf664782db004255b67464808c257f722/sys-fs/eudev/files/40-gentoo.rules#L7). Similar issues were already discussed and, as far as I understood, fixed for systemd (see, e.g., https://lwn.net/Articles/837033/ and https://github.com/systemd/systemd/issues/8221). From what I read on the corresponding issue in systemd, a fix for that particular issue would be to change the 'ACTION!="add", GOTO="default_end"' to 'ACTION!="add|bind", GOTO="default_end"' (in https://github.com/gentoo/eudev/blob/fa0ea89c147584ae3c5c5acf13273f75ce182753/rules/50-udev-default.rules#L16). For me, this change fixed the issue with my printer. Any opinions?
*** Bug 696898 has been marked as a duplicate of this bug. ***
In my case the devices were owned by "scanner" group (due to the printer being also scanner+printer). Adding users to scanner group allowed them to print
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=15b01aed0650b4f7621558ca101573caae398297 commit 15b01aed0650b4f7621558ca101573caae398297 Author: Pacho Ramos <pacho@gentoo.org> AuthorDate: 2022-01-22 11:19:47 +0000 Commit: Pacho Ramos <pacho@gentoo.org> CommitDate: 2022-01-22 11:20:07 +0000 media-gfx/sane-backends: Avoid scanner group usage scanner group usage ends up breaking cups printing due to changing permissions and owners of devices in an uncontrolled way (#644636) Follow CUPS upstream suggestion to generate udev rules as other distributions (Fedora or Arch, for example) to avoid this issue. https://github.com/OpenPrinting/cups/issues/314 https://gitlab.com/sane-project/backends/-/issues/546 https://wiki.gentoo.org/wiki/Printing#USB_Printer_is_not_detected Bug: https://bugs.gentoo.org/644636 Package-Manager: Portage-3.0.30, Repoman-3.0.3 Signed-off-by: Pacho Ramos <pacho@gentoo.org> media-gfx/sane-backends/files/66-saned.rules | 2 + .../sane-backends/sane-backends-1.1.1-r1.ebuild | 363 +++++++++++++++++++++ 2 files changed, 365 insertions(+)
Someone raised https://forums.gentoo.org/viewtopic-p-8693358.html#8693358 on the forums too which may be related.