[mtp] Cannot open mtp-device

smirky · 2016-01-03 00:16:40

Hello,

I'm facing a very weird issue from more than half an year now with detecting my android device's storage with MTP.
I have the needed packages:

 0 « root » ~ » pacman -Q mtpfs libmtp
mtpfs 1.1-2
libmtp 1.1.10-1

which are also not modified in any way:

 0 « root » ~ » pacman -Qkk mtpfs libmtp
mtpfs: 3 total files, 0 altered files
libmtp: 38 total files, 0 altered files

The problem I face is this:

 0 « root » ~ » mtp-detect 
libmtp version: 1.1.10

Listing raw device(s)
Device 0 (VID=04e8 and PID=6860) is a Samsung Galaxy models (MTP).
   Found 1 device(s):
   Samsung: Galaxy models (MTP) (04e8:6860) @ bus 2, dev 4
Attempting to connect device(s)
ignoring libusb_claim_interface() = -6PTP_ERROR_IO: failed to open session, trying again after resetting USB interface
LIBMTP libusb: Attempt to reset device
inep: usb_get_endpoint_status(): Device or resource busy
outep: usb_get_endpoint_status(): No such device
libusb_open() failed!: No such device
LIBMTP PANIC: Could not init USB on second attempt
Unable to open raw device 0
OK.

I have a laptop, which has an almost identical configuration compared to this system, also using Arch, and is able to detect mtp without problems.
I'm really out of ideas what could be the problem, it's beyond me.

Another example of the problem is shown here through Dolphin in Plasma.
This problem is not occurring on my laptop in Dolphin, it works flawlessly:

I hope someone has an idea what could be the problem. I would gladly provide configurations and other settings to resolve this.

aldyrius · 2016-01-04 14:32:14

I had a similar problem a few weeks ago and fixed by plugging my android into a USB 2.0 port instead of USB 3.0. However, I wasn't trying to use my android on the Arch host; I was just passing it thru to a VM run with qemu. I didn't do much debugging beyond that, but it still may have been an issue with the USB controller that was controlling the 3.0 hub.

If you only have USB 2.0, maybe try a different USB port that would use another controller.

If using another port doesn't help, check the output of

$ dmesg | tail -500 | egrep -i "usb|mtp"

You'll want to look for anything related to the specific controllers in use, the kernel throwing errors in loading USB or MTP-related firmware/drivers/modules, etc.

If when looking at that you aren't sure which one is related to the android device, you can run:

$ sudo journalctl -f

to follow systemd journald's messages in real-time, then unplug and replug your device and watch what comes out. That would help you know what to look for in dmesg a little more.

As an alternative to physically unplugging, you may be able to achieve results with a quick usbreset program as described here: http://cpansearch.perl.org/src/DPAVLIN/ … usbreset.c

Googling for the specific messages in your dmesg or journalctl findings may be best; there are often android development forums that address known mtp concerns as it's a commonly "fussy" protocol.

smirky · 2016-01-04 20:34:41

Hey aldyrius,

Thanks for the reply! I already done a lot of debugging like this. Anyway, a new pair of eyes would probably see something I'm not.
Regarding dmesg, here's what I got:

https://paste.smirky.net/view/raw/56344e33

Regarding journalctl, I made a cut with plugging the device to an USB 2.0 port (yes I was using USB 3.0 before):

https://paste.smirky.net/view/raw/56344e33

I also did a "udevadm monitor" to get some more info:

https://paste.smirky.net/view/raw/c5529642

The first six lines are from the plugging into the USB 2.0 port. The rest of the lines are the result of "mtp-detect".
This is really weird.

aldyrius · 2016-01-04 21:54:29

OK, so something is definitely throwing an error from the libmtp library of functions. However looking at the source, namely libusb1-glue.c, that error is supposedly harmless:

