gvfs should not attempt to mount MTP devices in an endless loop (cluttering your desktop with messages)

[Oliver Grawert]

trying to use phablet-flash in raring to flash a phone or tablet (or when just running adb shell or adb root from commandline) causes a constant reconnect loop of an attached mtp device. it seems adb and gvfs try concurrently to establish a connection which results in permanent reconnects and a huge amount of mtp popup windows on the desktop PC.

[Sebastien Bacher (seb128)]

Thanks ogra, we have indeed a "known issue" there and not specific to the phablet scripts, our mtp stack doesn't handle "conflicting" access well. That's happening as well with mtp music players where rhythmbox/gvfs conflict in a similar way.

One thing we could do is probably to not automount the devices when plugged (e.g wait for the user to click on the icon), that would be only a workaround though (you would still get issues if you run e.g a music player that detects your device/lists the songs included on it). It would also somewhat be an user experience regression because it would add an extra step for normal users (most users probably don't run the phablet script but rather want to be able to copy files from/to their device)

[Oliver Grawert (ogra)]

so analyzing this a bit deeper, it actually does not have anything to do with adb but with the fact that gvfs assumes that if an USB device registers with:

Product: Android
Manufacturer: Android
(seen in dmesg)

gvfs blindly assumes there is mtp support on the other side ... Ubuntu Touch currently does not ship any mtp support which causes the gvfs mount to fail and to retry over and over (once every 60 seconds).

we should:

a) not make gvfs try to mount at all if we detect an adb connection since then it is clear that we are in developer or flashing mode.
b) probably make gvfs not try to remount at all if it already knows there is no mtp on the responding side
c) at some point ship mtp support on the ubuntu touch images though it has to be researched if this interferes with adb which we require for flashing, debugging and development currently.

[Oliver Grawert (ogra)]

the mtp functionallity seems to be defined in /lib/udev/rules.d/69-libmtp.rules, a quick and hackish workaround for affected people using Ubuntu Touch would be to move this rules file out of /lib/udev/rules.d/ (note that this indeed suppresses all mtp support)

[Philip Langdale (langdalepl)]

The MTP monitor in gvfs looks for usb devices with the IS_MTP flag set in the udev info. This is controlled by the 69-libmtp.rules file, so if Ubuntu Touch devices shouldn't be identified as having MTP, then the appropriate change should be made to the rules file.

There is no conflict between mtp and adb on normal Android devices. I use both all the time.

[Oliver Grawert (ogra)]

The problem here is that the USB Vendor and DeviceID are the same in Ubuntu Touch and in android (we use the same kernel so the device identifies itself the same way). Unlike android Ubuntu Touch doesn't ship and MTP userspace bits which makes the mount fail. I would expect gvfs to notice that and not try again as long as there was no reconnect but instead it fires a new mount attempt every minute (resulting in a new error popup).

gvfs should definitely not try mounting over and over once it knows there is no way to mount as long as there was no physical reconnect. We can't just rip out the device IDs from the rules file as this would break all devices of the same model using android here. Thenaks for the info that MTP does not interfere with adb, so in case we decide we will use it (this is not clear yet, we might decide to just connect as USB mass storage for more convenient device access) it would go away.

I still think teh behavior is a bug though. Can gvfs be told to not attempt constant mounting in a loop please ? An USB ID is not enough to identify if the MTP protocol is supported or not. A single mount attempt should be enough to notice if there is userspace support.

[Philip Langdale (langdalepl)]

So, after some research:

1) gvfs is not responsible for automounting. It emits events when devices appear and responds to requests to mount devices. As such, gvfs is not responsible for deciding whether to give up on mount attempts or not.

2) Instead, I believe the heavy lifting is done by gnome-settings-daemon.

3) It respects a config key at /org/gnome/desktop/media-handling/automount. If this key is set to false, then no attempts will be made to auto-mount devices.

So, it seems you have a few options.

A) Note that the libmtp detect rule which catches android devices is not based on ID. It runs a program called mtp-probe that checks the USB interfaces exposed by the device. I feel certain that you can configure the USB interfaces published by the device to exclude MTP if you don't support it. Normal android devices must be able to do this if they use UMS instead of MTP.

