In the decade I’ve been using Linux, it’s gone from something that required lots of technical know-how just to set up, to something that (in its major flavors) can auto-detect most hardware and provides friendly GUIs for most configuration tasks. But every once in a while, I have the kind of experience that would turn a new user off of Linux. Usually because Fedora has decided to change something during an update.

In this case, it was a digital camera problem. Since we bought our Canon PowerShot SD600 last December, I’ve used KDE’s digiKam to transfer and manage the photos. DigiKam detected the camera and accessed the photos right out of the box, no configuration needed beyond telling it to remember the model. But something changed in the last two weeks, and last night I started getting an error message: Failed to connect to the camera. Oddly enough, it could still detect the camera when it was connected. But it couldn’t display or download the images.

I searched all over, hitting dead end after dead end, until I got a hint that it was a permissions problem. That’s when I hit the command line to start troubleshooting.

Digikam uses a library called gphoto2 to access cameras. It has utilities that you can run from the command line for testing. I ran gphoto2 --auto-detect, which dutifully reported the correct camera. I ran gphoto2 -l to list the folders on the camera, and it spit out an error including the phrase: Could not claim the USB device. The interesting thing was, if I ran the same command as root, it was able to see the folders.

Way back when, Linux used a static list of devices in /dev. Now that everyone is constantly connecting and disconnecting devices with USB, Firewire, Bluetooth etc., that’s not practical. Most modern Linux distributions use one method or another to dynamically build that list from what’s actually connected to the computer, and react when new devices are plugged in. Fedora 7 uses udev to identify and configure devices. I had to figure out how to tell udev to give me write access.

I finally found the gphoto documentation on setting permissions, and found the command I needed: print-camera-list, which will build a list of rules for udev to use when someone attaches a camera. Unfortunately, the directions were slightly out of date. Instead of adding a “version 0.98” option, it wanted “udev-rules-0.98”.

So the command I used (as root) was this:

/usr/lib/libgphoto2/print-camera-list udev-rules-0.98 group users mode 0660 > /etc/udev/rules.d/90-libgphoto2.rules

Note that where it says “users” you should substitute the name of the group your account belongs to. (In Fedora, that might actually be the same name as your username, since it likes to create a group just for you.)

It took me about an hour to track this down, since initial searches sent me looking in the wrong direction. I’m hoping this blog post will save someone else a little time and frustration.

Update (June 2008)

I’ve run into a different problem with Fedora 9. In this case, I’m running digiKam under the GNOME desktop. GNOME can mount the camera now, so it auto-mounts and pops up a filesystem window. But when I try to access the camera in digiKam, I get the same error message about not being able to connect.

It turns out this one’s just a conflict: either the virtual filesystem or digiKam can access the camera, but not both at once. I just right-clicked on the icon on the desktop, unmounted it, and was able to connect in digiKam.

12 thoughts on “When digiKam Failed to Connect

  1. Thank you so much for your help! I panicked when my digiKam software stopped working after I reinstalled Fedora. Being a Linux newb I would have never figured out how to fix it, but with your instructions digiKam works fine!

  2. Thanks for the information!

    It fixed the problem after my camera stopped working with a recommended kernel upgrade to FC7.

    This also happened about 1 month earlier again with a kernel upgrade, however I was able to fix it on this occasion by updating the 50-udev.rules file (changing mode 0644 to 0666 for the usb device)

    see for further details

    Great to see that the Linux community spirit is alive and well.

    The rest of us certainly appreciate it!! :o)

  3. Thanks a lot, it helped me by pointing to the correct location of the problem.

    I solved the problem in a different way, as Debian has a group plugdev and gives this group rwx-permission in the ruleset. So I simply added the allowed users to the plugdev group and won’t have problems with the rules-file at the next updates.

    BTW: It is fine, that you have included the error message in the post. In this way it could be googled. πŸ˜‰

  4. Thanks a lot.
    Saved me some time…

    But things like :

    “/usr/lib/libgphoto2/print-camera-list udev-rules-0.98 group users mode 0660 > /etc/udev/rules.d/90-libgphoto2.rules

    …shouldn’t be necessary to get things working.


    ( sorry for the caps….)

    But now things work.
    Thanks again.

  5. Hi,

    great work with this article.
    Did you notify the developers so they can incorporate it as a general fix?

    Kind regards.

  6. Nice informative post. On my system (libgphoto2-2.4.0-25.2, opensuse 10.3, KDE 4.3), the print-camera-list syntax did not work, I had to use
    print-camera-list udev-rules version 0.98 group users …
    Oh, and what was ultimately the cause for the connection failure in my particular case was a leftover Konqueror/KDE3 trying to automount the camera.

  7. “It turns out this one’s just a conflict: either the virtual filesystem or digiKam can access the camera, but not both at once. I just right-clicked on the icon on the desktop, unmounted it, and was able to connect in digiKam.”

    Thanks a lot for this… that’s all I needed to know to make digikam talk to my Canon 450D. Much appreciated!

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.