Bug 186131

Same here on x86_64 using FC5 final with Canon EOS 300D camera

I also see this error: FC5 final ( Kodak EasyShare cx7220 ). gphoto2 2.1.99-8
This worked on FC4.

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.

Here is related bug:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=183972

looks like a selinux problem.

Here is the dmesg output after plugging in the camera:

usb 3-1: new full speed USB device using uhci_hcd and address 4
usb 3-1: configuration #1 chosen from 1 choice
audit(1144121337.284:16): avc:  denied  { search } for  pid=3232 comm="cat"
name="console" dev=dm-0 ino=589913 scontext=system_u:system_r:hald_t:s0
tcontext=system_u:object_r:pam_var_console_t:s0 tclass=dir

I think I tested without SELinux (disabled), but it didnt' help.

I tested with selinux disabled and it worked. No errors and import of images
successful.

jarki, maybe you can disable selinux again, or check for "denied" messages in
dmesg when you plug the camera in.

Tested once again - SElinux was disabled.
No changes, the same 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.

dmesg does not show any errors 

usb 2-1: new full speed USB device using uhci_hcd and address 3
usb 2-1: configuration #1 chosen from 1 choice

These same dmesg messages can be seen when SElinux enabled.

Also in my case SELinux is disabled (I always disable it during install as I
don't need it for desktop) and the problems exists. Same dmesg message as jarki has.

Installed another vanilla FC5 on another PC and the problem reproduces with
latest   
FC5 updates applied.

Ditto here. Selinux disabled - same behavior - more or less the same in fspot, too.

Found a easy fix from here 
http://www.redhat.com/archives/rhl-list/2006-May/msg02620.html
Works for my Canon PowerShot S45. 

The fix that jarki provided doesn't work for me (Canon EOS 300D) and I reverted
back to original settings in the .fdi file. However when I changed communication
mode from "normal" to "ptp" in my camera the issue is gone and I can import the
photos using regular user account.

In the /usr/share/hal/fdi/information/20thirdparty/10-camera-libgphoto2.fdi
file, I changed the entry for my camera model DC3400. I changed the
"camera.access_method" entry from 'proprietary' to 'ptp' as shown below:

<merge key="camera.access_method" type="string">ptp</merge>

Then, as a normal user, I turn on my camera for download and gthumb-import
starts up and states "no images". However, I press the camera button icon in the
gthumb-import window and it downloads the images ok.

At least I can now download the images without using root.

I also have this prob. After a bit of looking around...I have found that if as
su chown the /dev/bus/usb/ and /proc/bus/usb/ to my username, gthumb works.
So... I created a test script cutting from /usr/libexec/gphoto-set-procperm the
line "bus_num=`printf %.3u $HAL_PROP_USB_BUS_NUMBER`" and echoing $bus_num....
the output is "000". Could this be the source of the problem, the permissions on
the devices don't get chowned!

Reassigning to John, who has done the most of the hotplug work.

John, we need to make sure that this works reasonably for FC6

*** Bug 188383 has been marked as a duplicate of this bug. ***

what version of HAL are you using?  Is this fixed with the latest HAL release in
FC-5?

I am using hal-0.5.7.1-2.fc5 and kernel 2.6.17-1.2157_FC5 (currently the latest
versions) and the problem still reproduces.

(In reply to comment #17)
> I am using hal-0.5.7.1-2.fc5 and kernel 2.6.17-1.2157_FC5 (currently the latest
> versions) and the problem still reproduces.

Strange I had the same problem with my kodak ptp camera and it was fixed by the
latest hal, now I'm only experiencing bug 201359, iow gthumb-import doesn't get
started automaticly when I plugin the camera, but when I do it manually it works
fine as a normal user.

(In reply to comment #11)
>  However when I changed communication
> mode from "normal" to "ptp" in my camera the issue is gone and I can import the
> photos using regular user account.

Ah, maybe in normal mode its a usb storage device and you can access the photos
through the file manager?

This stopped happening for me a while ago. Sorry I didn't report it at the time.
I had forgotten about the bug.

(In reply to comment #19)
> This stopped happening for me a while ago. Sorry I didn't report it at the time.
> I had forgotten about the bug.

Same for me, jarki can you test with a fully up2date FC-5 system?

Tested with two different native FC5 installations (no update from previous
releases) with latest HAL and the problem still exists. In
10-camera-libgphoto2.fdi I had 
<merge key="camera.access_method" type="string">proprietary</merge>
which should be the original line.
Does this work for you with Canon (or Canon S45)?

(In reply to comment #21)
> Tested with two different native FC5 installations (no update from previous
> releases) with latest HAL and the problem still exists. In
> 10-camera-libgphoto2.fdi I had 
> <merge key="camera.access_method" type="string">proprietary</merge>
> which should be the original line.
> Does this work for you with Canon (or Canon S45)?

Please first run yum-update or puplet and let it fully update your system 2 of
us were seeing similar problems and no longer have this problem. Maybe it was in
udev or ...? Who knows? Thus please try with a fully updated system. Thanks!

Yes I run FC5 with the latest updates as you can see from my previous updates above.
Does this work for you with Canon (or Canon S45) with new FC5 installation, so
that you have not upgraded Fedora from previous releases (FC4)?

(In reply to comment #23)
> Yes I run FC5 with the latest updates as you can see from my previous updates
above.
> Does this work for you with Canon (or Canon S45) with new FC5 installation, so
> that you have not upgraded Fedora from previous releases (FC4)?

No I have another type of camera I just wanted to make sure this problem still
exists for you.

> Ah, maybe in normal mode its a usb storage device and you can access the photos
> through the file manager?

Nope, when I'm in 'normal' mode nothing seems to appear in /media. In FC4 it was
working ok in nomral mode but it wans't in PTP, AFAIK. In FC5 it works in PTP
but not in normal. Hopefully one of these modes will continue work in FC6 ;-)

Tested with current updated FC5 (updated as of 13th Aug 2006) and works fine
with Canon PowerShot A700. Although it doesn't detect the camera by name, it
correctly detects that a digital camera is connected and accesses it as a PTP
camera and downloads images when logged in as a normal (non-root) user.

This is an FC5 bug, so moving of FC6Desktop. Actually, this should probably be
closed now, John ?

Matthias, the problem is not solved yet.
Why you are saying this should be closed?
Thanks.

Upgraded two laptops, which previously has this problem, from FC5 to FC6 and 
tested this with the same PowerShot S45.
This seems to work now without problems.
Thanks.

Problem still exists in Fedora 8, gthumb 2.10.7-1.fc8 with my PowerShot A560 on
both my 32bit desktop and my AMD 64x2 laptop.

Another observation.  This error may be intermittent.  Yesterday the upload was
not working.  Today, first thing after logging in, it works.  Then, closed
gthumb and turned the camera off.  Then turned the camera back on. gthumb came
up reporting a camera was detected and there were photos to import.  So I
clicked the import button and got the whole "Could not claim the USB device"
error that I was getting yesterday.

Problem has gone away for me.  I can now upload every time as a normal user. 
Have received a few fedora updates since my last post (#31) including updates to
the kernel.

Fedora Core 5 is no longer maintained. Is this bug still present in Fedora 7 or
Fedora 8?

As a filer I can say that the bug does not reproduce anymore in Fedora 8 with
the latest updates.
Thanks.