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!).
It is impossible to transfer pictures from a Samsung Galaxy S3 to Centos 6 Linux. MTP mode doesn’t work on RHEL6-derived systems; and PTP mode is problematic and only one way even in the rare occasions that it works. This is too bad but you have to swtich to a different operating system if you own a Samsung Galaxy S3.
We have been fighting this mtpfs issue on the Centos forums and on the gmane Centos group “gmane.linux.centos.general”. One solution that seems to work for the Samsung Galaxy SIII on Centos 6 is to switch the phone into PTP mode. Then mtpfs is not needed, yet, you can still transfer files between the Android 4.x smartphone & the Centos PC via USB cable. Details are critical, but the summary is:
0. Connect the phone once by cable to see the menu to switch from MTP mode to PTP mode and disconnect the phone
1. Reboot the Centos PC & reconnect the phone by USB cable
2. Centos should recognize the phone as a camera
3. The file system browser should pop up and you can then transfer files
Details here:
http://www.centos.org/modules/newbb/viewtopic.php?topic_id=39977&forum=57
PTP has its own problems.
Is there any Android phone, which you can use properly without tinkering with Linux? Is it only Samsung (Galaxy S III), which have those problems? Do I get same problems, if I change to another device, say HTC or Sony or some other?
Or do I need to downgrade back to my old faithful Nokia/Symbian?
As noted in the update at the top of this posting, the S III seems to work fine with Linux with its most recent software update.
I can’t comment on which other Android phones work better or worse with Linux, since the S III is the only one I use.
What about the verizon version of SIII? In Jelly Bean, it only shows the windows drivers! Any solution?
I don’t understand your question. I use the SIII on Verizon and the instructions above are accurate for me. When you plug your phone into your computer, an ongoing notification will pop up telling you what kind of device you are connected as. You can open that notification to switch from MTP to PTP or vice versa.
Pingback: SGS3 – next… | Dmitry-Bond
You don’t need to kill gvfs2-gphoto-volume-monitor, you can disable it.
You must modify the libgphoto2 udev rule (it’s a file named XX-libgphoto2-2.rules where XX is a number and it’s in /usr/lib/udev/rules.d/ or /lib/udev/rules.d/ according to the distro you’re using and the version of udev) by adding:
ATTRS{idVendor}==”XXXX”, ATTRS{idProduct}==”YYYY”, GOTO=”libgphoto2_usb_end”
before
ENV{ID_USB_INTERFACES}==”*:060101:*”, ENV{ID_GPHOTO2}=”1″, ENV{GPHOTO2_DRIVER}=”PTP”, GOTO=”libgphoto2_usb_end”
where XXXX and YYYY are the product and vendor ids you can read with lsusb. This works for all MTP devices, you just need to use the correct vendorid and productid.
To enable the modified rule you can run udevadm control –reload and kill and restart all gvfs processes, or more simply, reboot the machine.
Useful if you want to prevent Nautilus from ever connecting to your phone, but sometimes I actually want to use Nautilus to access the phone. In that case, it’s easier just to kill gvfs2-gphoto-volume-monitor when I want to use the external tool, and then log out and log back in afterward to reset it when I’m done.
You can use SSHDroid – no root required.
Thanks fro the tip – just tried SSHDroid – works but is too slow. It took about 20 secs to copy 1 mp3. I want to copy about 10G worth.
You are going to run into two performance problems with SSHDroid that you won’t run into with go-mtpfs:
For these reasons, go-mtpfs will probably be faster than SSHDroid, assuming you can get go-mtpfs to work.
SSHDroid isn’t particularly useful for file synchronization. Rsync sort of works over sshfs, but it seems to work somewhat better over go-mtpfs. I suppose SSHDroid would be useful for copying a few files over to the device, but I don’t think it’s a good choice for synchronizing a lot of data.
Can you give an example of the go-mtpfs comand you use, and the output you get?
I get the following
lawrie@lawrie:~/Downloads$ ./go-mtpfs.x86_64 ../mnt_mtp &
[1] 15993
lawrie@lawrie:~/Downloads$ Device 0 (VID=04e8 and PID=6860) is a Samsung GT-P7310/P7510/N7000/I9100/Galaxy Tab 7.7/10.1/S2/Nexus/Note.
2012/08/01 22:11:58 device Samsung: GT-P7310/P7510/N7000/I9100/Galaxy Tab 7.7/10.1/S2/Nexus/Note (04e8:6860) @ bus 2, dev 7
:
lawrie@lawrie:~/Downloads$ ls ../mnt_mtp/
lawrie@lawrie:~/Downloads$
This is what you should see if (a) you run go-mtpfs fast enough, i.e., within a couple seconds after plugging in the phone, and (b) nothing else, e.g., gvfs-gphoto2-volume-monitor, starts talking to the phone before you run go-mtpfs:
The fact that you’re missing the last three lines means that either (a) or (b) above is not true.
Thanks for that – working now. Seems I just wasn’t fast enough. I still had some permissions issues with fuse configuration but they were easy to fix. Opened up Dolphin under Kubuntu and copied a whole CD worth of mp3s in a few seconds. Beautiful!
Thanks for your help. I also had trouble. My solution is to just use SSH.
1. Root the phone (really easy).
2. Install QuickSSHd.
3. Copy over your public key.
4. Give the phone a reserved (“static”) DHCP address and DNS entry for convenience.
5. Use scp/sftp.
I don’t think the US Verizon Wireless version of the SIII has been rooted yet. At least I couldn’t find instructions for rooting it last week when I looked.