B) You can turn off automounting if you're just worried about your development workflow.

C) You can file a g-s-d bug and ask them to implement some sort of back-off failure handling policy.

Thanks!

[Pat McGowan (pat-mcgowan)]

The workaround I am using:

Add this rule to /lib/udev/rules.d/69-libmtp.rules

#skip Nexus 4/10 for UT debug
ATTR{idVendor}=="18d1", ATTR{idProduct}=="4ee2", GOTO="libmtp_rules_end"

Add a new file to /etc/udev/rules.d called 99-android.rules
# enable access to nexus devices
SUBSYSTEM=="usb", ATTR{idVendor}=="18d1", ATTR{idProduct}=="4ee2", MODE="0666"

The usb devices get mode 0664 by default so adb will require root without this.

sudo udevadm control --reload-rules
sudo service udev restart

[Alan Pope 🍺🐧🐱 🦄 (popey)]

The Nexus 7 is device 4e42, so you'd probably want to add an additional line to both those files if you're using a Nexus 7 for Ubuntu Touch too.

[Alan Pope 🍺🐧🐱 🦄 (popey)]

Strangely my Nexus 7 is now 18d1:d002 so had to add that too.

[Dario Bertini (berdario)]

I have a related problem: my Nexus S doesn't actually expose MTP, and so gvfs pops up an error dialog each time I plug it in

I checked, and this seems to have been already fixed upstream: (4e21 is the wrong id... 4e25 apparently is fine)
http://sourceforge.net/p/libmtp/code/ci/master/tree/src/music-players.h

If current devices truly have a different id when they have MTP enabled or not, I think that Ubuntu on phablet should just be a good citizen, and change it as well

[Sergio Schvezov (sergiusens)]

I see this problem the instant I turn my manta device on while plugged in (android or ubuntu touch)

[LantzR (lantzr)]

This appears to be what is happening when I connect my iPhone to Trusty now. I did not have this issue in Saucy. gvfs is crashing and I get the loop of messages. I am going to try to get the dump in here an xRef it.

[Darren (darreng1205)]

Has their been any progress on this? It's now 2 years later and the same android connection loop is still occuring. The workaround has also stopped working.

[Darren (darreng1205)]

The workaround is now working. Had to switch USB ports and reload the workaround to fix the issue. However is there a long term solution to this issue that I am missing, or is being worked on?

[Pat McGowan (pat-mcgowan)]

Ubuntu phones have had MTP support for some time so that original instance of the bug is no longer a problem
I no longer have the rules workarounds, this has been fine for me on both vivid and wily.
Which ubuntu version and what are you plugging in?

[Darren (darreng1205)]

Ubuntu 14.04, and Nexus 5X. This might not be the exact bug that I am experiencing. My phone continuously remounts and opens the file manager to the phone storage.

[Darren (darreng1205)]

The workaround seems to work intermittently, but is no longer functioning even after trying all USB ports.

[Pat McGowan (pat-mcgowan)]

The original bug was that it was repeatedly popping up the error dialog saying it could not mount it. In this case it is mounting it successfully but for some reason is remounting it, as if you lost connection.

If you watch the syslog you may see if it actually sees the connection dropping and reconnecting. Dumb question but have you tried a different cable.

[Darren (darreng1205)]

The same issue happens with other cables when mounting phones(have tried 3 different phones so far), but a webcam doesn't seem to have any issues. I looked at the syslog, and saw this pattern repeated over and over.

