Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 644636 - net-print/cups and USB printer. Permissions in /dev/bus/usb do not allow to print
Summary: net-print/cups and USB printer. Permissions in /dev/bus/usb do not allow to p...
Status: CONFIRMED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal with 1 vote (vote)
Assignee: Printing Team
URL: https://wiki.gentoo.org/wiki/Printing...
Whiteboard:
Keywords: Bug
Depends on:
Blocks:
 
Reported: 2018-01-15 09:06 UTC by Xavier Fernández i Marín
Modified: 2019-05-06 11:03 UTC (History)
6 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
udev rules (udev.tar,90.00 KB, application/x-tar)
2018-04-19 14:49 UTC, Xavier Fernández i Marín
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Xavier Fernández i Marín 2018-01-15 09:06:56 UTC
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
Comment 1 Techwolf 2018-02-05 23:51:49 UTC
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
Comment 2 Techwolf 2018-02-06 00:23:27 UTC
Can an admin edit my comment and remove or edit the sercial #? I did not realized what I did until now. Whoops.
Comment 3 Richard Yao gentoo-dev 2018-04-16 18:32:32 UTC
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.
Comment 4 Richard Yao gentoo-dev 2018-04-16 18:44:52 UTC
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.
Comment 5 Richard Yao gentoo-dev 2018-04-16 20:38:32 UTC
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.
Comment 6 Mike Gilbert gentoo-dev 2018-04-16 20:51:32 UTC
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.
Comment 7 Richard Yao gentoo-dev 2018-04-16 20:56:53 UTC
(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. :/
Comment 8 Xavier Fernández i Marín 2018-04-17 11:38:24 UTC
(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?)
Comment 9 Richard Yao gentoo-dev 2018-04-17 15:38:32 UTC
(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.
Comment 10 Mike Gilbert gentoo-dev 2018-04-17 16:30:47 UTC
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.
Comment 11 Richard Yao gentoo-dev 2018-04-17 16:32:26 UTC
(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.
Comment 12 Xavier Fernández i Marín 2018-04-17 17:49:46 UTC
(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?
Comment 13 Richard Yao gentoo-dev 2018-04-19 14:19:23 UTC
(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.
Comment 14 Xavier Fernández i Marín 2018-04-19 14:49:18 UTC
Created attachment 528044 [details]
udev rules
Comment 15 Xavier Fernández i Marín 2018-04-19 14:50:38 UTC
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.
Comment 16 Tomasz Golinski 2018-06-25 16:20:03 UTC
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.
Comment 17 Ulrich Kawald 2018-07-05 07:43:01 UTC
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"
Comment 18 Amel Hodzic 2018-09-24 04:31:59 UTC
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.
Comment 19 Israel G. Lugo 2018-11-05 21:03:36 UTC
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.
Comment 20 Israel G. Lugo 2018-11-05 21:16:49 UTC
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"
Comment 21 Israel G. Lugo 2018-11-05 21:19:33 UTC
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?