Red Hat Bugzilla – Bug 239250
Permission denied importing photos from camera
Last modified: 2013-03-05 22:50:41 EST
Description of problem:
Cannot import photos from camera. This may be a hal error, perhaps something
should be setting the permissions on this?
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Attach cannon powerShot A510 camera
2. run gphoto2 -P
*** Error ***
An error occurred in the io-library ('Could not claim the USB device'): Could
not claim interface 0 (Operation not permitted). Make sure no other program or
kernel module (such as sdc2xx, stv680, spca50x) is using the device and you have
read/write access to the device.
*** Error (-53: 'Could not claim the USB device') ***
pertinent lines from strace:
open("/dev/bus/usb/001/003", O_RDWR) = -1 EACCES (Permission denied)
open("/dev/bus/usb/001/003", O_RDONLY) = 6
ioctl(6, USBDEVFS_GETDRIVER, 0xbfb81244) = -1 EPERM (Operation not permitted)
Created attachment 154236 [details]
logfile as created by gphoto2
I'm seeing this as well with a canon s700. ;(
If you manually chmod 666 /dev/bus/usb/X/X it works, so it looks like a
permissions issue from udev or something.
I see this too, with a PowerShot A710 IS.
It's not definitely a bug in gphoto2, so reassigning it to udev. IMO the default
644 permissions for the USB devices don't make too much sense as only read
permissions are useless for USB interface, 660 whould fit better here to have
R/W perms for owner (likely root) and also for people in a specific group. That
would fix the problems you see.
hmm, pam_console or HAL?
Created attachment 157082 [details]
part of lshal output for Canon S3
The same result with Canon S3.
As lshal shows, existed entries like
"info.bus" and so on dont match with
rules in 10-camera-ptp.fdi (hal-info)
and 10-camera-libgphoto2.fdi (old gphoto).
- full lshal output
- output of ck-list-sessions
- distro version (I assume Rawhide)
Created attachment 157264 [details]
full lshal output
Created attachment 157265 [details]
My distro is "near Rawhide" -- local
rebuild with some small local changes.
There's no USB interface for the USB device
Is there any useful output in dmesg? Thanks.
It seems to be a kernel problem.
On old kernel, similar to rh 3119, all works fine.
Under research now.
It may be an interference between new kernel
USB naming scheme and old HAL rules.
*** Bug 249239 has been marked as a duplicate of this bug. ***
Created attachment 159777 [details]
lshal for Canon IXUS 55
This is fedora 7 with all updates running
Notice how it say info.subsystem = 'usb' instead of info.subsystem =
'usb_device' as the other say. Also the file
/usr/share/hal/fdi/policy/10osvendor/20-acl-management.fdi uses 'usbraw" and
there is no such thing as far as I can see.
Does this work for anyone?
Seems like it is an issue with the latest kernel. When I tried an earlier 2.6.21
kernel it worked fine.
Same here: the most recent 2.6.21 kernel works as expected, with no other changes
System is Fedora 7 x86_64, fully updated
Camera is Fujifilm Finepix S6500fd
This will get fixed with the next hal update. FYI, for Fedora 7 it should be
fixed with an update; that's tracked in bug 249211.
Hmmm... I see this problem with 2.6.21 and 2.6.22 series kernels with a Canon
EOS 400D (error message is "An error occurred in the io-library ('Could not
claim the USB device'): Could not claim interface 0 (Operation not permitted).
Make sure no other program or kernel module (such as sdc2xx, stv680, spca50x) is
using the device and you have read/write access to the device."). Only think I
can think has been updated recently is udev.
FWIW, the upstream bugfix is
I'll get this into Fedora soon.
David, I tried the above patch but I'm still having no luck. Might I be missing
some udev rules?
/usr/lib/libgphoto2/print-camera-list udev-rules mode 0666 > \
it appears to be working again.
> /sbin/udevcontrol reload_rules
this is not necessary, because udevd watches all rule files for changes.
Even if the file concerned doesn't already exist?
Finally tracked down the problem to a corrupt /var/lib/hal/acl-list --- the USB
device node ACL wasn't being set correctly. So it now works without the udev hack.
Seems to work now.