I am running Linux Mint 17.1 64-bit (based on Ubuntu 14.04). Ever since upgrading from Linux Mint 14/Ubuntu 12.10, the Python script I use to sync music to my Walkman has stopped working.

Previously, when I mounted my Walkman, it would automatically show up as the path /run/user/1000/gvfs/WALKMAN/Storage Media and would work like any other file system: I could copy tracks to it, delete tracks from it, etc, all through Python. However, I can't remember if I had to make any changes to get this to happen.

Since upgrading to Linux Mint 17 (and now 17.1), when I mount the Walkman, it shows up as the path /run/user/1000/gvfs/mtp:host=%5Busb%3A002%2C007%5D/Storage Media. Furthermore, when I try to run the same file operations, they now fail. I have discovered that this happens not just through Python, but on the command line as well. For example:

david@MILTON:~$ cp '/data/Music/10SecsWhiteNoise.mp3' '/run/user/1000/gvfs/mtp:host=%5Busb%3A002%2C006%5D/Storage Media/MUSIC'
cp: cannot create regular file ‘/run/user/1000/gvfs/mtp:host=%5Busb%3A002%2C006%5D/Storage Media/MUSIC/10SecsWhiteNoise.mp3’: Operation not supported

I have done some research on this problem, but the most common explanation seems to be that it was formerly solved by this PPA: https://launchpad.net/~langdalepl/+archive/ubuntu/gvfs-mtp

But now, Ubuntu versions since 13.10 contain all these changes so it should no longer be necessary. So why am I still having these errors? I am still able to do file operations on my Walkman through a graphical file manager (Caja, on Linux Mint), just not via the command line.


A guess: you are now actually using MTP for accessing your Walkman, and MTP sucks.


The Operation not supported error could indicate that your Walkman uses an MTP implementation that doesn't support "direct" access. According to http://intr.overt.org/blog/?p=174 this kind of direct access is an Android-specific extension, so it's probably not supported by your Walkman.

As result, you can only use a few selected ways to access files on your Walkman using MTP: I guess everything that reads or writes files in one single operation is supported, while access to selected parts of a file is not supported for these MTP implementations. And it appears that cp and Python always use the latter access method and hence fail.

Possible Workaround

However, you might be able to just replace cp by gvfs-copy. In my tests with a Samsung Android phone (which has a crippled MTP implementation as well) gvfs-copy was able to copy files to the phone where cp failed.


I couldn't find much info about these device-dependent MTP limitations; here are some snippets where the situation is explained somewhat:

https://askubuntu.com/a/284831 https://bugs.launchpad.net/ubuntu/+source/gvfs/+bug/1389001/comments/2 https://bugs.launchpad.net/ubuntu/+source/gvfs/+bug/1157583/comments/1

Why did it work before?

As to why your Walkman was accessible with cp in Mint 14 but not in Mint 17, this might be caused by an internal switch from PTP to MTP as access system. At least that's what I noticed for the Samsung device when switching from Ubuntu 12.04 to 14.04. The phone supports both PTP and MTP, but Ubuntu 12.04 apparently only supports PTP; so that's what was used. Since the new Ubuntu version has built-in support for MTP, this is now used instead.

Actually it might even be the case that your Walkman was previously accessed as USB Mass Storage Device, which is what USB hard disks and flash drives use. Maybe for some reason Linux (or your Walkman) decided that MTP was preferable over Mass Storage access.

You can see the access method used by looking at the URL for the Walkman (in Nautilus, go to the Walkman folder, press Ctrl+L and look at the address bar): for MTP the device is found under eg. mtp://[usb:001,004]/ while for PTP it's something like gphoto2://[usb:001,004]/store_00010001. For Mass Storage access the URL is just a normal path like /media/WALKMAN.

I don't know if MTP has any actual advantages over PTP or Mass Storage, or whether it's possible to switch back to PTP or Mass Storage. Under Linux, both MTP and PTP implementations have their own set of bugs, so it might depend on your use case which one is better. AFAIK Mass Storage is the most desirable option for the user but device support in phones is waning.

  • 2
    Thanks for introducing me to gvfs-copy. However, it's a huge bummer it doesn't copy directories recursively. Is there another I can do it recursively? – TuxForLife Sep 8 '15 at 7:42
  • also gvfs-copy does not work for me better than normal cp. And in my case, the same phone worked in the past over MTP. Some phones work and some do not now. All over MTP (as I select MTP connect option in the phone menu). update: found the issue. Was trying to copy from card to phone storage. I had to copy to local filesystem first (e.g. /tmp) then copy to phone storage. Seems like mtp->mtp direct copy does not work (yet). – akostadinov Apr 1 '16 at 21:03

In order to access my cell phone I had to install mtp-server via the Synaptic Package Manager on my Linux Mint 17.1 Mate. My previous Linux Mint 17 Mate didn't require me to install mtp-server, my cell phone was recognized automatically upon connecting via usb port. Maybe this info will help.

  • Do you mean via the command line? As I said, I can still access it via the GUI file manager. – David Pitchford Mar 30 '15 at 1:51
  • Caja answers my needs, so I can't help you with command line. – Scott Mar 31 '15 at 3:26
  • Thank you Scott. Your answer helped me to resolve this error message: Kon 'mtp://[usb:003,029]/' niet weergeven. Fout: The name :1.1813 was not provided by any .service files Kies een andere weergavemethode en probeer het opnieuw. And my Adroid device did not connect through MTP on my Mint 17 installation. Probably after a 17.1 upgrade. apt-get install mtp-server resolved my problem. This is for other searchers with this problem may help them as it helped me. – user110041 Apr 11 '15 at 12:17

I ran into this very problem on Ubuntu 16.04 and Samsung Galaxy SIII connected in MTP mode.

Using Oliver's suggestion to use gvfs-copy, copying directly from my NAS to phone doesn't work: (neither did Nautilus). This is a work-round for a possible bug in gvfs-copy.

gvfs-copy '/run/user/1000/gvfs/smb-share:server=n2100,share=public/Music/The Story of Funk-1.mp2' '/run/user/1000/gvfs/mtp:host=%5Busb%3A001%2C005%5D/Card/Music/Radio/'
Error copying file /run/user/1000/gvfs/smb-share:server=n2100,share=public/Music/The Story of Funk-1.mp2: Operation unsupported

Neither did the alternate path format suggested by the manpage:

gvfs-copy 'smb://n2100/public/Music/The Story of Funk-1.mp2' 'mtp://[usb:001,005]/Card/Music/Radio'
Error copying file smb://n2100/public/Music/The Story of Funk-1.mp2: Operation unsupported

Copying the file to a local folder first however did work. {Thanks akostadinov} (and so did Nautilus).

gvfs-copy '/home/nigel/The Story of Funk-1.mp2' 'mtp://[usb:001,005]/Card/Music/Radio'

On Debian Jessie, gvfs-copy from package gvfs-bin works for me.

$ dpkg -S $(which gvfs-copy)
gvfs-bin: /usr/bin/gvfs-copy
$ dpkg -l gvfs-bin |tail -1
ii  gvfs-bin       1.22.2-1     amd64        userspace virtual filesystem - binaries

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.