Bug 1023073 - no access to usb scanner from sane-find-scanner
no access to usb scanner from sane-find-scanner
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: sane-backends (Show other bugs)
20
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Nils Philippsen
Fedora Extras Quality Assurance
:
: 1026071 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-10-24 10:49 EDT by Leonid Kanter
Modified: 2014-10-24 20:52 EDT (History)
11 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-10-24 20:52:10 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Leonid Kanter 2013-10-24 10:49:18 EDT
Description of problem:



Version-Release number of selected component (if applicable):

systemd-208-4.fc20.x86_64


How reproducible:

always

Steps to Reproduce:

1. attach usb scanner, run sane-find-scanner as user


Actual results:

$ sane-find-scanner 

  # 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.

could not open USB device 0x1d6b/0x0002 at 002:001: Access denied (insufficient permissions)
could not open USB device 0x0b97/0x7772 at 007:003: Access denied (insufficient permissions)
could not open USB device 0x0b97/0x7761 at 007:002: Access denied (insufficient permissions)
could not open USB device 0x1d6b/0x0001 at 007:001: Access denied (insufficient permissions)
could not open USB device 0x055f/0x021a at 006:003: Access denied (insufficient permissions)
could not open USB device 0x1d6b/0x0001 at 006:001: Access denied (insufficient permissions)
could not open USB device 0x1d6b/0x0001 at 005:001: Access denied (insufficient permissions)
could not open USB device 0x1d6b/0x0002 at 001:001: Access denied (insufficient permissions)
could not open USB device 0x0af0/0x6911 at 004:003: Access denied (insufficient permissions)
could not open USB device 0x1d6b/0x0001 at 004:001: Access denied (insufficient permissions)
could not open USB device 0x0a5c/0x4503 at 003:005: Access denied (insufficient permissions)
could not open USB device 0x0a5c/0x4502 at 003:004: Access denied (insufficient permissions)
could not open USB device 0x413c/0x8126 at 003:003: Access denied (insufficient permissions)
could not open USB device 0x0a5c/0x4500 at 003:002: Access denied (insufficient permissions)
could not open USB device 0x1d6b/0x0001 at 003:001: Access denied (insufficient permissions)
  # No USB scanners found. If you expected something different, make sure that
  # you have loaded a kernel driver for your USB host controller and have setup
  # the USB system correctly. See man sane-usb for details.

  # 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
  # necessary.

Expected results:

it should show scanner model like that

found USB scanner (vendor=0x055f, product=0x021a [USB Scanner], chip=GT-6816) at libusb:006:003

Additional info:

Works from root user, works from non-root user on rhel6
Comment 1 Lennart Poettering 2013-12-12 20:56:42 EST
*** Bug 1026071 has been marked as a duplicate of this bug. ***
Comment 2 Zbigniew Jędrzejewski-Szmek 2014-10-12 17:25:30 EDT
70-uaccess.rules contains this line:
  ENV{libsane_matched}=="yes", TAG+="uaccess"
and 65-sane-backends.rules contains a list of scanners, and assigns ENV{libsane_matched}="yes". I think it is most likely that your scanner is missing from this list. Can you post the output of

  udevadm info /dev/...

where /dev/... is the scanner device (/dev/sgX probably)? It should contain

  E: libsane_matched=yes
  E: TAGS=:uaccess:
Comment 3 Kim Bisgaard 2014-10-13 02:25:47 EDT
I have this:
# ls -l /dev/sg*
crw-rw----+ 1 root cdrom 21, 0 Oct 13 08:11 /dev/sg0
crw-rw----. 1 root disk  21, 1 Oct 13 08:11 /dev/sg1
crw-------+ 1 root root  21, 2 Oct 13 08:11 /dev/sg2
# udevadm info /dev/sg2
P: /devices/pci0000:00/0000:00:14.4/0000:01:05.0/host8/target8:0:6/8:0:6:0/scsi_generic/sg2
N: sg2
E: DEVNAME=/dev/sg2
E: DEVPATH=/devices/pci0000:00/0000:00:14.4/0000:01:05.0/host8/target8:0:6/8:0:6:0/scsi_generic/sg2
E: ID_FOR_SEAT=scsi_generic-pci-0000_01_05_0-scsi-0_0_6_0
E: ID_PATH=pci-0000:01:05.0-scsi-0:0:6:0
E: ID_PATH_TAG=pci-0000_01_05_0-scsi-0_0_6_0
E: MAJOR=21
E: MINOR=2
E: SUBSYSTEM=scsi_generic
E: TAGS=:seat:uaccess:
E: USEC_INITIALIZED=82265
E: libsane_matched=yes
Comment 4 Zbigniew Jędrzejewski-Szmek 2014-10-13 08:50:56 EDT
That looks OK. Can you paste output from 'getfacl /dev/sg2'?
Comment 5 Kim Bisgaard 2014-10-13 09:00:29 EDT
#getfacl /dev/sg2
getfacl: Removing leading '/' from absolute path names
# file: dev/sg2
# owner: root
# group: root
user::rw-
user:kim:rw-                                                                                                                                  
group::---                                                                                                                                    
mask::rw-                                                                                                                                     
other::---
Comment 6 Zbigniew Jędrzejewski-Szmek 2014-10-13 09:15:26 EDT
So in fact you *do* have read-write permissions. I looked at your original bug report, and there you didn't ("+" was missing). So something changed meanwhile, though not on systemd side afaik. I'd be inclined to close this, unless you see the missing permissions again.
Comment 7 Kim Bisgaard 2014-10-13 09:34:23 EDT
I agree - has been working last time I used it - not often.

What about the usb-problem (Leonid Kanter). Let's give him a couple of days to chime in.
Comment 8 Leonid Kanter 2014-10-24 17:30:01 EDT
Confirming that it works now
Comment 9 Zbigniew Jędrzejewski-Szmek 2014-10-24 20:52:10 EDT
OK, problem seems to have gone away.

Note You need to log in before you can comment on or make changes to this bug.