$less -N src/libusb1-glue.c
1750   /*
1751    * It seems like on kernel 2.6.31 if we already have it open on another
1752    * pthread in our app, we'll get an error if we try to claim it again,
1753    * but that error is harmless because our process already claimed the interface
1754    */
1755   usbresult = libusb_claim_interface(device_handle, ptp_usb->interface);
1756
1757   if (usbresult != 0)
1758     fprintf(stderr, "ignoring libusb_claim_interface() = %d", usbresult);

Whether that is actually causing your specific problem I still can't say. Some conjecture here, but it appears that particular error-validating section of libmtp code hasn't had much attention in a while. Even though it claims to be harmless, perhaps something with more recent kernels has caused a break.

Maybe try one of the other MTP supporting packages instead of mtpfs, under the "Functionality" section of the wiki:
https://wiki.archlinux.org/index.php/MTP#Functionality

If one of those fixes it at least we'll know not to trust the libmtp error for this diagnosis.

smirky · 2016-01-04 22:52:40

I went through the list of alternatives to mtpfs and this is what I got:

-> jmtpfs

Failed through USB 2.0 with this: https://paste.smirky.net/view/raw/494fe195
Failed through USB 3.0 with this: https://paste.smirky.net/view/raw/d14e569b

-> go-mtpfs

Failed through USB 3.0 with this: https://paste.smirky.net/view/raw/e17ea004
Same for USB 2.0

-> mtpfs

USB 2.0 with this: https://paste.smirky.net/view/raw/7bb1f181

-> simple-mtpfs

USB 2.0 with this: https://paste.smirky.net/view/raw/afab7cd0

Tried with libmtp-git too and using it's mtp-connect binary. It failed too.

aldyrius · 2016-01-05 00:46:40

Hmm. I'm stumped as well I'd say those error messages all point back to the same source, so we can probably blame libmtp at this point. A few google searches of the error content brought up similar issues across other distros (specifically some Ubuntu users discussing the topic) but nothing concrete. Sorry I can't be of more help!

mezkov · 2018-04-28 20:37:17

Hi,
I've also dealt with this issue. In my case, the problem was that the device was claimed by amarok and it didn't allow any other application to use it. Simply closing amarok and reconnecting the phone solved the issue.

I've found help in this article: https://unix.stackexchange.com/question … usb-device

Use these steps to find, which application uses the device:

$ usb-devices
..
T:   Bus=01 Lev=01 Prnt=01 Port=05 Cnt=01 Dev#= 29 Spd=480 MxCh= 0
D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
P:  Vendor=0b05 ProdID=7772 Rev=03.10
S:  Manufacturer=Android
S:  Product=Android
S:  SerialNumber=GBAXHM00Y2989W5
C:  #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=500mA
I:  If#=0x0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=00 Driver=usbfs
...

Check, if the Driver on last line is usbfs and then take the Bus and Dev# numbers from first line to another command:

$ lsof /dev/bus/usb/001/029
amarok  879 mezkov  114u   CHR 189,28      0t0 46696 /dev/bus/usb/001/029
amarok  879 mezkov  117u   CHR 189,28      0t0 46696 /dev/bus/usb/001/029

WorMzy · 2018-04-28 21:01:35

Thanks for sharing. I'm going to go ahead and close this old topic now.

Arch Linux

#1 2016-01-03 00:16:40

[mtp] Cannot open mtp-device

#2 2016-01-04 14:32:14

Re: [mtp] Cannot open mtp-device

#3 2016-01-04 20:34:41

Re: [mtp] Cannot open mtp-device

#4 2016-01-04 21:54:29

Re: [mtp] Cannot open mtp-device

#5 2016-01-04 22:52:40

Re: [mtp] Cannot open mtp-device

#6 2016-01-05 00:46:40

Re: [mtp] Cannot open mtp-device

#7 2018-04-28 20:37:17

Re: [mtp] Cannot open mtp-device

#8 2018-04-28 21:01:35

Re: [mtp] Cannot open mtp-device

Board footer