usbmount does not work on Bionic

Bug #1768010 reported by Andrew Oakley
38
This bug affects 7 people
Affects Status Importance Assigned to Milestone
usbmount (Ubuntu)
Confirmed
Undecided
Unassigned

Bug Description

The package "usbmount" under previous versions of Ubuntu (definitely under Xenial 16.04), mounted USB filesystems such as memory sticks, to mountpoints /media/usb0 /media/usb1 /media/usb2 etc. This was ideal for server or headless systems (i.e. without a desktop) to gain access to, for example, USB memory card readers.

On Bionic, usbmount no longer appears to work.

Package: usbmount
Version: 0.0.22

What works in both 16.04 and 18.04 :

* When you install the usbmount package, the mount points /media/usb0 /media/usb1 /media/usb2 .. /media/usb7 are created

* The symbolic link /media/usb correctly links to /media/usb0

* /etc/usbmount is populated with the default configuration files

* /dev/sdb1 , /dev/sdb2 etc. do correctly come into existence when a memory card is inserted into the reader. This is nothing to do with usbmount but it does indicate that my system is otherwise performing correctly.

What doesn't work in 18.04 that used to work in 16.04 :

* When you place a memory card (e.g. SD card) into an attached USB memory card reader, usbmount on Bionic does not automatically mount it to one of the /media/usb? points. For example, when I insert a Raspberry Pi micro SD card (one card, two partitions; first VFAT and second EXT4) into my USB card reader, under Xenial it mounted /dev/sdb1 to /media/usb0 , and /dev/sdb2 to /media/usb1 . Under Bionic it does not mount anything. However /dev/sdb1 and /dev/sdb2 do exist and can be mounted manually.

My guess:

* I suspect that Bionic is doing something different in the way it detects new USB device connections or new memory card insertions (maybe all newly attached filesystems?). If my suspicion is correct then the usbmount scripts never get called.

Other observations:

* When I remove the card fromt the reader, the Bionic console says "usb 1-2: device descriptor read/64, error -32". It didn't do that under Xenial.

Workaround:

* I can mount the filesystems manually using sudo mount /dev/sdb1 /media/usb0 && sudo mount /dev/sdb2 /media/usb1 , however this assumes I already know the partitions on the card. If I don't, then I have to use sudo fdisk -l to examine the card first. This is a faff and prone to user error.

I REALLY, REALLY don't want to be writing files to the wrong device!!! (Been there, done that, killed the boot & root partitions). usbmount provided a relatively safe way to quickly automatically mount SD cards & USB keys (for example it didn't require sudo). Using the workaround is considerably more risky.

My use case is that I run a Raspberry Pi educational club for children, and I use usbmount to edit and read Micro SD card files to/from backups on my Ubuntu headless server.

Tags: bionic
description: updated
tags: added: bionic
Revision history for this message
Steve Bian (freespace) wrote :

This issue is caused by MountFlags=slave in the systemd-udevd.service file. Historically 16.04 removed this flag to allow laptop-mode-tools to work:

https://askubuntu.com/questions/1019865/why-does-ubuntu-16-04-remove-mountflags-slave-from-systemd-udevd-service

In 18.04 this flag is preserved and as such when usbmount mounts filesystems they are mounted into systemd's private namespace and not visible to the user.

A workaround is to override the MountFlag as described in:

https://unix.stackexchange.com/a/441588/191141

Revision history for this message
Andrew Oakley (andrew-aoakley) wrote :

