Bug 387454 - MTP doesn't work in KDE with Linux 4.14
Summary: MTP doesn't work in KDE with Linux 4.14
Status: RESOLVED UPSTREAM
Alias: None
Product: frameworks-solid
Classification: Unclassified
Component: general (show other bugs)
Version: 5.48.0
Platform: Archlinux Packages Linux
: NOR major
Target Milestone: ---
Assignee: Lukáš Tinkl
URL: https://github.com/systemd/systemd/is...
Keywords:
: 388347 395130 (view as bug list)
Depends on:
Blocks:
 
Reported: 2017-11-30 00:44 UTC by emg81
Modified: 2019-04-04 20:37 UTC (History)
37 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
mtp-detect log (27.26 KB, text/plain)
2017-11-30 00:44 UTC, emg81
Details
udevadm monitor log (10.64 KB, text/plain)
2017-11-30 00:45 UTC, emg81
Details
diff of /sys betweeen 4.11 and 4.14 (16.20 KB, patch)
2017-12-02 11:03 UTC, Davide Gianforte
Details
udevadm (23.25 KB, text/plain)
2018-01-28 21:25 UTC, Nille
Details
Hacked a patch together to have udev ignore bind/unbind events when handling rules (651 bytes, patch)
2018-04-25 19:36 UTC, Stephan Wezel
Details

Note You need to log in before you can comment on or make changes to this bug.
Description emg81 2017-11-30 00:44:56 UTC
Created attachment 109123 [details]
mtp-detect log

Brief description: after upgrading to Linux kernel 4.14 I cannot access my android device anymore via MTP using KDE.

When I click on KDE's popup - I get message "The file or folder udi=/org/kde/solid/udev/sys/devices/pci0000:00/0000:00:14.0/usb3/3-1 does not exist".

It happens only with combination of:
- 4.14 kernel;
- KDE. 

When I switch back to kernel 4.13, I can mount device again.

I also can access device via MTP with mtpfs command OR by using LXDE (and its default file manager and desktop) without any problems on the same system with kernel 4.14.

So it looks like issue is purely related to KDE *and* Linux 4.14 "conflict".

What I tried:
- recompiled kernel,
- tried vanilla-sources,
- checked every new kernel option that was set during "make oldconfig",
- recompiled kde-frameworks/solid-5.40.0, media-libs/libmtp-1.1.14 and sys-fs/mtpfs-1.1-r3,
- recompiled all packages ("@world" in Gentoo)
but no success so far. 

Also, there are people at manjaro forums complaining about the same issue:
https://forum.manjaro.org/t/is-it-worth-upgrading-to-4-14-lts/35620/16
https://forum.manjaro.org/t/is-it-worth-upgrading-to-4-14-lts/35620/26
Comment 1 emg81 2017-11-30 00:45:58 UTC
Created attachment 109124 [details]
udevadm monitor log
Comment 2 weltqgel 2017-12-01 20:25:21 UTC
I can confirm this behaviour under Manjaro stable. the package Android File Transfer works, accessing the device through Dolphin/Plasma does not work.

inxi -Fx

System:    Host: manjamin-pc Kernel: 4.14.2-1-MANJARO x86_64 bits: 64 gcc: 7.2.0
           Desktop: KDE Plasma 5.11.3 (Qt 5.9.2) Distro: Manjaro Linux
Machine:   Device: desktop Mobo: ASUSTeK model: Q170T v: Rev X.0x serial: N/A
           UEFI: American Megatrends v: 0215 date: 04/18/2016
CPU:       Quad core Intel Core i5-6500TE (-MCP-) arch: Skylake-S rev.3 cache: 6144 KB
           flags: (lm nx sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx) bmips: 18436
           clock speeds: max: 3300 MHz 1: 2300 MHz 2: 2300 MHz 3: 2300 MHz 4: 2300 MHz
Graphics:  Card: Intel HD Graphics 530 bus-ID: 00:02.0
           Display Server: x11 (X.Org 1.19.5 ) driver: intel Resolution: 1920x1080@50.00hz
           OpenGL: renderer: Mesa DRI Intel HD Graphics 530 (Skylake GT2)
           version: 4.5 Mesa 17.2.5 Direct Render: Yes
