Red Hat Bugzilla – Bug 984913
gvfs-gphoto2 fails when copying files from the camera using caja or nautilus
Last modified: 2013-11-24 11:14:45 EST
Description of problem:
When trying to copy files from the camera using any software relaying on gvfs-gphoto2, I get the following error: "Operation not supported by backend"
Version-Release number of selected component (if applicable):
always (on two different machines, tested with Caja, Nautilus, Thunar)
Steps to Reproduce:
1. Install gvfs-gphoto2
2. Connect camera
3. Browse images
4. Attempt to copy images
A popup error message appears "Operation not supported by backend"
Files copied without error message
$ gphoto2 -P
downloads all files with no issues
also installing any software capable of importing images (darktable, shotwell) will import them without any issues too, though none of these apps are installed by default on MATE Desktop, separate bug was filled for it: https://bugzilla.redhat.com/show_bug.cgi?id=984908 ).
Created attachment 776906 [details]
screenshot of error message
Here's a screenshot showing the error. Marking with a priority of "high" due to wife grief factor ;).
Opening the files directly in various editing packages and there is no issue.
I have the same problem now, but only with a Canon Power Shot SX 260 HS, while I don't have this problem with the old Nikon Coolpix 4100.
Same problem with canon 50d
Same problem with iPhone 5. The gvfs mount works fine in a terminal, but copying the files in nautilus, which used to be the easiest way to download the photos on F17, now just gives "Operation not supported by backend" after upgrading to F19.
I am pretty sure the problem is with either gvfs or nautilus, not with specific cameras. In fact, I am also not completely sure but I think the iPhone uses gvfs-afc, not gvfs-gphoto2 -- so this may be a general problem that affects more than one backend. gvfs-gphoto2 is probably not the main culprit -- I'd look at the nautilus/gvfs interaction.
Ah, in fact, here's a lower-level manifestation of the same problem, still on iPhone -- no nautilus or other file manager involved, it's clearly 100% a gvfs problem. Someone with a camera with a gvfs-gphoto2 mount could try to confirm whether the same issue happens with gvfs-gphoto2 as with gvfs-afc -- I suspect that's probably the case.
~ > gvfs-ls afc://e545[...]c3df/DCIM/100APPLE/
~ > gvfs-copy afc://e545[...]c3df/DCIM/100APPLE/IMG_0463.JPG .
Error copying file afc://e545[...]c3df/DCIM/100APPLE/IMG_0463.JPG: Operation not supported by backend
~ > ls /run/user/500/gvfs/afc:host=e545[...]c3df/DCIM/100APPLE/
~ > cp /run/user/500/gvfs/afc:host=e545[...]c3df/DCIM/100APPLE/IMG_0463.JPG .
[file copies successfully]
I have the same problem in Thunar filemanager.
Connecting a camera (eg. canon 50d) shows up immediately in Thunar device list, and browsing images on the camera is possible, even thumbnails are created. Trying to open an image in eg. Geeqie, by double-clicking it in the filemanager, does not work however, and neither does copy/paste from the gphoto2 location via the filemanager.
Nothing gets populated in /run/user/1001/gvfs/ or /run/media either.
Probably connected with:
(In reply to Ondrej Holy from comment #8)
> Probably connected with:
That bug now has a varified patch.
Can we get Fedora 19 package(s) fixed and respun?
FWIW I can verify https://git.gnome.org/browse/glib/commit/?id=be2656f13952dd22d348ff5e3f43240700cdef5a fixing the issue here. Wife happy now, I'm going to be happy once this has been pushed as an update to Fedora so I dont need to maintain a locally built version of glib2.
And yes the patch in question is on glib2, not gvfs, switching to correct component.
Detected same issue with Fedora 19 x86_64 after update from F18.
Same computer/camera worked fine on F18 prior to the update
last weekend. Camera is Canon 50D.
I can manually copy the files from the command line.
I belive bug 986543 is a duplicate of this bug.
I have the same problem on F19 x86_X64 with a Kodak Easyshare M590 camera and my iPhone. Workaround is either to use a program such as GIMP to open off the device and save to my HDD or to copy files via command line
Fails to me too, Fedora 19.
I've added that patch to the Fedora 19 glib2 package.
glib2-2.36.3-4.fc19 has been submitted as an update for Fedora 19.
* should fix your issue,
* was pushed to the Fedora 19 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing glib2-2.36.3-4.fc19'
as soon as you are able to.
Please go to the following url:
then log in and leave karma (feedback).
As I understand it, we need one more person to test the
update (see comment 16) and up-vote it, and then it can
be pushed to Fedora 19 stable.
Meh, I intended to do test it a while ago but just forgot... anyway, done + "voted" now. Oh and thanks Richard for bothering to make the update!
glib2-2.36.3-4.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.
I confirmed the bug is fixed with the updated glib2 package in F19. For the sake of completeness, I reproduced the bug in the last F20 Beta release, but it is fixed in F20 TC1.