0

I'm developing an application which at some point needs to write in a USB drive unit. The application gets executed with non-superuser permissions and I've thought the best way to write on the drive would be to have it mounted with the flush option as soon as the drive gets inserted, this way, theoretically I don't need to do any umount operation, with this udev rule:

ACTION="add", KERNEL="sd*[0-9]", SUBSYSTEMS="usb", RUN+="/bin/sh mymountscript.sh '%E{DEVNAME}'"

The mount script tries to invoke the command this way:

mount -o --flush $1 /media/my-user/my-usb-unit

But I get this mount error:

mount: wrong fs type, bad option, bad superblock on /dev/sdb1,
       missing codepage or helper program, or other error

What it's curious about it is that I get this error only when trying to mount it through the udev rule, if I invoke mymountscript.sh myself the unit gets properly mounted in the point.

Apart from a solution for this issue, I would like to know if it's risky to do it this way (I understand it is because I don't umount the drive after the file is written). If I go the other way, I would need the application script (which gets executed on behalf of the user) to be able to mount/umount the unit himself. For this, I would need to save the device name somewhere when it gets inserted and also to grant mount permissions to the application.

The OS is Xubuntu 16.04.

  • I guess, if you invoke the Mount-script manually, you specify a Partition (/dev/sdb1) but when done automatically, it gets passed the device (dev/sdb) instead? – gerhard d. Jun 3 at 10:04
  • @gerhardd. When done manually, I pass the device name myself: mymountscript.sh /dev/sdb1. – Xtreme Biker reinstate Monica Jun 3 at 10:06
  • Yes, i thought you would :-) Looking at your error message: "bad superblock on /dev/sdb," we can see that the script gets passed the wrong Parameter when mounting automatically. One typically Mounts a Partition (/dev/sdX[1..n]), not the whole device (/dev/sdX). – gerhard d. Jun 3 at 11:02
  • Sorry, I did a typo here, it's just meant to be /dev/sdb1 itself. It's not a problem with the parameter actually, the mount command does it well when no --flush option is specified. – Xtreme Biker reinstate Monica Jun 3 at 12:01
0

My workaround for this was to manage it this way:

  1. One udev rule for the USB inserted action.

  2. The scripts coming in the meanwhile mount/umount the drive themselves.

  3. One udev rule for the USB removed action.

USB gets inserted

I execute one script which just saves the device name into a file. I can append any other script in this rule:

ACTION=”add”, KERNEL=”sd*[0-9]*”, SUBSYSTEMS=”usb”,  RUN+=”/bin/sh my-usb-inserted.sh”,  RUN+=”/bin/sh myownscript.sh” 

Here, myownscript.sh will mount the device using pmount, which allows mounting/umounting removable drives for standard users. I can call any other scripts after these, as long as I umount the unit in each of them before the next one uses it.

USB gets removed

Here, a simple script removes the file created by my-usb-inserted.sh, so we know there's no any flash unit inserted inside the scripts.

ACTION=”remove”, KERNEL=”sd*[0-9]*”, SUBSYSTEMS=”usb”,  RUN+=”/bin/sh usb-removed.sh” 

This workaround has not taken into consideration the fact of having to deal with more than one USB drive.

See also:

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.