| Summary: | net-print/cups and USB printer. Permissions in /dev/bus/usb do not allow to print | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Xavier Fernández i Marín <xavier.fim> |
| Component: | Current packages | Assignee: | Printing Team <printing> |
| Status: | CONFIRMED --- | ||
| Severity: | normal | CC: | eudev, gentoo, israel.lugo, pacho, sam, scott, Sergiy.Borodych, solstiss, tomaszg, udev-bugs |
| Priority: | Normal | Keywords: | Bug |
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| URL: | https://wiki.gentoo.org/wiki/Printing#USB_Printer_is_not_detected | ||
| See Also: | https://github.com/OpenPrinting/cups/issues/314 | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: | udev rules | ||
|
Description
Xavier Fernández i Marín
2018-01-15 09:06:56 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 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. |
