28

Using Arch Linux / XFCE, I frequently have problems with USB drives that are not properly mounted. Sometimes they automatically show up in Thunar and I can mount them with one click. However, at other times (it's about fifty/fifty) the drive is just not recognized. I have had this problem with USB External Hard Drives, USB Memory Sticks, and cameras. If the external drive is not recognized, this is the situation:

  • The drive does not show up at fdisk -l at all (it only shows my hard drives)
  • The drive does not appear at /dev/disk
  • The drive DOES appear when running lsusb

So there is some sort of recognition, but I do not understand why, nor do I know how to mount the drives when this happens. I just reboot and hope it works next time, which is clearly not convenient...

UPDATE

When I monitor /var/log/everything.log (no info in syslog), then I see this happen when plugging in the USB:

Dec 14 15:36:32 localhost kernel: [ 6591.042911] usb 1-3: new high speed USB device number 9 using ehci_hcd
Dec 14 15:36:32 localhost mtp-probe: checking bus 1, device 9: "/sys/devices/pci0000:00/0000:00:1d.7/usb1/1-3"
Dec 14 15:36:32 localhost mtp-probe: bus: 1, device: 9 was not an MTP device

This is another requested output:

$udevadm monitor
monitor will print the received events for:
UDEV - the event which udev sends out after rule processing
KERNEL - the kernel uevent

KERNEL[6809.192268] add      /devices/pci0000:00/0000:00:1d.7/usb1/1-3 (usb)
KERNEL[6809.193421] add      /devices/pci0000:00/0000:00:1d.7/usb1/1-3/1-3:1.0 (usb)
UDEV  [6809.299246] add      /devices/pci0000:00/0000:00:1d.7/usb1/1-3 (usb)
UDEV  [6809.306074] add      /devices/pci0000:00/0000:00:1d.7/usb1/1-3/1-3:1.0 (usb)
  • run this command udevadm monitor, then plugin your USB device and post pack any issues you find there. – Hanan Dec 14 '11 at 17:10
  • @HananN. copy that; I've added this –  Dec 14 '11 at 18:39
  • 1
    Just a thought: I sometimes had this problem when connecting via USB Hub which wasn't powered externally – erch Dec 02 '13 at 19:24

3 Answers3

16

The problem seems to be a catchall rule in /lib/udev/rules.d/69-libmtp.rules:

# Autoprobe vendor-specific, communication and PTP devices
ENV{ID_MTP_DEVICE}!="1", ENV{MTP_NO_PROBE}!="1", ENV{COLOR_MEASUREMENT_DEVICE}!="1", ENV{libsane_matched}!="yes", ATTR{bDeviceClass}=="00|02|06|ef|ff", PROGRAM="/usr/lib/udev/mtp-probe /sys$env{DEVPATH} $attr{busnum} $attr{devnum}", RESULT=="1", SYMLINK+="libmtp-%k", ENV{ID_MTP_DEVICE}="1", ENV{ID_MEDIA_PLAYER}="1"

Commenting out that line, as shown below, fixed the problem:

# Autoprobe vendor-specific, communication and PTP devices
ENV{ID_MTP_DEVICE}!="1", ENV{MTP_NO_PROBE}!="1", ENV{COLOR_MEASUREMENT_DEVICE}!="1", ENV{libsane_matched}!="yes", ATTR{bDeviceClass}=="00|02|06|ef|ff", PROGRAM="/usr/lib/udev/mtp-probe /sys$env{DEVPATH} $attr{busnum} $attr{devnum}", RESULT=="1", SYMLINK+="libmtp-%k", ENV{ID_MTP_DEVICE}="1", ENV{ID_MEDIA_PLAYER}="1"

In my case, I had to reboot, but there's probably a service that could be restarted instead.

terdon
  • 242,166
kbyrd
  • 1,416
  • 14
  • 18
  • this data was in /var/log/everything.log, but as you can see there is no drive letter assigned (which is also seen with fdisk). There is very little output, but there is some. I've added this at the top. –  Dec 14 '11 at 18:40
  • 5
    Well now, it appears to be fixed! In the log I found this: Dec 14 15:36:32 localhost mtp-probe: bus: 1, device: 9 was not an MTP device, and after searching for this I found this thread: https://bbs.archlinux.org/viewtopic.php?id=119676 - and I was able to solve it commenting out the catch-all line in the MTP rules, it now appears to be working. Thanks! –  Dec 14 '11 at 18:59
  • 4
    @user11780: if the actual answer is the one you gave in your comment, then instead of accepting the offered answer, you should write a new answer yourself with the information you found, and then accept that. Otherwise, casual readers will be misled into thinking kbyrd's answer -- which is really more of a comment than an answer -- is the correct one. – Teemu Leisti Jul 15 '13 at 09:59
  • Totally agree with @TeemuLeisti. Put the right answer here then change the correct one from mine to your new one. – kbyrd Jul 16 '13 at 21:53
  • Oh, and instead of just linking to the article, please repeat the information here -- the page at the end of the link might disappear, rendering your answer useless. – Teemu Leisti Jul 17 '13 at 08:07
  • 1
    Since the OP accepted your answer (which wasn't really answering, only suggesting where the OP should check for more info), I replaced your answer with the actual solution found in the thread the OP linked to. I can confirm that this solution solved the issue for me. – terdon Oct 01 '16 at 12:40
  • https://unix.stackexchange.com/questions/39370/how-to-reload-udev-rules-without-reboot#39371
    # udevadm control --reload-rules && udevadm trigger     – kyb Oct 06 '17 at 21:19
  • 2
    Commenting out that line, as shown below, doesn't look commented out to me.. – ZN13 Mar 29 '18 at 10:49
9

I used ENV{MTP_NO_PROBE}="1" to stop the MTP Probe. That way I didn't have modify the Arch's /lib/udev/rules.d/69-libmtp.rules.

export MTP_NO_PROBE="1"
kyb
  • 420
Dennis Anderson
  • 101
0

Logging shows that there's something going on with the MTP device detection.

Try uninstalling libmtp if you can get away with it, or just comment out the udev rule in the relevant file.

purple_arrows
  • 101