emerging libusb-0.1.12 causes the famous "can't scan as non-root" permissions problem. Reversion to libusb-0.1.11 fixes the problem.
Same problem here, not only for scanning, I can't access my digital camera either! This is what I get with libusb-0.1.12 (as root): hardcore ~ # sane-find-scanner found USB scanner (vendor=0x06b9 [ALCATEL], product=0x4061 [Speed Touch USB ]) at libusb:002:003 # Your USB scanner was (probably) detected. It may or may not be supported by # SANE. Try scanimage -L and read the backend's manpage. hardcore ~ # scanimage -L device `plustek:libusb:002:004' is a Canon N670U/N676U/LiDE20 USB flatbed scanner when I try to access my usb-scanner as a normal user: tekknokaetzi@hardcore ~ $ sane-find-scanner found USB scanner (vendor=0x04a9, product=0x220d, chip=LM983x?) at libusb:002:004 found USB scanner (vendor=0x06b9, product=0x4061) at libusb:002:003 # Your USB scanner was (probably) detected. It may or may not be supported by # SANE. Try scanimage -L and read the backend's manpage. tekknokaetzi@hardcore ~ $ scanimage -L No scanners were identified. If you were expecting something different, check that the scanner is plugged in, turned on and detected by the sane-find-scanner tool (if appropriate). Please read the documentation which came with this software (README, FAQ, manpages). Same problem for my digital camera: it's recognised but I can't access it. after reverting back to libusb-0.1.11 I can access my scanner and my digital camera as a normal user: tekknokaetzi@hardcore ~ $ sane-find-scanner found USB scanner (vendor=0x04a9 [Canon], product=0x220d [CanoScan], chip=LM9832/3) at libusb:002:005 # Your USB scanner was (probably) detected. It may or may not be supported by # SANE. Try scanimage -L and read the backend's manpage. tekknokaetzi@hardcore ~ $ scanimage -L device `plustek:libusb:002:005' is a Canon N670U/N676U/LiDE20 USB flatbed scanner emerge --info: Portage 2.1_pre9-r5 (default-linux/x86/2005.0, gcc-4.0.3, glibc-2.3.6-r3, 2.6.16-beyond-git12 i686) ================================================================= System uname: 2.6.16-beyond-git12 i686 Intel(R) Pentium(R) 4 CPU 1400MHz Gentoo Base System version 1.12.0_pre18 ccache version 2.4 [enabled] dev-lang/python: 2.4.2-r1 dev-util/ccache: 2.4-r1 dev-util/confcache: [Not Present] sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.59-r7 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2 sys-devel/binutils: 2.16.1-r2 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.11-r5 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-march=pentium4 -mtune=pentium4 -msse -msse2 -pipe -O2 -fomit-frame-pointer -momit-leaf-frame-pointer -fno-ident -fforce-addr -falign-functions=4" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/kde/3/share/config /usr/share/X11/xkb /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/eselect/compiler /etc/gconf /etc/revdep-rebuild /etc/terminfo /etc/env.d" CXXFLAGS="-march=pentium4 -mtune=pentium4 -msse -msse2 -pipe -O2 -fomit-frame-pointer -momit-leaf-frame-pointer -fno-ident -fforce-addr -falign-functions=4 -fvisibility-inlines-hidden" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig ccache distlocks metadata-transfer sandbox sfperms strict" GENTOO_MIRRORS="ftp://sunsite.informatik.rwth-aachen.de/pub/Linux/gentoo ftp://linux.rz.ruhr-uni-bochum.de/gentoo-mirror http://mirrors.sec.informatik.tu-darmstadt.de/gentoo/ ftp://ftp-stud.fht-esslingen.de/pub/Mirrors/gentoo/ ftp://gentoo.inode.at/source/ http://gentoo.oregonstate.edu http://www.ibiblio.org/pub/Linux/distributions/gentoo" LANG="de_DE@euro" LC_ALL="de_DE@euro" LDFLAGS="-Wl,-O1 -Wl,--enable-new-dtags -Wl,--sort-common -s -Wl,--as-needed" LINGUAS="de" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage /usr/local/overlays/gentoo-de" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="x86 X acpi alsa arts atm avi bitmap-fonts cdr cli crypt cups divx4linux dlloader dri dvd encode ffmpeg foomaticdb gdbm gif gphoto2 gpm gtk gtk2 imlib ipv6 isdnlog joystick jpeg kde libg++ libwww mad mmx motif mp3 mpeg ncurses nls nptl nptlonly nsplugin nvidia ogg oggvorbis opengl oss pam pcre pdf pdflib perl pic png pppd python qt quicktime readline real reflection scanner sdl session spell spl sse sse2 ssl svga tcpd tiff truetype truetype-fonts type1-fonts usb vorbis win32codecs wmf xml2 xmms xorg xv zlib elibc_glibc input_devices_keyboard input_devices_mouse kernel_linux linguas_de userland_GNU video_cards_nv video_cards_nvidia video_cards_fbdev video_cards_vesa" Unset: ASFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK
I did some debugging. It seems that the line ret = ioctl(dev->fd, IOCTL_USB_SETCONFIG, &configuration); in usb_set_configuration in linux.c returns a different error as non-root for libusb-0.1.12 and libusb-0.1.11. libusb-0.1.12 returns E_PERM.
OK, I found out why this is happening, but the answer is not pleasant. It turns out that libusb-0.1.11 is looking for usb devices at /proc/bus/usb while libusb-0.1.12 is looking at /dev/bus/usb. All the documentation and hotplug scripts call for changing permissions at /proc/bus/usb. One solution is to change all the documentation and hotplug scripts to change permissions at /dev/bus/usb instead. I don't know the extent or consequences ot this change. Comments?
OK, here's how I fixed this problem. I added the file 10-scanner.rules to /etc/udev/rules.d consisting of the line: BUS="usb", SYSFS{idVendor}="04b8", SYSFS{idProduct}="0818", PROGRAM="/bin/sh -c 'K=%k; K=$${K#usbdev}; printf bus/usb/%%03i/%%03i $${K%%%%.*} $${K#*.}'", NAME="%c", MODE="0660", GROUP="scanner"
Can confirm this bug with gphoto. Changing perms on /dev/bus/usb/appropriate/file allows non-root access again. Don't have a pretty, general solution.
http://libusb.cvs.sourceforge.net/libusb/libusb/linux.c?r1=1.77&r2=1.78 this is the change that did it. which documentation says to change the permissions on /proc/bus/usb? on my machine both permissions are the same, no root write access, am I missing something?
(In reply to comment #6) > http://libusb.cvs.sourceforge.net/libusb/libusb/linux.c?r1=1.77&r2=1.78 > > this is the change that did it. which documentation says to change the > permissions on /proc/bus/usb? on my machine both permissions are the same, no > root write access, am I missing something? > The code changes that you reference seem to be related to determining whether usb is found or not, either /proc/bus/usb or /dev/bus/usb. The change that seems to cause the problem is code determining the permissions of the usb devices, which have changed from /proc/bus/usb to /dev/bus/usb. The permissions are now checked on /dev/bus/usb. On your machine, are you looking at /proc/bus/usb, /dev/bus/usb, or both? The workaround here, and in the forums, is to write a special udev rule to create the /dev/bus/usb devices with the proper permissions for the new usb device. This is unsatisfactory as it is not general and depends on writing special udev rules for each specific usb device.
I agree that the udev rules is not a good solution. I'll see if I can get upstream to look at this.
i got the same problem, downgrading to libsusb-0.1.11 works fine for me, on 0.1.12 i couldn' acces even my camera had to do udev rule but this is not ok
vapier, you might not want to mark libusb-0.1.12 stable for sh, s390 and arm because of this bug.
isnt udev broken ? shouldnt this line: SUBSYSTEM=="usb_device", PROGRAM="/bin/sh -c 'K=%k; K=$${K#usbdev}; printf bus/usb/%%03i/%%03i $${K%%%%.*} $${K#*.}'", NAME="%c", MODE="0644" read MODE="0664" and GROUP="usb"
The same error here. But after echo "=media-gfx/sane-backends-1.0.18-r2 ~x86" >> /etc/portage/package.keywords emerge -pu sane-backends These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild U ] media-gfx/sane-backends-1.0.18-r2 [1.0.17] emerge -u sane-backends etc-update reboot scanning as non-root with libusb-0.1.12 works again for me. (According to Bug 148608 sane-backends-1.0.18-r2 should become x86 stable soon.)
gregkh: check out Comment #11
Also encountered this issue with gphoto and a Canon camera. USB permissions under /proc/bus/usb are correct, but apparently libusb checks them at /dev/bus/usb. Can 0.1.12 be marked back to testing for time being, until solution is found, perhaps upstream?
*** Bug 149968 has been marked as a duplicate of this bug. ***
arch teams, can you please not mark 0.1.12 stable for your respective architectures. this problem needs to be solved otherwise your users are going to complain.
libusb-0.1.12 back to ~ppc for now; has upstream given any feedback on this issue yet?
sane needs udev rules written. they aren't hard to do. the move to /dev/bus/usb was reasonably announced by upstream, and other packages have responded in kind. I've been trying to get nut-2.0.4* stable, because it finally supports a lot of newer USB UPSes. It ships with this udev rule file (/etc/udev/rules.d/70-nut-usbups.rules), that sane will need to implement something like for libusb: # udev rules for the NUT USB drivers SUBSYSTEM!="usb_device", ACTION!="add", GOTO="nut-usbups_rules_end" # MGE UPS SYSTEMS - usbhid-ups SYSFS{idVendor}=="0463", SYSFS{idProduct}=="ffff", MODE="660", GROUP="nut" SYSFS{idVendor}=="0463", SYSFS{idProduct}=="0001", MODE="660", GROUP="nut" # APC - usbhid-ups SYSFS{idVendor}=="051d", SYSFS{idProduct}=="0002", MODE="660", GROUP="nut" # Powerware - bcmxcp_usb SYSFS{idVendor}=="0592", SYSFS{idProduct}=="0002", MODE="660", GROUP="nut" # Tripp Lite - tripplite_usb SYSFS{idVendor}=="09ae", SYSFS{idProduct}=="0001", MODE="660", GROUP="nut" LABEL="nut-usbups_rules_end" Sane should have it MUCH easier than NUT however, as IIRC all scanners should show up with a bInterfaceClass of USB_CLASS_STILL_IMAGE (6), which means you can cover every scanner with a single udev rule. If two or three people with USB scanners could attach tarballs of their /sys directory, I'll gladly whip up some udev rules for you, so that libusb can move forward, instead of backwards.
Apparently gphoto 2.2.0 also does the UDEV rules: http://www.gphoto.org/news/ So if you want to move this to stable, gphoto 2.2 should be stabilized at the same time.
Could libusb-0.1.12 be marked back ~amd64 also. This bit me today also. The only reason the scanner worked is because had a local udev rule in there from long time ago. What about what SpanKY said in #11? That is already there and shouldn't it be written that way from the getgo? : SUBSYSTEM=="usb_device", PROGRAM="/bin/sh -c 'K=%k; K=$${K#usbdev}; printf bus/usb/%%03i/%%03i $${K%%%%.*} $${K#*.}'", NAME="%c", MODE="0644" read MODE="0664" and GROUP="usb"
decibelshelp: changing that rule per spanky's request is one fix. the alternative fix like nut uses would end up with the similar result. spanky: maybe open a new bug to gregkh to get it fixed quicker?
Hi, I had the same problem and found on forums another work around : # echo "export USB_DEVFS_PATH=/proc/bus/usb" >> ~/.bash_profile
Don't use that environment variable, just fix the packages to do it properly.
Okay, back to ~amd64. (sorry, got lost in the shuffle) Add us back when you want it stable again...
*** Bug 150463 has been marked as a duplicate of this bug. ***
(In reply to comment #9) > i got the same problem, downgrading to libsusb-0.1.11 works fine for me, on > 0.1.12 i couldn' acces even my camera had to do udev rule but this is not ok > Downgrading didn't help (x86). I'm still not able to acces my ZenExtra as normal user. I did a revdep-rebuild too. Any suggestion?
What do the different upstreams (kernel/udev/libusb/lsb) say about this? seems /proc/bus/usb (and usbfs) is now not longer needed, as udev can provide all of its functions from userspace, and /dev would be a more suitable namespace for usb device nodes anyways. If usbfs really is deprecated/scheduled for removal, we should start fixing the udev rules now instead of waiting till a new kernel rev. breaks stuff. just my 2
What do the different upstreams (kernel/udev/libusb/lsb) say about this? seems /proc/bus/usb (and usbfs) is now not longer needed, as udev can provide all of its functions from userspace, and /dev would be a more suitable namespace for usb device nodes anyways. If usbfs really is deprecated/scheduled for removal, we should start fixing the udev rules now instead of waiting till a new kernel rev. breaks stuff. just my 2¢, /Ernst
Strange. I have both sane-backends, gphoto2-2.2.0, and libusb-0.1.12 on amd64, and I can find my scanner as non-root. Of course, the scanner in /dev/bus/usb/xxx/yyy is chgrp'ed "scanner" and the user I use (tygris) is part of the scanner group, so I don't have a permissions problem. Someone double-check that: Locate your scanner, where it's plugged in as root, and then ls -l the device in /dev/bus/usb to see if it's chgrp'ed "scanner". Then check to see if the non-root user is in the "scanner" group in /etc/group.
(In reply to comment #28) > Strange. I have both sane-backends, gphoto2-2.2.0, and libusb-0.1.12 on amd64, > and I can find my scanner as non-root. That's because gphoto 2.2.0 has been made to work with the udev stuff - like I said earlier - it should have been marked stable at the same time as libusb-0.1.12.
(In reply to comment #28) > Someone double-check that: Locate your scanner, where it's plugged in as root, > and then ls -l the device in /dev/bus/usb to see if it's chgrp'ed "scanner". > Then check to see if the non-root user is in the "scanner" group in /etc/group. > Mine does: /dev/bus/usb/002: total 0 crw-r--r-- 1 root root 189, 128 Oct 15 01:28 001 crw-rw---- 1 root scanner 189, 133 Oct 15 15:10 006 and non-root user is in the scanner group But that is only because I have a rule for the scanner. Had to write a rule a long time back to get it working. Wasn't the case with my camera though, before the libusb change it worked without a rule using gphoto2. You sure you don't have a rule for the scanner that is making this work?
(In reply to comment #29) > That's because gphoto 2.2.0 has been made to work with the udev stuff Hm, i have gphoto 2.2.0 and nevertheless i had to manually create an udev rule so the usb device for my camera is created with the right group.. (it defaults to being owned by group root)
(In reply to comment #31) > (In reply to comment #29) > > That's because gphoto 2.2.0 has been made to work with the udev stuff > > Hm, i have gphoto 2.2.0 and nevertheless i had to manually create an udev rule > so the usb device for my camera is created with the right group.. (it defaults > to being owned by group root) > Ah, then the package maintainer for gphoto hasnt added the stuff referred to in http://www.gphoto.org/news/ Build system (packagers beware!) * You should generate HAL FDI, linux-hotplug usb.usermap, and udev rules now via our program: ${libdir}/print-camera-list (hal-fdi|usb-usermap|udev-rules) This obsoletes print-usb-usermap and print-udev-rules. The hal FDI file should be put into: /usr/share/hal/fdi/information/10freedesktop/10-camera-libgphoto2.fdi ...so yes, udev rules need to be created but gphoto has the capability to do it automatically in 2.2.0. If the gphoto ebuild does not do it, I think a new bug should be filed.
BTW, did you update libgphoto as well when you tested the 2.2?
(In reply to comment #33) > BTW, did you update libgphoto as well when you tested the 2.2? Yes, it's a dependency. Well, i did some further research now. the udev rules from libgphoto (i've manually added them) just call the /etc/hotplug/usb/usbcam script, however that is already called from another source, so gentoo already had the correct rules i guess. The usbcam script changes the group of $DEVICE to plugdev - however, $DEVICE is always /proc/bus/usb/..., never /dev/bus/usb/...
Created attachment 100235 [details] usbcam > > Well, i did some further research now. > the udev rules from libgphoto (i've manually added them) just call the > /etc/hotplug/usb/usbcam script, however that is already called from another > source, so gentoo already had the correct rules i guess. > The usbcam script changes the group of $DEVICE to plugdev - however, $DEVICE is > always /proc/bus/usb/..., never /dev/bus/usb/... > The script is called, but there is something missing. When it's called from the hotplug agent, $DEVICE is set to /proc/bus/usb...., but when called from udev the device path resides in $DEVNAME. This updated /etc/hotplug/usb/usbcam script does the job.
Created attachment 100236 [details] usbcam Removed some debug stuff I accidentally left behind.
(In reply to comment #26) > (In reply to comment #9) > > i got the same problem, downgrading to libsusb-0.1.11 works fine for me, on > > 0.1.12 i couldn' acces even my camera had to do udev rule but this is not ok > > > > Downgrading didn't help (x86). I'm still not able to acces my ZenExtra as > normal user. I did a revdep-rebuild too. > > Any suggestion? > Hello, I confirm: downgrading to libusb-0.1.11 (or even libusb-0.1.10a) also did NOT fix the problem (x86). However, setting "USB_DEVFS_PATH=/proc/bus/usb" does provide a temporary solution.
(In reply to comment #36) > Created an attachment (id=100236) [edit] > usbcam I can confirm that this works, together with gphotos udev rules which you get by doing: /usr/lib/libgphoto2/print-camera-list udev-rules > /etc/udev/rules.d/libgphoto2.rules
I have libusb-0.1.12 installed and can scan with my HP 1410 as normal user. Looks like I cannot reproduce the problem here.
(In reply to comment #0) > emerging libusb-0.1.12 causes the famous "can't scan as non-root" permissions > problem. Reversion to libusb-0.1.11 fixes the problem. Running amd64, libusb-0.1.11, libgphoto2-2.1.6-r1, gphoto2-2.1.6 => non-root user can NOT access a digital camera whereas root can. Entries in /proc/bus/usb are 664 root:plugdev Entries in /dev/bus/usb are 664 root:root chmod'ing the /dev/bus/usb to 666 gives access, presumably changing the group to plugdev would do the same. I don't really know how to interpret the 50-udev.rules file but there is only one entry for usb_devices that I can see.
(In reply to comment #39) > I have libusb-0.1.12 installed and can scan with my HP 1410 as normal user. > Looks like I cannot reproduce the problem here. > With libusb-0.1.12 (x86), I can as well scan with my HP PSC 1210. However, I cannot access my digital camera (unless I become root).
I do have the same problem: not being able to access the digital camera via gphoto2. I did have libusb-0.1.12 installed, but downgrading to 0.1.11 doesn't help. Changing permissions of /dev/bus/usb/ did actually help, so it seems to me as if libusb-0.1.11 does have the same problem.
Ok, it also doesn't change when going back to 0.1.10a or 0.1.8 - so the root of the problem must be something different.
(In reply to comment #42) > I do have the same problem: not being able to access the digital camera via > gphoto2. I did have libusb-0.1.12 installed, but downgrading to 0.1.11 doesn't > help. Changing permissions of /dev/bus/usb/ did actually help, so it seems to > me as if libusb-0.1.11 does have the same problem. > Or the problem lies at least partly elsewhere. Using either libusb 0.1.12 or 0.1.11, I can only access my camera as non-root with stable udev and a line in 10-local.rules for my camera. Until recently was able to do so without the local rule and using udev 096-r1.
The problem appears to be fixed since upgrade to gphoto2-2.2.0 and libgphoto2-2.2.1-r1. I can now fully access my digital camera (Nikon Coolpix 4600) as a regular user.
libgphoto2-2.2.1-r1 fixed the problem for mee to. (Canon Digital Ixus 55)
So... everyone having the problem test w/ libgphoto2-2.2.1-r1 and report back please...
/me still thinks udev is broken. I needed to change the usb_device rule in 50-udev.rules as Spanky suggested it in comment #11
The only problem I'm having with libgphoto2-2.2.1-r1 is the rules: get whole bunch of these during gentoo part of bootup: udevd[1094]: add_to_rules: unknown key 'ATTRS{idVendor}', in 'ATTRS{idVendor}' Was helping out someone else getting this and they had this version. I upgraded and got it also. Can't remember order of things right now, but downgraded back to orig and still got it (perhaps orphaned udev rule file) and then removed 99-libgphoto2.rules file and error messages gone. Camera still worked, didn't need rules. Was just thinking. I don't need a rule for my camera, perhaps this error is because don't have a rule?? If I don't have to have a rule for my camera I don't think udev or libgphoto2 should be forcing me to make one just so it doesn't produce those errors. Camera worked with or without the error messages anyway. Otherwise, camera works with that version of libgphoto2, but 2 boxes I know of get that output during boot with it. But right now haven't tested downgrading again after deleting the udev rule file to see if it puts one there or leaves an orphaned file. Ice storm of the centry hit us and have been without power for 2 1/2 days, will test out later.
I'm having the same problem, and spent several hours searching the forums and other sources for a solution. The USB_DEFVS_PATH env var works, but as mentioned here, isn't ideal. This udev rule works for me: SUBSYSTEM=="usb_device", DRIVER!="usbhid", DRIVER!="hub", DRIVER!="hci_usb", PROGRAM="/bin/sh -c 'K=%k; K=$${K#usbdev}; printf bus/usb/%%03i/%%03i $${K%%%%.*} $${K#*.}'", NAME="%c", GROUP="plugdev", MODE="0664" I put it in /etc/udev/rules.d/10-local.rules. The idea here is that it doesn't set change the permissions on things like mice, keyboards, the USB hub itself, and (in my case) the hci_usb Bluetooth device. It's probably not security-conscious enough for everyone, but it lets me have access to any camera plugged in, not just particular models. Other libusb-based devices should work just as well. Since the original rule is still in 50-udev.rules, other devices will get the default permissions.
Removing ppc from. Feel free to add us back if something ppc specific needs to be done.
really removing ppc now :/ sorry for the bugspam
Reopen if you can reproduce with >=udev-104-r12; make sure you have *no* stale/orphaned files in /etc/udev/rules.d, that you've emerged udev with --noconfmem, that you've run etc-update or dispatch-conf after the upgrade and merged all the updated properly and rebooted the box after that.
Works fine for me now!
(Spring cleaning.) This works for me too.
