Libiphone libiphone → 1.0 Release

Comments and changes to this ticket

• 

  Martin S. June 10th, 2009 @ 04:58 PM

  • Tag changed from “automount, fdi, gnome, udev” to “automount, fdi, gnome, ifuse, udev”
  • State changed from “new” to “open”

  Got almost exactly the same mess like you.

  For me to make auto-mounting work (halfway) I had to add this gconf key "/system/storage/default_options/fuse.ifuse/mount_options" as a list type with the string "allow_other". I think nautilus (or GVfs) check that key and if it's not there mounting seems to fail due to permission issues.

  After that you get the same mess again this time with names like /media/iPhone, /media/iPhone_, /media/iPhone__, ...
  This is due to unmounting fails due to permission issues whoever issued it (Nautilus or user had choosen unmount volume).

  The thing is a bit complex to dissect (if one is lazy) since one must track the sources of nautilus, GVfs daemon+monitors which all do some creepy async DBUS ping pong to determine mountability but it seems the issue is with iFuse.

  I have a rough idea why things happen this way and what the issue is. Check what happens roughly when an iPhone/iPod Touch is plugged in:

  • HAL keys are read by GVfs and are correct
  • GVfs daemon does some DBUS ping pong with a GVfs monitor and determines I should mount the new device
  • GVfs checks volume.fstype as "fuse.ifuse" and thus calls /sbin/mount.fuse.ifuse
  • Comparing ntfs-3g and others in this case, GVfs supplies them uid,gid credentials which in turn are ignored by iFuse (looks like the main issue to me here) and thus the device is apparently mounted by root (instead of the correct desktop user)
  • if no "allow_other option was passed (which only happens with that gconf key set I described) the mountpoint is not even accessible form the regular user
  • GVfs notices and exposes any fuse mounts to Nautilus
  • Nautilus displays the thing and reads the volume name and stuff from the HAL keys
  • Unmounting manually or letting GVfs unmount it fails since the process attempts to unmount as the user who mounted it (the initially passed uid,gid) but the whole thing was mounted by root.

  Checking through ntfs-3g sources and other fuse file systems I noticed that they make use of the passed uid,gid credentials and perhaps iFuse should too.
  Also the behavior seems different depending on the distribution used.

• 

  Nikias Bassen June 10th, 2009 @ 11:41 PM

  Ok I see. BTW, the only fdi "information" file I have in place is 31-apple-mobile-device.fdi (I deleted 30-ifuse.fdi because I don't want automounting) which has the following contents:

  <?xml version="1.0"?>
  <deviceinfo version="0.2">
    <device>
      <match key="info.subsystem" string="usb">
        <match key="usb.vendor_id" int="0x05ac">
          <match key="usb.product_id" compare_ge="0x1290">
            <match key="usb.product_id" compare_le="0x1293">
              <match key="usb.interface.number" int="0x1">
                <append key="info.capabilities" type="strlist">afc</append>
              </match>
            </match>
          </match>
        </match>
      </match>
    </device>
  </deviceinfo>
  

  So I wonder what the heck is telling GVfs or whatever to try to automount something. Perhaps it's about the configuration 3 change that the udev rule for usbmuxd performs which presents multiple interfaces or whatever to the system.

• 

  Martin S. June 11th, 2009 @ 09:03 AM

  Check your paths for other leftover fdi's since it won't automount without a few required keys like volume.fstype being exposed on the HAL device.
  Also check what "lshal -v" tells you about the device and it's usb interfaces. If it still contains the volume.* keys and others added by 30-ifuse.fdi you probably have an older one lying around somewhere.

  The udev config change is basically happening below and before everything else comes to live and should not affect this.

• 

  Nikias Bassen June 11th, 2009 @ 06:09 PM

  • Title changed from “automounting under GNOME (fdi?)” to “automounting under GNOME with pretty name”

  I found it. It's in libgphoto2's prepropbe fdi file. After explaining the issue to the libgphoto developers they commited the necessary changes. Bug for Ubuntu has also been reported:

  https://bugs.launchpad.net/ubuntu/+source/libgphoto2/+bug/386002

  The problem is that the iphone has two interfaces, and both of them are set to info.category "camera" and appended "camera" to the info.capabilities list. This explains why multiple cameras show up on the desktop and also explains why an exclusive device access is not possible and causing an error ;)

  I played a bit and made it possible to get a pretty name for the automount using the iphone_id tool via a script hal-probe-iphone. Patch for ifuse is attached. I also changed several append tags to merge as copy_property is not useful with append when just copying a string.

  The only problem we have now is the permission problem as the mount is performed as root... how do we fix this?

