13

Users repeatedly complain about lost data on USB thumb drives after they unplugged them without unmounting. We run Ubuntu 14.04 LTS on our machines. Auto-mounting is enabled.

As I am tired of remembering them to do a safe removal before unplugging, I want to make Ubuntu display an alert whenever a mounted USB drive is unplugged.

I thought of adding an udev rule that runs notify-send on removal in case the drive is still mounted. How can I determine if the USB drive was mounted upon removal?

RenWal
  • 158
  • So you've said that auto-mounting is enabled, but then you ask "how can I determine if the usb that fired udev rule was mounted?" . Now, I think you mean you need to determine the state of USB upon removal - mounted or unmounted. I'd personally approach this with a startup script that merely monitors the mounting/unmounting time of the usb with df -a | grep 'sd[b-z]' command. A udev rule can send date of removal to a log of some sort. If the time of removal given by the script matches that of udev rule (at least by minutes, with the seconds there may be delay), then usb wasnt mounted. – Sergiy Kolodyazhnyy Jun 20 '15 at 23:45
  • 2
    Here's also a script that i wrote for the logging purposes. http://paste.ubuntu.com/11748191/ If you like this idea, I could post this as an answer, but I personally consider these two comments a suggestion, rather than a working solution – Sergiy Kolodyazhnyy Jun 20 '15 at 23:47

2 Answers2

8

Unfortunately, that's a thing Micro$oft actually got quite right: USB removal... And you'll keep on having this problem until you:

  1. Disable auto-mounting

    If users have to mount manually, it'll be easier to train them to dismount as well.

  2. Create a udev rule that turns off all caching on USB disks...

Community
  • 1
Fabby
  • 34,259
  • 2
    +1 - disabling the cache helps reduce the problem. As long as they don't unplug the device during a write (which usually causes an LED on the device to light up / flash) they will be alright. – Nathan Osman Jun 21 '15 at 00:17
  • Okay, that'd work well on the computer side. But doesn't disabling cache or setting sync flag on mount burn out the flash chip rather quickly? Those USB drives are all VFAT and I heard Linux is quite aggressive at updating FAT tables - wearing out the sectors containing the table. – RenWal Jun 21 '15 at 10:41
  • I only buy SLC sticks and haven't had any die on me yet regardless of the file system... (and I only have 2) – Fabby Jun 21 '15 at 13:42
  • @RenWal: As you've never accepted an answer on this site: don't forget to click the grey ☑ at the left of this text, which means Yes, this answer is valid! – Fabby Jun 24 '15 at 07:35
  • 1
    FWIW, Windows disables write cache on FAT-formatted USB drives by default, for the same reasons, so I guess any extra wear on the drive was seen as a lesser evil. – thomasrutter Jun 25 '15 at 05:48
4

I like Fabby's approach, but it is good to teach people about this bad habit (They are not working all the time on controlled machines). This is similar to an OSX feature, as described here.

There is a small difference that you may use it to know if it was a safe remove:

  • udev variable ID_PART_TABLE_TYPE=dos is set for sdx disk node (NOT partition node sdxY) in unsafe remove.

  • Where it is not set in safe remove

Noticed by monitoring udev events:

udevadm monitor -u --environment

  • Safe remove

    UDEV  [8292.380554] change   /devices/pci0000:00/0000:00:14.0/usb1/1-2/1-2:1.0/host16/target16:0:0/16:0:0:0/block/sdb (block)