Device added: sysfs-LGE-Nexus_5X
Dec 10 11:56:33 colord: Device added: sysfs-(null)
Dec 10 11:56:48 kernel: [ 1368.674491] usb 1-3: USB disconnect, device number 116
Dec 10 11:56:48 colord: device removed: sysfs-(null)
Dec 10 11:56:48 colord: device removed: sysfs-(null)
Dec 10 11:56:48 colord: device removed: sysfs-LGE-Nexus_5X
Dec 10 11:56:48 kernel: [ 1368.945261] usb 1-3: new high-speed USB device number 117 using xhci_hcd
Dec 10 11:56:48 [ 1369.132080] usb 1-3: New USB device found, idVendor=18d1, idProduct=4ee2
Dec 10 11:56:48 kernel: [ 1369.132086] usb 1-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Dec 10 11:56:48 kernel: [ 1369.132089] usb 1-3: Product: Nexus 5X
Dec 10 11:56:48 kernel: [ 1369.132091] usb 1-3: Manufacturer: LGE
Dec 10 11:56:48 kernel: [ 1369.132093] usb 1-3: SerialNumber: ########
Dec 10 11:56:48 colord: Device added: sysfs-LGE-Nexus_5X
Dec 10 11:56:48 colord: Device added: sysfs-(null)
Dec 10 11:56:52 kernel: [ 1373.292430] usb 1-3: USB disconnect, device number 117
Dec 10 11:56:52 colord: device removed: sysfs-(null)
Dec 10 11:56:52 colord: device removed: sysfs-(null)
Dec 10 11:56:52 device removed: sysfs-LGE-Nexus_5X
Dec 10 11:56:52 kernel: [ 1373.562714] usb 1-3: new high-speed USB device number 118 using xhci_hcd
Dec 10 11:56:53 kernel: [ 1373.730609] usb 1-3: Device not responding to setup address.
Dec 10 11:56:53 kernel: [ 1373.934517] usb 1-3: Device not responding to setup address.
Dec 10 11:56:53 kernel: [ 1374.138410] usb 1-3: device not accepting address 118, error -71
Dec 10 11:56:53 kernel: [ 1374.434224] usb 1-3: new high-speed USB device number 120 using xhci_hcd
Dec 10 11:56:54 kernel: [ 1374.624811] usb 1-3: New USB device found, idVendor=18d1, idProduct=4ee2
Dec 10 11:56:54 kernel: [ 1374.624815] usb 1-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Dec 10 11:56:54 kernel: [ 1374.624816] usb 1-3: Product: Nexus 5X
Dec 10 11:56:54 kernel: [ 1374.624818] usb 1-3: Manufacturer: LGE
Dec 10 11:56:54 kernel: [ 1374.624819] usb 1-3: SerialNumber: ######
Dec 10 11:56:54 colord: Device added: sysfs-LGE-Nexus_5X
Dec 10 11:56:54 colord: Device added: sysfs-(null)
Dec 10 11:56:54 colord: device removed: sysfs-(null)
Dec 10 11:56:54 kernel: [ 1375.464027] usb 1-3: USB disconnect, device number 120
Dec 10 11:56:54 colord: device removed: sysfs-(null)
Dec 10 11:56:54 colord: device removed: sysfs-LGE-Nexus_5X

[Pat McGowan (pat-mcgowan)]

then definitely not the same bug, you may want to submit a new bug against the kernel although its not clear to me its not hardware related

I see other similar reports where people have resolved by unplugging devices and shutting down the PC, modprobe the usb driver, etc but no idea

[Joseph Salisbury (jsalisbury)]

@Darren, can you open a bug against the kernel? That will provide a way to track this issue and review your hardware and configuration.

I can investigate this issue using that bug report. You can open a bug by running the following from a terminal:

ubuntu-bug linux

[Darren (darreng1205)]

Also just tried on liveUSB, and the same issue occurs.

[Darren (darreng1205)]

It could be a hardware issue, but I ran that command and received the following message:
"The problem cannot be reported:

This is not an official Ubuntu package. Please remove any third party package and try again."

Not sure what is going on.

[Joseph Salisbury (jsalisbury)]

@Darren, can you run uname -a from a terminal and post the output? It sounds like you may be running an unsupported kernel.

[Darren (darreng1205)]

Linux darren-######(removed) 3.19.0-39-generic #44~14.04.1-Ubuntu SMP Wed Dec 2 10:00:35 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

[Joseph Salisbury (jsalisbury)]

That looks okay, so it may be something else causing ubuntu-bug to fail. Can you just open a bug using the Launchpad web interface, then I can post in that bug how to collect the appropriate data.

You can open a bug by going to:
https://launchpad.net/ubuntu/+source/linux

Then click "Report a bug"

Thanks

[Darren (darreng1205)]

It must have been a physical issue, replaced the cord and updated the computer and the error seems to no longer occur. Thank you all for the assistance.