Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm trying to set up a script to run every time I plug in a USB device. I created the file /etc/udev/rules.d/90-local.rules and added the following rule:

ACTION=="add", SUBSYSTEM=="usb", KERNEL=="sd*", SYSFS{model}=="Cruzer*", RUN+="sh /home/jesse/Documents/Scripts/"

The problem is that when the drive is connected, nothing happens. The script, for debugging purposes, is rigged to send a notification with notify-send, which is installed and works fine from the terminal.

The path to the script is correct, as I've run that exact command in the terminal without any troubles.

share|improve this question
Is your antivirus running? This is behavior which would trigger action from any number of AV programs. Although I'd expect a warning, if you've disabled notifications, you may not see it except in the logs. I would recommend disabling the internet, then your AV program, the trying it again. – zenbike Jul 3 '11 at 14:48
Running Ubuntu 11.04 with no AV installed. – JTeK Jul 4 '11 at 4:31
@zenbike: Why would adding custom udev rules trigger an antivirus program? – grawity Jul 15 '11 at 8:11
Starting any script on device insertion can cause false positives in an AV set to scan removable devices. Why, I don't know. That it happened to me with a factory installed script on a thumbdrive and Avira AV, I do know. – zenbike Jul 15 '11 at 8:18
up vote 3 down vote accepted

I had the same problem. This worked for me:

Try to copy your script into /usr/local/bin and change the directory in your .rules file.

Also, I don't know what SYSFS is, but I would prefer to use the ATTR properties.

The following line is the content of my .rules file:

ACTION=="add", SUBSYSTEM=="block", KERNEL=="sd[a-z]1", ATTRS{vendor}=="SanDisk ", RUN+="/usr/local/bin/"
share|improve this answer
Thanks for the help! – JTeK Aug 14 '11 at 13:58
the ATTRS{vendor}=="SanDisk " part does that mean that only Sandisk will be detected? – blade19899 Sep 26 '12 at 9:23

notify-send requires access to your DBus session bus, which it cannot have for two reasons:

  • No information about the session. When started by udev, your script knows nothing about where you are logged in or if you're logged in at all. Multi-seat with X11 is still tricky, but user switching works for both X11 and console sessions. Many people also use SSH, VNC and NX over the network.

    (DISPLAY=:0 would work half of the time, but that's still guessing at best.)

  • Denied by DBus policy. Even if your script somehow finds your X11 session, it will not be able to send notifications due to the script being run as root instead of your user account.

share|improve this answer
for LINE in $(find /proc/ -maxdepth 2 -name environ -exec grep -z "^DBUS_SESSION_BUS_ADDRESS" {} \; | sort -uz | tr '\0' '\n'); do eval $LINE ... done; did the trick for me with notify-send – mlt Jun 26 '12 at 8:00

You can try to match the device by vendor and product IDs instead. The following custom rule works for me:

ACTION=="add", SUBSYSTEM=="usb", ATTR{idVendor}=="0763", ATTR{idProduct}=="019b", RUN+="/usr/bin/aconnect 20 128"

You can see idVendor and idProduct in the lsusb output or dmesg after attaching the device.

share|improve this answer
I tried that, and it didn't work either... (ATTR{idProduct}=="5530")... is the vendor also required? I wouldn't think so... – JTeK Jul 4 '11 at 4:29
In that case the problem might be with the script itself. For example it may depend on $PATH env variable. For a test try to run it like export PATH=''; /home/jesse/Documents/Scripts/ – Aleh Jul 4 '11 at 14:37

Following up on Aleh's answer: If you also want to monitor remove events, you need to look for an environment variable named ID_SERIAL. It contains vendor and product ID separated by underscore:

ACTION=="add|remove", SUBSYSTEM=="usb", ENV{ID_SERIAL}=="0763_019b" RUN+="/usr/bin/aconnect 20 128"

The rule is now shorter, too.

share|improve this answer

Perhaps, you may need to add a sleep within the script, to give the usb device a chance to "settle" down? For example, usb 3g modems, mode switching to get a /dev/ttyUSB to get kicked up and running by the kernel.

share|improve this answer

Try to replace SUBSYSTEM="usb" with SUBSYSTEMS="usb"

share|improve this answer
No, SUBSYSTEM=="usb" is just fine. – krlmlr Sep 27 '13 at 13:34

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .