Description of problem: usb connection recognized but gphoto2/gthumb etc. fail to access images. Root has no problems. Version-Release number of selected component (if applicable): udev-116-3.fc8 kernel-2.6.23.9-85.fc8 How reproducible: always Steps to Reproduce: 1.plug in camera 2.try to import images 3. Actual results: 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. Expected results: driver loading Additional info: http://www.fedoraforum.org/forum/showthread.php?t=170607&page=1&pp=15&highlight=camera Making MODE changes as suggested works but presumably this is not a permanent and secure fix. This problem seems to come up regularly! Isn't it about time it got checked before release?
Possibly need to get a fix out the door quickly on this. It becomes more of an image issue (i.e. how many times does Fedora drop the ball on little niggles like this). These are the things that take the lustre off a polished release. P.S. I don't have a PTP camera, so am not waiting for a fix. I know 2 people who are waiting, however, so am monitoring on their behalf.
$ rpm -qf /usr/share/hal/fdi/information/10freedesktop/10-camera-ptp.fdi /usr/share/hal/fdi/policy/10osvendor/20-acl-management.fdi hal-info-20071030-1.fc8 hal-0.5.10-1.fc8
For F9 the workaround mentioned in comment #0 does not work anymore. Actually even root gets this error message now. Should I open a separate bug for rawhide?
This was fixed Monday with the latest hal package http://cvs.fedoraproject.org/viewcvs/devel/hal/hal.spec?r1=1.152&r2=1.153
(In reply to comment #4) > This was fixed Monday with the latest hal package > > http://cvs.fedoraproject.org/viewcvs/devel/hal/hal.spec?r1=1.152&r2=1.153 That's the hal I was using when writing comment #3. Actually I was using an even more recent version: hal-0.5.11-0.5.rc2.fc9.x86_64
Created attachment 302255 [details] env LANG=C gphoto2 --debug --debug-logfile=my-logfile.txt -L Both gthumb-import and gphoto2 still fail on rawhide. I added the gphoto2 debug output.
The gphoto2 output is not very useful. Please attach the output of 'lshal' and the output of 'getfacl `find /dev/bus/usb`' instead. Thanks.
And also the output of 'ck-list-sessions'. Thanks.
$ ck-list-sessions Session2: uid = '501' realname = 'Axel Thimm' seat = 'Seat1' session-type = '' active = TRUE x11-display = ':0' x11-display-device = '/dev/tty7' display-device = '' remote-host-name = '' is-local = TRUE on-since = '2008-04-14T16:41:56Z'
Created attachment 302366 [details] lshal output shortlz after plugging in the camera
Created attachment 302367 [details] ACLs of usb devices The relevant part is probably # file: dev/bus/usb/005/003 # owner: root # group: root user::rw- user:thimm:rw- group::rw- mask::rw- other::rw- Note that the 0666 mode is due to trying the workaround quoted above. So permissions look like fully set, but the camera will still refuse to work with the ioerror.
BTW, there are two gthumb-import instances being invoked in series when plugging in the camera. Not sure this makes any difference to this bug, but I thought perhaps they lock eachother off the camera. But I tried to call gthumb-import manually also, and the result is the same (but it also does ask again about importing). Calling it from the commandline reveals some more output: $ gthumb-import libhal.c 1310 : invalid udi: doesn't startwith '/org/freedesktop/Hal/devices/'. error: libhal_device_get_property_type: (null): (null)
Permissions does look about right. Looks to me like a gthumb problem...
Actually this is a gnome-volume-manager problem as that file comes from that package.
The original bug (permissions) is fixed, I moved the discussion of the timeout problem to bug #443515.