ACTION=change
DEVLINKS=/dev/disk/by-id/usb-ADATA_USB_Flash_Drive_8d90ec535e6663-0:0 /dev/disk/by-path/pci-0000:00:14.0-usb-0:2:1.0-scsi-0:0:0:0
DEVNAME=/dev/sdb
DEVPATH=/devices/pci0000:00/0000:00:14.0/usb1/1-2/1-2:1.0/host16/target16:0:0/16:0:0:0/block/sdb
DEVTYPE=disk
DISK_MEDIA_CHANGE=1
ID_BUS=usb
ID_INSTANCE=0:0
ID_MODEL=USB_Flash_Drive
ID_MODEL_ENC=USB\x20Flash\x20Drive\x20
ID_MODEL_ID=c96a
ID_PATH=pci-0000:00:14.0-usb-0:2:1.0-scsi-0:0:0:0
ID_PATH_TAG=pci-0000_00_14_0-usb-0_2_1_0-scsi-0_0_0_0
ID_REVISION=0.00
ID_SERIAL=ADATA_USB_Flash_Drive_8d90ec535e6663-0:0
ID_SERIAL_SHORT=8d90ec535e6663
ID_TYPE=disk
ID_USB_DRIVER=usb-storage
ID_USB_INTERFACES=:080650:
ID_USB_INTERFACE_NUM=00
ID_VENDOR=ADATA
ID_VENDOR_ENC=ADATA\x20\x20\x20
ID_VENDOR_ID=125f
MAJOR=8
MINOR=16
SEQNUM=2989
SUBSYSTEM=block                                                              
TAGS=:systemd:                                                               
USEC_INITIALIZED=554873

  • Unsafe remove

    UDEV  [8391.320280] remove   /devices/pci0000:00/0000:00:14.0/usb1/1-3/1-3:1.0/host17/target17:0:0/17:0:0:0/block/sdb (block)
ACTION=remove
DEVLINKS=/dev/disk/by-id/usb-ADATA_USB_Flash_Drive_8d90ec535e6663-0:0 /dev/disk/by-path/pci-0000:00:14.0-usb-0:3:1.0-scsi-0:0:0:0
DEVNAME=/dev/sdb
DEVPATH=/devices/pci0000:00/0000:00:14.0/usb1/1-3/1-3:1.0/host17/target17:0:0/17:0:0:0/block/sdb
DEVTYPE=disk
ID_BUS=usb
ID_INSTANCE=0:0
ID_MODEL=USB_Flash_Drive
ID_MODEL_ENC=USB\x20Flash\x20Drive\x20
ID_MODEL_ID=c96a
ID_PART_TABLE_TYPE=dos
ID_PATH=pci-0000:00:14.0-usb-0:3:1.0-scsi-0:0:0:0
ID_PATH_TAG=pci-0000_00_14_0-usb-0_3_1_0-scsi-0_0_0_0
ID_REVISION=0.00
ID_SERIAL=ADATA_USB_Flash_Drive_8d90ec535e6663-0:0
ID_SERIAL_SHORT=8d90ec535e6663
ID_TYPE=disk
ID_USB_DRIVER=usb-storage
ID_USB_INTERFACES=:080650:
ID_USB_INTERFACE_NUM=00
ID_VENDOR=ADATA
ID_VENDOR_ENC=ADATA\x20\x20\x20
ID_VENDOR_ID=125f
MAJOR=8
MINOR=16
SEQNUM=3022
SUBSYSTEM=block
TAGS=:systemd:
USEC_INITIALIZED=436355

  1. Create a udev rule (change useranme)

    $ sudo nano /etc/udev/rules.d/90-unsafe-remove-notify.rules

ACTION=="remove", KERNEL=="sd?", ENV{ID_PART_TABLE_TYPE}!="", RUN+="/usr/bin/sudo -u username DISPLAY=:0 notify-send 'Unsafe Remove' '<b><i>Your long message</b></i>' -i /usr/share/icons/gnome/48x48/emotes/face-worried.png -t 10000"

  2. Reload rules

    sudo udevadm control --reload-rules

Another way, you may use a script (python) that connect to udisks DBUS. It has all needed info you need about partition mount/unmount, disks plug/unplug...

Reference/Source: Gentoo Wiki: Udisks - USB_Thumb_Drive_Example

Community
  • 1
user.dz
  • 48,105
  • 1
    While I do like Fabby's approach, this is what I was looking for! I now plan on writing a python script that listens for udisks events on DBUS and then handles the display of message dialogs, etc. – RenWal Jul 13 '15 at 16:24