Audio:     Card Intel Sunrise Point-H HD Audio driver: snd_hda_intel bus-ID: 00:1f.3
           Sound: Advanced Linux Sound Architecture v: k4.14.2-1-MANJARO
Network:   Card-1: Intel Ethernet Connection (2) I219-LM
           driver: e1000e v: 3.2.6-k bus-ID: 00:1f.6
           IF: enp0s31f6 state: up speed: 100 Mbps duplex: full mac: 34:97:f6:8b:e1:a6
           Card-2: Intel Wireless 7265 driver: iwlwifi bus-ID: 02:00.0
           IF: wlp2s0 state: up mac: 60:57:18:73:95:5b
           Card-3: Realtek RTL8111/8168/8411 PCIE Gigabit Ethernet Controller
           driver: r8168 v: 8.044.02-NAPI port: e000 bus-ID: 04:00.0
           IF: enp4s0 state: down mac: 34:97:f6:8b:e1:a7
Drives:    HDD Total Size: 3756.7GB (74.2% used)
           ID-1: /dev/nvme0n1 model: SAMSUNG_MZVPV256HDGL size: 256.1GB
           ID-2: /dev/sda model: Samsung_SSD_850 size: 500.1GB
           ID-3: USB /dev/sdb model: Elements_25A2 size: 1000.2GB
           ID-4: USB /dev/sdc model: USB_2.0_Drive size: 1000.2GB
           ID-5: USB /dev/sdd model: Elements_10B8 size: 1000.2GB
Partition: ID-1: / size: 39G used: 23G (62%) fs: ext4 dev: /dev/nvme0n1p3
           ID-2: /home size: 119G used: 57G (51%) fs: ext4 dev: /dev/nvme0n1p5
Sensors:   System Temperatures: cpu: 73.0C mobo: 29.8C
           Fan Speeds (in rpm): cpu: 0
Info:      Processes: 225 Uptime: 1:37 Memory: 2773.6/15926.0MB Init: systemd Gcc sys: 7.2.0
           Client: Shell (bash 4.4.121) inxi: 2.3.43
Comment 3 Davide Gianforte 2017-12-02 11:03:02 UTC
Created attachment 109171 [details]
diff of /sys betweeen 4.11 and 4.14

I have a Slackware-based self compiled system, and I'm affected by the same issue.

I have lurked the /sys filesystem, and I've found that the 4.14 device tree is "missing" a symlink to the usbfs (see attachment al line 109). I don't know how to check that solid or mtp do really use that file.

Obviously, I wasn't able to create that symlink on 4.14 to see if it solves the issue neither delete it from 4.11.

I'm available to do any test.
Comment 4 weltqgel 2017-12-03 21:29:46 UTC
Problem pertains with Plasma 5.14.4 and Kernel 4.14.3. No problems when using last LTS Kernel (4.9.66).
Last kernel version where it functioned was EOL 4.13 series.
Comment 5 emg81 2017-12-15 15:10:59 UTC
KDE Apps 17.12, Linux 4.14.6, Solid 5.41 - still doesn't work with same error.
Comment 6 weltqgel 2017-12-18 10:50:37 UTC
Hey! Now it works for me with the following configuration:
Plasma 5.11.4, Kernel 4.14.5.1-MANJARO, Qt 5.9.3, Frameworks 5.40.0. 

If there is anything that I can provide to elucidate the issue further, let me know.
Comment 7 sydney 2018-01-01 17:42:27 UTC
Doesn't work with the following configuration :
Plasma 5.11.4, Kernel 4.14.10-2-MANJARO, Qt 5.10.0 , Frameworks 5.41.0
Comment 8 Antonio Rojas 2018-01-06 10:46:05 UTC
*** Bug 388347 has been marked as a duplicate of this bug. ***
Comment 9 Markus 2018-01-07 21:39:43 UTC
Same issue here. Slackware Linux 14.2/-current with KDE 5.41.0 / Plasma 5.11.4. With Linux-4.14.12 i can not mount my mobile phone using mtp:/. Switching back to LTS-4.4.110 and everything is fine.
Comment 10 Nille 2018-01-28 21:25:41 UTC
Created attachment 110188 [details]
udevadm