• 

  Martin S. June 12th, 2009 @ 09:53 AM

  Hmm, on my system I can't see that behavior. I guess I have some older generated preprobe definitions not containing the iPod Touch 1G then (using libgphoto2-2.4.3-3.1).
  

     <match key="usb.interface.class" int="6">
  
  
  
  
  
  
  

  <match key="usb.interface.subclass" int="1">
   <match key="usb.interface.protocol" int="1">
    <merge key="info.category" type="string">camera</merge>
    <append key="info.capabilities" type="strlist">camera</append>
    <merge key="camera.access_method" type="string">ptp</merge>
    <merge key="camera.libgphoto2.name" type="string">USB PTP Class Camera</merge>
    <merge key="camera.libgphoto2.support" type="bool">true</merge>
   </match>
  </match>
  

  
  
  
  
     </match>
  

  Has always exposed the correct PTP interface as "USB PTP Class Camera" device. I can also use iFuse + PTP (thus both interfaces) without errors.

  Additionally for "hal-probe-iphone" I'd make it "hal-probe-iphone.in" and actually honor the install prefix in the script (/usr/bin is hardcoded now).

  Regarding permissions, I guess iFuse must get support for the uid and gid mount options so a device is owned by the right user to be unmounted again and that's it.

• 

  Nikias Bassen June 12th, 2009 @ 12:49 PM

  • no changes were found...

  • 0001-make-automounting-with-pretty-name-work-new.patch 8 KB
