UPDATE [2013/01/08]: As of the recent Galaxy S III update to Jelly Bean (Android 4.1), most of the text below is obsolete. The connect-within-3-seconds limitation appears to no longer exist, and you can connect to and disconnect from the phone multiple times without unplugging and replugging it. I’ve tested mtpfs, go-mtpfs, and simple-mtpfs with my Galaxy S III with Jelly Bean, and all seem to work fine. I’m leaving the text below for historical purposes, and for people with S III’s that don’t have Jelly Bean yet for whatever reason.
Here’s what I’ve learned about using my Samsung Galaxy S III with Linux (GNOME and the command-line in particular, but some of this may be applicable to KDE and other desktops).
If you plug your Galaxy S III into your Linux box, it’ll probably mount the phone and ask you whether you want to browse or eject it. At least, that’s what it does on my Fedora 17 box running GNOME, and the odds are it’ll do something similar for you.
If you leave it mounted, you’ll probably be able to browse its files, and you may even be able to transfer some files to it via drag-and-drop. However:
- If you eject it, you probably won’t be able to mount it again unless you unplug it and plug it back in.
- GNOME may not be able to mount it properly if the screen is locked when you plug it in.
- If you try to copy a large number of files, you could run into memory issues (see bug 840547 in Red Hat’s bugzilla database). Once that happens, again, you probably won’t be able to do anything else until you replug the phone.
- You won’t be able to get anything aside from the GNOME desktop to access the device successfully, because GNOME will monopolize it.
- If you’re clever enough to kill or uninstall gvfs-gphoto2 and switch the phone to MTP mode (it is set to use PTP mode when it ships) so you can use a tool like Rhythmbox, Gnomad2, or mtpfs, you may find that the tool you’re trying to use hangs and eventually gives up when trying to connect to the device.
- If you do manage to get mtpfs to connect, you may find that it doesn’t display all the files on the device (see bug 841260 in Red Hat’s bugzilla database).
- If you do manage to get some app to connect to the phone, you may find that initializing the connection takes a long time.
- You may find that certain files mysteriously fail to copy to the phone despite repeated attempts.
Here’s why all this is going on:
- The PC needs to connect to the phone within 2 or at most 3 seconds after it is plugged in, or the phone goes “numb” and won’t accept a connection.
- Android sometimes prevents phones from being mounted when they are locked, so that mounting the phone can’t be used as a backdoor into its contents.
- I’m not certain, but I believe once the PC has successfully connected to the phone and then disconnected from it, you can’t connect to it again without replugging it. You might be able to connect to it again if you do it within a couple of seconds of when the previous app disconnected, but I’m not sure about that, and in any case the timing is extremely tricky.
- That means that even if you tell GNOME to eject the phone after it mounts it automatically, you won’t be able to connect it to another application.
- Mtpfs is apparently buggy.
- In some cases, libmtp, the library most apps use to connect to the phone, reads the metadata for all files on the phone when it first connects. Therefore, if you have a lot of files, e.g., a large music library, on the phone, the connection could take a long time to initialize.
- I stumbled across a bug which prevents files that are 3,680,252 bytes long, and I suspect files of other lengths as well (thought I haven’t found any yet), from copying successfully to the phone. This is a bug in the phone itself, not a bug in any of the software talking to it. See this Android bug I filed about it.
Therefore, here’s what I’m doing to access my S III from Linux:
- For small stuff, I just let GNOME do its thing — plug the phone in, let GNOME mount it, and access the files on it normally.
- Note, however, that the first time I plugged in the phone, I had to switch it from PTP mode to MTP mode. To do that, I dragged down the top of the screen after plugging it in, tapped on “Connected as a camera”, changed the setting from PTP to MTP, unplugged the phone, and plugged it back in. (I don’t know how to access this setting when the phone isn’t plugged in; I couldn’t find it anywhere in the Settings app.)
- For large stuff, I’m using go-mtpfs, which requires installing the Go tools to compile it.
- When I need to mount the phone with go-mtpfs, I do the following:
- Kill my gvfs-gphoto2-volume-monitor process.
- Prepare the go-mtfps command in a terminal window but don’t hit Enter.
- Make sure the phone is unlocked and plug it in.
- As soon as the phone chimes to indicate it’s plugged in, hit Enter in the window with the go-mtpfs command in it.
- Run “fusermount -u <mountpoint>” to unmount the phone when I’m done using it.
- Log out of GNOME and log back in to reset gvfs-gphoto2 (I can’t figure out how to start it back up properly by hand).
- If I run into a file I can’t copy to the phone because of the aforementioned bug that causes files of certain lengths to be uncopyable, I change its length, e.g., by adding an extra null character to the end of an MP3, and try the copy again.
Some caveats about go-mtpfs I should mention:
- It can’t copy zero-length files to the phone. This is a limitation of the MTP protocol, not go-mtpfs’s fault.
- It does not preserve modification times properly on files (see this issue on Github). If you use “touch”, or “rsync”, or whatever, to set the modification time on a file while the phone is mounted, and then do “ls -l” on the file, it will appear that the modification time was set, but when you unmount and remount the phone, it’ll revert to the time at which it was last touched. This is also apparently a limitation in the MTP protocol.
This means that if you, e.g., want to keep your music collection synchronized with a tool like rsync, you need to tell your tool to ignore file timestamps and only pay attention to file sizes (e.g., with “–size-only” to rsync). However, that’s only safe for immutable files, so if the files you’re synchronizing change without changing names and sizes, you’ll have to recopy the whole hierarchy every time (ugh!).