udevadmin monitor -p
Comment 11 Nille 2018-01-28 21:28:51 UTC
I got this in Slackware64-current(15.0) KDE4.14.XX
I read this thread and saw gentoo and slackware and it made me think that it might be eudev related.
Is it so that all of us that has this problem use eudev?
There was weltqgel that used systemd but since it was fixed later it might not have been the same problem it could as well have been the gvfs udev problem that appeared almost the same time.

The error message, first is original in my native tongue and the second is translated by me.
Filen eller katalogen udi=/org/kde/solid/udev/sys/devices/pci0000:00/0000:00:10.0/usb3/3-2/ finns inte.
File or catalog udi=/org/kde/solid/udev/sys/devices/pci0000:00/0000:00:10.0/usb3/3-2/ doesn't exist.

It does work for me in xfce if i use pcmanfm or in KDE if i use thunar to open the mtp device.

I did try and bisect the kernel and got this result.
git bisect bad                 1455cf8dbfd06aa7651dcfccbadb7a093944ca65 is the first bad commit
commit 1455cf8dbfd06aa7651dcfccbadb7a093944ca65
Author: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Date:   Wed Jul 19 17:24:30 2017 -0700

    driver core: emit uevents when device is bound to a driver
    
    There are certain touch controllers that may come up in either normal
    (application) or boot mode, depending on whether firmware/configuration is
    corrupted when they are powered on. In boot mode the kernel does not create
    input device instance (because it does not necessarily know the
    characteristics of the input device in question).
    
    Another number of controllers does not store firmware in a non-volatile
    memory, and they similarly need to have firmware loaded before input device
    instance is created. There are also other types of devices with similar
    behavior.
    
    There is a desire to be able to trigger firmware loading via udev, but it
    has to happen only when driver is bound to a physical device (i2c or spi).
    These udev actions can not use ADD events, as those happen too early, so we
    are introducing BIND and UNBIND events that are emitted at the right
    moment.
    
    Also, many drivers create additional driver-specific device attributes
    when binding to the device, to provide userspace with additional controls.
    The new events allow userspace to adjust these driver-specific attributes
    without worrying that they are not there yet.
    
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

