Red Hat Bugzilla – Bug 432392
xsane: no devices available
Last modified: 2009-12-14 15:42:25 EST
# ls -l /dev/scanner*
lrwxrwxrwx 1 root root 9 Feb 11 18:49 /dev/scanner-usbdev2.4 -> usbdev2.4
Description of problem:
xsane does not find my usb scanner when running xsane as normal user (although
the scanner is connected). This worked already with Fedora 8 some weeks ago and
stopped working suddenly (after an update, I guess).
Scanning as root works fine.
Bus 002 Device 004: ID 04b8:0110 Seiko Epson Corp. Perfection 1650
Bus 002 Device 003: ID ...
Bus 002 Device 002: ID ...
Bus 002 Device 001: ID 0000:0000
Bus 001 Device 001: ID 0000:0000
found USB scanner (vendor=0x04b8, product=0x0110) at libusb:002:004
Obviously, it has something to do with permissions:
$ ls -l /dev/scanner*
lrwxrwxrwx 1 root root 9 11. Feb 20:02 /dev/scanner-usbdev2.4 -> usbdev2.4
$ ls -l /dev/usbdev*
crw-rw---- 1 root root 189, 0 11. Feb 20:02 /dev/usbdev1.1
crw-rw---- 1 root root 251, 0 11. Feb 20:02 /dev/usbdev1.1_ep00
crw-rw---- 1 root root 251, 1 11. Feb 20:02 /dev/usbdev1.1_ep81
crw-rw---- 1 root root 189, 128 11. Feb 20:02 /dev/usbdev2.1
crw-rw---- 1 root root 251, 2 11. Feb 20:02 /dev/usbdev2.1_ep00
crw-rw---- 1 root root 251, 3 11. Feb 20:02 /dev/usbdev2.1_ep81
crw-rw---- 1 root root 189, 129 11. Feb 20:02 /dev/usbdev2.2
crw-rw---- 1 root root 251, 4 11. Feb 20:02 /dev/usbdev2.2_ep00
crw-rw---- 1 root root 251, 5 11. Feb 20:02 /dev/usbdev2.2_ep81
crw-rw---- 1 root root 189, 130 11. Feb 20:02 /dev/usbdev2.3
crw-rw---- 1 root root 251, 6 11. Feb 20:02 /dev/usbdev2.3_ep00
crw-rw---- 1 root root 251, 7 11. Feb 20:02 /dev/usbdev2.3_ep81
crw-rw---- 1 fs lp 189, 131 11. Feb 20:02 /dev/usbdev2.4
crw-rw---- 1 root root 251, 8 11. Feb 20:02 /dev/usbdev2.4_ep00
crw-rw---- 1 root root 251, 10 11. Feb 20:02 /dev/usbdev2.4_ep02
crw-rw---- 1 root root 251, 9 11. Feb 20:02 /dev/usbdev2.4_ep81
Unfortunately, even something like "chown foo.foo /dev/usb*; chmod 0777 /dev/usb*"
does lead to xsane working with a normal user.
I found bug 244444 which looks quite similar but:
$ rpm -q udev
I suspect that there is some problem with udev involved but I want to let you make
the choice to which package this belongs.
Version-Release number of selected component (if applicable):
$ rpm -q xsane
$ rpm -q sane-backends
Steps to Reproduce:
1. Connect scanner to computer
2. launch xsane as normal user
I've been working on using PolicyKit for the permission thing instead of udev in
the current Rawhide packages of sane-backends-1.0.19. I've made a scratch build
of the current revision for i386 and x86_64:
Please test the packages suitable for your hardware and report back whether this
improves the situation.
After installing the packages from koji
sane-backends-libs-gphoto2-1.0.19-0.2.fc8.x86_64.rpm), the situation is still
The only change is that there is no /dev/scanner... link any more.
(In reply to comment #2)
> After installing the packages from koji
> sane-backends-libs-gphoto2-1.0.19-0.2.fc8.x86_64.rpm), the situation is still
> the same.
> The only change is that there is no /dev/scanner... link any more.
What are the permissions/ownership of the device file?
Which device file?
$ ls -l /dev/usbdev*
crw-rw---- 1 root root 189, 0 13. Feb 18:53 /dev/usbdev1.1
crw-rw---- 1 root root 251, 0 13. Feb 18:53 /dev/usbdev1.1_ep00
crw-rw---- 1 root root 251, 1 13. Feb 18:53 /dev/usbdev1.1_ep81
crw-rw---- 1 root root 189, 3 13. Feb 18:57 /dev/usbdev1.4
crw-rw---- 1 root root 251, 8 13. Feb 18:57 /dev/usbdev1.4_ep00
crw-rw---- 1 root root 251, 10 13. Feb 18:57 /dev/usbdev1.4_ep02
crw-rw---- 1 root root 251, 9 13. Feb 18:57 /dev/usbdev1.4_ep81
crw-rw---- 1 root root 251, 11 13. Feb 18:57 /dev/usbdev1.4_ep83
crw-rw---- 1 root root 189, 128 13. Feb 18:53 /dev/usbdev2.1
crw-rw---- 1 root root 251, 2 13. Feb 18:53 /dev/usbdev2.1_ep00
crw-rw---- 1 root root 251, 3 13. Feb 18:53 /dev/usbdev2.1_ep81
crw-rw---- 1 root root 189, 129 13. Feb 18:53 /dev/usbdev2.2
crw-rw---- 1 root root 251, 4 13. Feb 18:53 /dev/usbdev2.2_ep00
crw-rw---- 1 root root 251, 5 13. Feb 18:53 /dev/usbdev2.2_ep81
crw-rw---- 1 root root 189, 130 13. Feb 18:53 /dev/usbdev2.3
crw-rw---- 1 root root 251, 6 13. Feb 18:53 /dev/usbdev2.3_ep00
crw-rw---- 1 root root 251, 7 13. Feb 18:53 /dev/usbdev2.3_ep81
crw-rw---- 1 root root 189, 131 13. Feb 19:12 /dev/usbdev2.4
crw-rw---- 1 root root 251, 12 13. Feb 19:12 /dev/usbdev2.4_ep00
crw-rw---- 1 root root 251, 14 13. Feb 19:12 /dev/usbdev2.4_ep02
crw-rw---- 1 root root 251, 13 13. Feb 19:12 /dev/usbdev2.4_ep81
But changing the ownership for all devices listed above to my user does change
(In reply to comment #4)
> But changing the ownership for all devices listed above to my user does change
"Does" or "doesn't"? I assume the latter ;-). Do you have SELinux enabled? What
does "sane-find-scanner" and "scanimage -L" give?
Yes, "doesn't" is correct - fortunately, humans are much smarter than computers :-)
$ cat /etc/selinux/config | grep -v '^#'
# sane-find-scanner will now attempt to detect your scanner. If the
# result is different from what you expected, first make sure your
# scanner is powered up and properly connected to your computer.
# No SCSI scanners found. If you expected something different, make sure that
# you have loaded a kernel SCSI driver for your SCSI adapter.
found USB scanner (vendor=0x04b8, product=0x0110) at libusb:002:004
# Your USB scanner was (probably) detected. It may or may not be supported by
# SANE. Try scanimage -L and read the backend's manpage.
# Not checking for parallel port scanners.
# Most Scanners connected to the parallel port or other proprietary ports
# can't be detected by this program.
# You may want to run this program as root to find all devices. Once you
# found the scanner devices, be sure to adjust access permissions as
$ 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).
Would you please strace scanimage both as normal user and as root and attach a)
the output and b) the strace output (don't paste)? The command would be
(provided strace is installed):
strace -Ff -o <stracefile> scanimage -L -v > <outputfile> 2>&1
Here, <stracefile> would be the file getting the strace output and <outputfile>
would get the output of scanimage.
Created attachment 295213 [details]
strace as requested when running scanimage as a user
As you can see in the previously attached strace log, The normal user is lacking
permissions on /proc/bus/usb/002/004 (where my scanner is attached). Changing
the owner from root/root (0644) to <user> fixes the issue.
Therefore the only remaining question for me is why these permissions are not
The strace shows that /proc/bus/usb is used which is an obsolete interface. This
is likely because it doesn't seem to find /dev/bus/usb -- which version of udev
do you have?
Scratch that question, you've answered that one before. I should learn to read ;-).
Another question: Which kernels do you have installed and which are you running
("rpm -qa kernel\*; uname -a")?
BTW, new scratch build waiting for you at:
$ rpm -qa kernel\*; uname -a
Linux ws2.schwarz.lokal 2.6.21-2957.fc8xen #1 SMP Tue Feb 12 13:07:27 EST 2008
x86_64 x86_64 x86_64 GNU/Linux
Maybe its the Xen kernel I'm running?
Upgrading to the referenced koji RPMs did not fix the problem (do I have to
restart some daemon?).
That you're running the XEN kernel may just be the culprit -- it's the
/dev/bus/usb hierarchy missing which causes libsane/libusb to fallback to using
/proc/bus/usb which doesn't (can't) have the permissions setup correctly for
I'm moving this to the kernel-xen component and adding Harald Hoyer and myself
to Cc. Harald is the Fedora maintainer for udev and mentioned some incompatible
changes made in the kernel w.r.t. udev and I suspect that these haven't been
done in the kernel-xen package yet.
BTW: The new sane-backends packages are just to ensure that we're on the same
page with regard to what's being tested.
This message is a reminder that Fedora 8 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 8. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora
'version' of '8'.
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version prior to Fedora 8's end of life.
Bug Reporter: Thank you for reporting this issue and we are sorry that
we may not be able to fix it before Fedora 8 is end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora please change the 'version' of this
bug to the applicable version. If you are unable to change the version,
please add a comment here and someone will do it for you.
Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
The process we are following is described here:
Fedora 8 changed to end-of-life (EOL) status on 2009-01-07. Fedora 8 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.
If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version.
Thank you for reporting this bug and we are sorry it could not be fixed.