• 

  Nikias Bassen June 12th, 2009 @ 12:50 PM

  The match pattern you wrote is like it should be. My (Ubuntu's) libgphoto2 fdi file also has this entry, but also two Apple iPhone entries, which only match against vendor_id and product_id which causes both interfaces to be set as "camera".

  I reworked the patch with your suggestion. I am debugging right now what's going on with the hal mount procedure. What I found out is that hal-storage-mount is called, but without any mount options (except a mount point). For my USB Flash drive, there are options like uid=, umask= etc. However the environment varialbe HAL_METHOD_INVOKED_BY_UID is correctly set to the current desktop user when hal-storage-mount is executed.

  ifuse definitly needs changes for this permission issue.

  WTF is going on with file attachments? They always appear as an empty message...

• 

  Nikias Bassen June 14th, 2009 @ 01:00 AM

  • no changes were found...

  • 0002-Better-option-handling-added-usage-info-uuid-a.patch 4.8 KB
• 

  Nikias Bassen June 14th, 2009 @ 08:57 PM

  Well, it is more complicated than we thought... First thing is, to make hal passing the uid= option to ifuse,
  a gconf scheme /schemas/system/storage/default_options/fuse.ifuse/mount_options is required with a list containing (uid= and allow_other). Second, a code change in hal-storage-mount would be necessary, otherwise an error message pops up "Cannot mount volume" with the details "TODO: have to rethink extra options" instead of passing the options to ifuse.
  After these changes, the automount is working BUT unmount is still not possible, and every attempt with gnome-mount -u -WHATEVER_I_TRIED just fails with a message "According to HAL, the volume is not mounted". This may be due to fuse not working with a device file, but I'm not sure.

  EDIT: I also noticed that the HAL property "volume.is_mounted" is also not set to true when the automount has been done.

  So the problem remains that unmounting is only possible as root, even if the user has access to the mounted file system.

  Attached is a patch that improves the option handling and also has an additional --uuid=UUID option to specifiy the device to use, as well as -o uid=N option which is used to set the ownership of the mount point. This option is also passed to fuse_main.

• 

  Nikias Bassen June 20th, 2009 @ 11:34 PM

  For your information, the libgphoto issue has been fixed in Ubuntu Karmic, and a libgphoto2 update for Ubuntu Jaunty is available via Jonathan's PPA:

  https://edge.launchpad.net/~jonabeck/+archive/ppa

• 

  Martin S. June 21st, 2009 @ 08:08 PM

  • Milestone set to “1.0 Release”

  1. iFuse automounting

  • ifuse.c:408: fuse_opt_add_arg(&args, "-oallow_other"); breaks mounting as user for me as it complains "fusermount: option allow_other only allowed if 'user_allow_other' is set in /etc/fuse.conf". Removing that forced option allows me to mount manually and rw access as a regular user.
  • ntfs-3g appears to set "stbuf->st_uid = context->uid" on get_attr whereas "context->uid" is set from cli...

  2. gfvs-backend-afc

  Regarding mounting, I have updated my branch of gvfs-backend-afc ( http://cgit.sukimashita.com/gvfs-backend-afc.git/ ) to compile with the latest usbmux changes.

  I altered it to use the uuid mechanism now so you can use "afc://uuid" to mount a specific device and browse it.
  Doing "afc://uuid:2" (port 2) mounts the root device tree using the afc2 service.

  GVFS exposes the device as fuse mount under "~/.gvfs/devicename/" for non GVFS access, too.

  The read/write file open/close stuff needs fixing though and crashes the gvfs backend currently but is fixable.

  When the afc volume monitor is finished the device will also automount properly!

• 

  Martin S. July 23rd, 2009 @ 08:58 PM

  Talked to David Zeuthen (creator of HAL and DeviceKit). He also can not really name the issue, but says that HAL creates the mount point directory. Nevertheless he says that in all upcoming distro releases of Ubuntu/openSUSE/Fedora, the automounting will no longer use HAL as DeviceKit-disks will take it's place and the fdi way we have now is a) totally not how it's supposed to be done b) will just no longer work. He welcomes the gvfs-backend-afc though and it will most likely be integrated into gvfs upstream now as the "proper" solution for automounting.

  However, the state of the gvfs-backend-afc is really out of sync with my latest API changes and I'll need to fix it in the coming days (help appreciated). What worked is browsing the device, r/w access failed due to some mutex issues afaik.

• 

  Matt Colyer July 27th, 2009 @ 02:26 AM

  There will be no longer be external mounting without having a custom backend for each situation? This seems like a bit of overkill but if that is what has to be done we can deprecate our awesome FDI once the dusts settles.

  I really wish that they would document stuff like this somewhere.

• 

  Martin S. August 2nd, 2009 @ 06:42 PM

  • State changed from “open” to “resolved”

  As it appears the right way will be to have a gvfs backend for such special protocols. I don't like that it can't be more straightforward and make a simple fuse fs driver work for mount/unmount though.

  Nevertheless, after a coding marathon with Nikias and the help of Bastien Nocera we have got the GVFS AFC backend into a usable state now. The libgpod (with special 3.0 hash support) works fine with it and syncs music.

  The backend automounts any device, works with multiple devices in parallel, supports symlinks, sets the correct icon names with fallbacks and uses the device's name for the desktop icon. Since the issue of the original bug is fixed in libgphoto2 and gvfs-backend-afc is available from the repo below I'd set this bug as resolved.
  http://cgit.sukimashita.com/gvfs-backend-afc.git/

  The backend will now probably be added to the official GVFS module.

  Thanks to all for fixing those evil bugs. :)