:040000 040000 fef96678b0a5ea8f89c41f006a3ccd013b4a36f4 34b72074bd6fab60bea1ec8066cf5ae9c600b37c M    drivers
:040000 040000 5657f6e76558ed4e14f17edabc6c602b93011d6d 1dbac2e41568c1638ea059fc8bc1afe8878353b8 M    include
:040000 040000 88854205d5255fbec438594cb3539e01c3610f82 54ad1fcb19ca64af9660e170ae0d7af186bd51ad M    lib
Comment 12 Martin Doucha 2018-02-07 16:00:24 UTC
(In reply to Nille from comment #11)
> I got this in Slackware64-current(15.0) KDE4.14.XX
> I read this thread and saw gentoo and slackware and it made me think that it
> might be eudev related.
> Is it so that all of us that has this problem use eudev?

I have the same problem on Gentoo and I'm not using eudev. I have udev-236-r1.

Kernel 4.15.1, Qt 5.9.4, KDE Frameworks 5.42.0, KDE Apps 17.12.1
Comment 13 Paolo Pedroni 2018-02-07 16:44:03 UTC
(In reply to Nille from comment #11)
> I got this in Slackware64-current(15.0) KDE4.14.XX
> I read this thread and saw gentoo and slackware and it made me think that it
> might be eudev related.
> Is it so that all of us that has this problem use eudev?

Nope, using Gentoo with systemd-236, kernel 4.14.14, KDE Frameworks 5.42.0 and KDE Apps 17.12.1
Comment 14 Paolo Pedroni 2018-02-12 16:07:16 UTC
Still failing with kernel 4.14.18 and KDE frameworks 5.43.0
Comment 15 ml 2018-02-25 19:21:18 UTC
Broken with kernel-4.15.4, kde-frameworks-5.43, kdeapps-17.12.2
Comment 16 Stephan Karacson 2018-03-03 13:37:59 UTC
I can confirm this behaviour. breaks with same error.
Broken on Gentoo (gentoo-sources-4.15.4, kde-frameworks/plasma-5.40.0, kde-apps/kde-apps-meta-17.08.3, kde-apps/dolphin-17.08.3, kde-frameworks/kio-5.40.0-r3)

Installing and using xfce-base/thunar-1.6.13 is a successful workaround.
Comment 17 Max 2018-04-06 07:02:07 UTC
I can confirm the error too.
Gentoo (gentoo-sources-4.14.29, kde-frameworks/plasma-5.44.0, kde-apps/dolphin-17.12.3, kde-frameworks/kio-5.44.0, media-libs/libmtp-1.1.15, sys-fs/mtpfs-1.1-r3)
Comment 18 Max 2018-04-21 23:51:15 UTC
Issue still exists with Kde-apps 18.04.0, kde-frameworks 5.45, gentoo-sources-4.14.43
Comment 19 Max 2018-04-22 08:09:41 UTC
I've fixed for myself. 
There weren't udev rules for Xiaomi in my Gentoo. 
Updating /etc/udev/rules.d/51-android.rules [I added 'SUBSYSTEM=="usb", ATTR{idVendor}=="2717", MODE="0666"] and /etc/udev/rules.d/69-libmtp.rules [ATTR{idVendor}=="2717", ATTR{idProduct}=="ff40", SYMLINK+="libmtp-%k", ENV{ID_MTP_DEVICE}="1", ENV{ID_MEDIA_PLAYER}="1"] was enough to resolve problem
Comment 20 Stephan Wezel 2018-04-22 17:57:38 UTC
I found a different solution.
It seems the udev rules for libmtp are broken with linux kernel 4.14+

No /dev/libmtp-* symlink is generated since then

The first rule in the rules file (on my gentoo machine this is /lib64/udev/rules/69-libmtp.rules with libmtp 1.1.14 installed)
ACTION!="add", GOTO="libmtp_rules_end"

It seems that since linux kernel while the udev add action is active not all attributes (e.g. idvendor) are already setup

The attributes seems to be all setup up in the bind udev action phase

So after I copied the file to /etc/udev/rules and changed the line
ACTION!="add", GOTO="libmtp_rules_end"

to 
ACTION!="bind", GOTO="libmtp_rules_end"

The symlink gets generated and I can access the storage on my smartphone again with dolphin
Comment 21 Nate Graham 2018-04-22 22:04:56 UTC
So is this an issue with the Kernel, then?
Comment 22 Stephan Wezel 2018-04-23 06:41:22 UTC
I quess not that is a kernel error.
As stated in comment 11 the kernel (4.14+) now sends bind uvents when the driver gets bound to a physical device.
It seems that the add uvents are now send earlier then before this change (when the device get plugged in). Before any device specific properties/attributes could be read.

Before my change the /dev/libmtp* symlink was created when i ran

udevadm test <path to usb device under dev>

after the device was plugged in.

The question is why can pcmanfm access the mtp device and dolphin (via solid) not.
Does Solid depend on the /dev/libmtp* symlink? Or which information are needed to mark an usb device as mtp device by solid?
Maybe solid depends on following two udev env variables?
ENV{ID_MTP_DEVICE}="1"
ENV{ID_MEDIA_PLAYER}="1"

Those ENV vars get setup by the libmtp udev rules, which also setup the /dev/libmtp* symlink.

Maybe pcmanfm doesn't depend on udev properties to access/mark a device as mtp device. It could directly query libmtp for available devices. And libmtp reports it correctly after the device was plugged in.
Comment 23 Paolo Pedroni 2018-04-23 13:17:13 UTC
(In reply to Stephan Wezel from comment #20)
> So after I copied the file to /etc/udev/rules and changed the line
> ACTION!="add", GOTO="libmtp_rules_end"
> 
> to 
> ACTION!="bind", GOTO="libmtp_rules_end"
> 
> The symlink gets generated and I can access the storage on my smartphone
> again with dolphin

This does not work for me: all I get is a few log messages telling:

apr 23 15:14:13 xxxxxx org_kde_powerdevil[19851]: UdevQt: unhandled device action "bind"
apr 23 15:14:13 xxxxxx kdeinit5[19762]: UdevQt: unhandled device action "bind"
apr 23 15:14:13 xxxxxx upowerd[819]: unhandled action 'bind' on /sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.1
Comment 24 Paolo Pedroni 2018-04-23 13:17:51 UTC
...and no new device notification popup.
Comment 25 Stephan Wezel 2018-04-23 20:25:09 UTC
(In reply to Paolo Pedroni from comment #23)
> This does not work for me: all I get is a few log messages telling:
> 
> apr 23 15:14:13 xxxxxx org_kde_powerdevil[19851]: UdevQt: unhandled device
> action "bind"
> apr 23 15:14:13 xxxxxx kdeinit5[19762]: UdevQt: unhandled device action
> "bind"
> apr 23 15:14:13 xxxxxx upowerd[819]: unhandled action 'bind' on
> /sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.1

The warnings are unrelated. Those simply telling that the udev code used by those kde components doesn't support the new udev device action type "bind"

(In reply to Paolo Pedroni from comment #24)
> ...and no new device notification popup.
Ah I had the same problem. After some playing around with the first rule I got it working.

Now the first rule looks like this:
ACTION!="bind", ACTION!="add" GOTO="libmtp_rules_end"

Now the popup shows up again and still I can access the storage on the mtp device.

It seems that the "add" ACTION must be still processed by the rules to have the device notification popup working. A second run for the "bind" ACTION is needed so that the newly plugged in device gets properly setup as mtp device (at least for solid)
Comment 26 Davide Gianforte 2018-04-24 05:22:53 UTC
Stephan's solution in #25 works for me.

Kernel 4.16.0+, Qt 5.9.4, Plasma 5.12.3, Frameworks 5.44.0, eudev 3.2.5, libgudev 232
Comment 27 Max 2018-04-24 07:38:36 UTC
Confirm, Stephan's workaround (post #25) works for me too.
Comment 28 Nate Graham 2018-04-25 13:21:15 UTC
So whose responsibility is it for fixing this? Is this the kernel's problem or ours?
Comment 29 Stefan Brüns 2018-04-25 14:34:02 UTC
(In reply to Nate Graham from comment #28)
> So whose responsibility is it for fixing this? Is this the kernel's problem
> or ours?

The kernel has a "never break userspace, even if userspace is broken" policy, so if brought to the attention of the kernel developers, there will likely be changes in the kernel.

On the other hand, I don't think it is the best approach here - it may take weeks until a solution is found, if at all possible (improving handling of some devices *AND* not breaking userspace), and more weeks until it reaches distributions and users.

The culprit is likely the missing handling of the "bind" action in solid/backends/shared/udev*.cpp (UdevQt) (which can likely be done by just emitting deviceChanged), *and* the missing handling of deviceChanged in solid/backends/devices/udev/udevmanager.cpp.

The changes in UdevQt are trivial, but the changes in udevmanager are likely more evolved.
Comment 30 Stephan Wezel 2018-04-25 18:46:25 UTC
Hmm something is strange.
The properties reported by udevadm monitor -p when i pluggin the device differs for the add and bind Action.

For this test I have reverted my workaround.
Here the output for those events

UDEV  [1721.426090] add      /devices/pci0000:00/0000:00:14.0/usb3/3-12 (usb)
ACTION=add
BUSNUM=003
DEVLINKS=/dev/libmtp-3-12
DEVNAME=/dev/bus/usb/003/010
DEVNUM=010
DEVPATH=/devices/pci0000:00/0000:00:14.0/usb3/3-12
DEVTYPE=usb_device
DRIVER=usb
ID_BUS=usb
ID_FOR_SEAT=usb-pci-0000_00_14_0-usb-0_12
ID_MEDIA_PLAYER=1
ID_MODEL=Xperia_Z3C
ID_MODEL_ENC=Xperia\x20Z3C
ID_MODEL_FROM_DATABASE=D5803 [Xperia Z3 Compact] (MTP mode)
ID_MODEL_ID=01bb
ID_MTP_DEVICE=1
ID_PATH=pci-0000:00:14.0-usb-0:12
ID_PATH_TAG=pci-0000_00_14_0-usb-0_12
ID_REVISION=0232
ID_SERIAL=Sony_Xperia_Z3C_YT911AT36D
ID_SERIAL_SHORT=YT911AT36D
ID_USB_INTERFACES=:ffff00:
ID_VENDOR=Sony
ID_VENDOR_ENC=Sony
ID_VENDOR_FROM_DATABASE=Sony Ericsson Mobile Communications AB
ID_VENDOR_ID=0fce
MAJOR=189
MINOR=265
PRODUCT=fce/1bb/232
SEQNUM=2495
SUBSYSTEM=usb
TAGS=:seat:uaccess:
TYPE=0/0/0
USEC_INITIALIZED=1721409960


UDEV  [1721.437162] bind     /devices/pci0000:00/0000:00:14.0/usb3/3-12 (usb)
ACTION=bind
BUSNUM=003
DEVNAME=/dev/bus/usb/003/010
DEVNUM=010
DEVPATH=/devices/pci0000:00/0000:00:14.0/usb3/3-12
DEVTYPE=usb_device
DRIVER=usb
ID_BUS=usb
ID_MODEL=Xperia_Z3C
ID_MODEL_ENC=Xperia\x20Z3C
ID_MODEL_FROM_DATABASE=D5803 [Xperia Z3 Compact] (MTP mode)
ID_MODEL_ID=01bb
ID_REVISION=0232
ID_SERIAL=Sony_Xperia_Z3C_YT911AT36D
ID_SERIAL_SHORT=YT911AT36D
ID_USB_INTERFACES=:ffff00:
ID_VENDOR=Sony
ID_VENDOR_ENC=Sony
ID_VENDOR_FROM_DATABASE=Sony Ericsson Mobile Communications AB
ID_VENDOR_ID=0fce
MAJOR=189
MINOR=265
PRODUCT=fce/1bb/232
SEQNUM=2497
SUBSYSTEM=usb
TYPE=0/0/0
USEC_INITIALIZED=1721409960

For the "add" action the DEVLINKS and the ID_MTP_DEVICE and ID_MEDIA_PLAYER are properly setup up

But for the "bind" action those properties are missing.
It seems that solid reacts on the "bind" action with the same (or similar) logic as the "add" action.
Maybe it updates the stored properties for the plugged in device when the "bind" action event occures. Through this update the properties DEVLINKS, ID_MTP_DEVICE and ID_MEDIA_PLAYER gets removed.

Otherwise I cannot understand why the "bind" action has an effect on how the newly plugged device is seen by solid

Due my workaround those properties are also set for the "bind" action and so any update done to stored properties doesn't change anything.

But it is also strange that the symlink (defined in the "add" action) is also not visible.
AFAIK udev itself creates such symlinks when a rules specifies "SYMLINK+="
So it seems that udev self might remove the stored information about e.g. ID_MTP_DEVICE and also the symlink when the "bind" action occures when the properties differs from the "add" action

It seems to be an udev/eudev bug. It handles the "bind" action as an "add/update" action
For udev (under systemd umbrella) I found this bugreport: https://github.com/systemd/systemd/issues/8221
Comment 31 Stephan Wezel 2018-04-25 19:36:49 UTC
Created attachment 112244 [details]
Hacked a patch together to have udev ignore bind/unbind events when handling rules

Hacked a patch together to have udev ignore bind/unbind events when handling rules.
This also fixes the problem.
This change should also fix possible any other broken udev rules which reacts only on "add" ACTION
Comment 32 Nate Graham 2018-04-25 19:42:36 UTC
Thanks Stephan! Patches in Bugzilla tickets tend to get lost, so please submit your patch via Phabricator: http://phabricator.kde.org/

Here's the documentation: https://community.kde.org/Infrastructure/Phabricator
Comment 33 Stephan Wezel 2018-04-25 19:49:45 UTC
(In reply to Nate Graham from comment #32)
> Thanks Stephan! Patches in Bugzilla tickets tend to get lost, so please
> submit your patch via Phabricator: http://phabricator.kde.org/
> 
> Here's the documentation:
> https://community.kde.org/Infrastructure/Phabricator

The patch is not for a kde-framework component. It is for systemd-udev itself.
I post it here mostly so that any other stumpling over this here can use it if wanted
Comment 34 Nate Graham 2018-04-25 19:55:14 UTC
Ah, then I'll just assume you're going to submit it to the right place! :)
Comment 35 Timo Gurr 2018-05-15 08:04:02 UTC
For reference, the upstream bug report seems to be: https://github.com/systemd/systemd/issues/8221
Comment 36 minarandria 2018-07-20 10:01:58 UTC
Stephan's solution on #25 works.
Comment 37 Axel Braun 2018-09-12 13:34:27 UTC
looks like this bug (upstream) is not making progress....
I'm running kernel 4.18.5, and with the proposed workaround I get the error

Could not read. Reason: I/O-Problem

See https://bugs.kde.org/show_bug.cgi?id=395130
Comment 38 Vignesh Kumar 2018-10-03 20:05:11 UTC
Fix is still needed in 4.18.10 and #25 solution still works.
Comment 39 Jordan Bradley 2018-10-19 16:00:18 UTC
This still hasn't been fixed in the Fedora 29 beta.

For anyone else having this problem this is the fix:

> $dnf install libmtp
> $nano /lib/udev/rules.d/69-libmtp.rules

And change

> ACTION!="add", GOTO="libmtp_rules_end"

to

> ACTION!="bind", ACTION!="add", GOTO="libmtp_rules_end"

And reboot
Comment 40 Marcus Meissner 2018-10-28 07:30:43 UTC
i released libmtp 1.1.16 with this fix included in its generated udev rules
Comment 41 Shmerl 2018-11-26 02:07:24 UTC
For Sony Xperia XA2 (running Jolla Sailfish) I had to use the bind/add workaround, plus to add an entry for the device as follows:

# SONY Xperia XA2 MTP
ATTR{idVendor}=="0fce", ATTR{idProduct}=="0a07", SYMLINK+="libmtp-%k", MODE="660", GROUP="audio", ENV{ID_MTP_DEVICE}="1", ENV{ID_MEDIA_PLAYER}="1"

Debian testing is still shipping libmpt 1.1.13, so it didn't get upstream fixes yet.
Comment 42 Simone 2019-01-19 14:22:51 UTC
Confirmed in Fedora 29 stable.

libmtp-1.1.16-1.fc29.x86_64

In /lib/udev/rules.d/69-libmtp.rules:
 
ACTION!="add", ACTION!="bind", GOTO="libmtp_rules_end"
ENV{MAJOR}!="?*", GOTO="libmtp_rules_end"
SUBSYSTEM=="usb", GOTO="libmtp_usb_rules"
GOTO="libmtp_rules_end"

LABEL="libmtp_usb_rules"

Still get the error.
Comment 43 Simone 2019-01-19 14:26:30 UTC
I'm sorry I was wrong, seems to work now. Thanks.
Comment 44 Wolfgang Bauer 2019-03-01 17:19:21 UTC
*** Bug 395130 has been marked as a duplicate of this bug. ***
Comment 45 tejbeer singh 2019-03-31 09:28:09 UTC
(In reply to Jordan Bradley from comment #39)
> This still hasn't been fixed in the Fedora 29 beta.
> 
> For anyone else having this problem this is the fix:
> 
> > $dnf install libmtp
> > $nano /lib/udev/rules.d/69-libmtp.rules
> 
> And change
> 
> > ACTION!="add", GOTO="libmtp_rules_end"
> 
> to
> 
> > ACTION!="bind", ACTION!="add", GOTO="libmtp_rules_end"
> 
> And reboot
Comment 46 tejbeer singh 2019-03-31 09:30:39 UTC
This worked for me 

> ACTION!="add", GOTO="libmtp_rules_end"

to

> ACTION!="bind", ACTION!="add", GOTO="libmtp_rules_end"