@freespace - Thank-you, I can confirm that your workaround solves the problem for me on Bionic. (Really - that's ENORMOUSLY helpful and makes my work with cotswoldjam.org Raspberry Pi club a million times easier. Thanks again.)

Could this workaround be considered the ideal long-term solution, and be promoted to the main release, or does it have unintended, undesirable or insecure consequences?

For the record, the workaround is:

sudo systemctl edit systemd-udevd
And insert into it:
[Service]
MountFlags=shared
Save the file and then execute:
sudo systemctl daemon-reload
sudo service systemd-udevd --full-restart

Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in usbmount (Ubuntu):
status: New → Confirmed
Revision history for this message
Jörg Vehlow (mofx) wrote :

This is already fixed upstream, but sadly no new package was commited: https://github.com/rbrito/usbmount/commit/2d2cdcc58b65bbadf1dbe532e9938967060cee09

Revision history for this message
Dr Stephen Marchant (fishb) wrote :

Thanks again for this, it helped me too.
I have a further problem though: when my usb stick is auto-mounted by usbmount it has write permissions only for root, doing sudo chmod a+w /media/usb0 prints no errors but has no effect. How can I grant user write permissions to this mount-point.
Thanks a lot.
Steve.

Revision history for this message
James (k-james-d) wrote :

I built the new package mentioned in #4 above. While it does auto mount the USB devices, there does seem to be a permission issue as mentioned above.

As root in /media/usb0

# touch test && ls -al test

-rwxr-xr-x 1 root root 0 Oct 4 16:13 test

# chmod 777 test && ls -al test

-rwxr-xr-x 1 root root 0 Oct 4 16:13 test

From mount -v :

/dev/sda1 on /media/usb0 type vfat (rw,nodev,noexec,noatime,nodiratime,sync,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,errors=remount-ro)

So there seems to be a bit more to it.

Revision history for this message
James (k-james-d) wrote :

Sorry for #6 above.. I shouldn't have been testing with a vfat volume, my bad.

Revision history for this message
Colin Taylor (colintaylor) wrote :

I can confirm that the current code on github fixes the udev issue for 18.04. The re-write also fixes an associated problem with mounting NTFS drives through usbmount.

Steven/James: The permissions issue you describe are not bugs and are explained in the documentation. You can set your preferred permissions in /etc/usbmount/usbmount.conf.

Revision history for this message
Dan Desjardins (desdan) wrote :

I've made the necessary changes described in #2 above but when I plug in a usb drive I get the following error

Oct 23 20:48:27 vstreamer systemd-udevd[4114]: Process '/usr/share/usbmount/usbmount add' failed with exit code 2.

There is about a 40 second delay (guessing) and then it looks like it tries again and succeeds...

Here is the full syslog

***********************
Oct 23 20:48:26 vstreamer kernel: [ 7920.611951] usb 3-9: new high-speed USB device number 6 using xhci_hcd
Oct 23 20:48:26 vstreamer kernel: [ 7920.760519] usb 3-9: New USB device found, idVendor=0781, idProduct=5406
Oct 23 20:48:26 vstreamer kernel: [ 7920.760521] usb 3-9: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Oct 23 20:48:26 vstreamer kernel: [ 7920.760523] usb 3-9: Product: U3 Cruzer Micro
Oct 23 20:48:26 vstreamer kernel: [ 7920.760525] usb 3-9: Manufacturer: SanDisk
Oct 23 20:48:26 vstreamer kernel: [ 7920.760526] usb 3-9: SerialNumber: 1738811618C2524A
Oct 23 20:48:26 vstreamer kernel: [ 7920.760924] usb-storage 3-9:1.0: USB Mass Storage device detected
Oct 23 20:48:26 vstreamer kernel: [ 7920.761036] scsi host6: usb-storage 3-9:1.0
Oct 23 20:48:27 vstreamer kernel: [ 7921.788338] scsi 6:0:0:0: Direct-Access SanDisk Cruzer 8.02 PQ: 0 ANSI: 0 CCS
Oct 23 20:48:27 vstreamer kernel: [ 7921.788545] sd 6:0:0:0: Attached scsi generic sg1 type 0
Oct 23 20:48:27 vstreamer kernel: [ 7921.789004] sd 6:0:0:0: [sdb] Attached SCSI removable disk
Oct 23 20:48:27 vstreamer usbmount[4132]: loaded usbmount configurations
Oct 23 20:48:27 vstreamer usbmount[4132]: trying to acquire lock /var/run/usbmount/.mount.lock
Oct 23 20:48:27 vstreamer usbmount[4132]: acquired lock /var/run/usbmount/.mount.lock
Oct 23 20:48:27 vstreamer systemd-udevd[4114]: Process '/usr/share/usbmount/usbmount add' failed with exit code 2.
Oct 23 20:48:28 vstreamer kernel: [ 7922.544364] sd 6:0:0:0: [sdb] 15704063 512-byte logical blocks: (8.04 GB/7.49 GiB)
Oct 23 20:48:28 vstreamer kernel: [ 7922.545035] sdb: detected capacity change from 0 to 8040480256
Oct 23 20:48:28 vstreamer kernel: [ 7922.545542] sdb: sdb1
Oct 23 20:48:49 vstreamer usbmount[4614]: loaded usbmount configurations
Oct 23 20:48:49 vstreamer usbmount[4614]: trying to acquire lock /var/run/usbmount/.mount.lock
Oct 23 20:48:49 vstreamer usbmount[4614]: acquired lock /var/run/usbmount/.mount.lock
Oct 23 20:48:49 vstreamer usbmount[4614]: /dev/sdb1 contains filesystem type vfat
Oct 23 20:48:49 vstreamer usbmount[4614]: mountpoint /media/usb0 is available for /dev/sdb1
Oct 23 20:48:49 vstreamer usbmount[4614]: executing command: mount -tvfat -osync,noexec,nodev,noatime,nodiratime /dev/sdb1 /media/usb0
Oct 23 20:48:49 vstreamer kernel: [ 7943.650747] FAT-fs (sdb1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.
Oct 23 20:48:49 vstreamer usbmount[4614]: executing command: run-parts /etc/usbmount/mount.d
Oct 23 20:48:49 vstreamer usbmount[4614]: usbmount execution finished

Revision history for this message
Colin Taylor (colintaylor) wrote :

Dan: It looks like it's working as expected. The first error can be ignored because it always does that. It first tries to mount /dev/sdb which always fails because it is not a partition. Next it tries to mount /dev/sdb1 which succeeds because it is a partition.

I don't know why there is a 21 second delay. Your computer initially appears to have some problem correctly reading the capacity of the USB drive. It might be connected to the fact that it wasn't previously ejected properly.

There are more changes to the upstream code than just that shown in post #2. These changes make the mounting process more reliable and emit some extra log messages.

Revision history for this message
Dan Desjardins (desdan) wrote :

Thanks Colin - that's good to hear! usbmount has been part of the distro of my product for some time now and losing it was driving me nuts!
I will work with our programmer to get the latest from github.

Revision history for this message
Dan Desjardins (desdan) wrote :

Checking github - there are a number of repos there... Is it the leetking/usbmount that you are referring to in #8?

Revision history for this message
Colin Taylor (colintaylor) wrote :

Dan: No, I was referring to this as per post #4. https://github.com/rbrito/usbmount

Revision history for this message
narayana (samanarayan) wrote :

Thanks a zillion everyone! After the software update today my USB dongle is getting recognised as before. Many thanks. :)

Revision history for this message
Nikolaj Løbner Sheller (nikolaj-l) wrote :

In
  /lib/systemd/system/systemd-udevd.service
setting
  [Service]
  PrivateMounts=no
solves the problem for me.

Revision history for this message
Bootch (di-man) wrote :

Nikolaj Løbner Sheller (nikolaj-l) wrote on 2019-12-13:
>In
> /lib/systemd/system/systemd-udevd.service
>setting
> [Service]
> PrivateMounts=no
>solves the problem for me.

Did not helped me. There are no changes in system behavior. The following error message is in syslog file:
>systemd[1]: /lib/systemd/system/systemd-udevd.service:35: Unknown lvalue 'PrivateMounts' in section 'Service'

Revision history for this message
Bootch (di-man) wrote :

Steve Bian (freespace) wrote on 2018-05-03:
>This issue is caused by MountFlags=slave in the systemd-udevd.service file. Historically 16.04 removed this flag to allow laptop-mode-tools to work:
>
>https://askubuntu.com/questions/1019865/why-does-ubuntu-16-04-remove-mountflags-slave-from-systemd-udevd-service
>
>In 18.04 this flag is preserved and as such when usbmount mounts filesystems they are mounted into systemd's private namespace and not visible to the user.
>
>A workaround is to override the MountFlag as described in:
>
>https://unix.stackexchange.com/a/441588/191141

Did not helped me. There are no changes in system behavior.

Revision history for this message
Bootch (di-man) wrote :

Bootch (di-man) wrote 22 minutes ago: #17

>Steve Bian (freespace) wrote on 2018-05-03:
>>This issue is caused by MountFlags=slave in the systemd-udevd.service file. Historically 16.04 removed this flag to allow laptop-mode-tools to work:
>>
>>https://askubuntu.com/questions/1019865/why-does-ubuntu-16-04-remove-mountflags-slave-from-systemd-udevd-service
>>
>>In 18.04 this flag is preserved and as such when usbmount mounts filesystems they are mounted into systemd's private namespace and not visible to the user.
>>
>>A workaround is to override the MountFlag as described in:
>>
>>https://unix.stackexchange.com/a/441588/191141

>Did not helped me. There are no changes in system behavior.

It works after reboot.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.