# User mount/umount for USB drives

## Havin_it

Hi,

I'm sure this question is oft-asked, but my searches have not yielded meaty goodness, so here goes:

HISTORY: I went through the pain of making a USB drive easy to insert and remove years ago, which involved running ivman in my KDE3 Autostart and having the following line in my fstab:

```
/dev/sda1              /mnt/usb        auto            noauto,user,rw,exec     0 0
```

The mountpoint had full permissions for my user, which I think was necessary at the time.

Fast-forward to today, and after a bumper Santa visit I had the novel experience of having multiple USB drives to insert. This didn't play well with KDE: when I plugged the second drive in, it glommed onto /mnt/usb leaving the first drive in some weird limbo state (it reappeared after I ejected the second drive). (This seems very odd, as how can both devices have been exposed as /dev/sda1 simultaneously?)

I commented-out the above line in fstab, which had the effect that when I plugged a drive in, it was automounted at "/media/UDISK 2.0". The created dir is read-write for my user, and I used the New Device Notifier plasmoid to open it in Dolphin* and promptly closed it again.  However, upon hitting the Eject button, I got the following message:

```
Cannot unmount the device.

One or more files on this device are open within an application.
```

Using "lsof|grep UDISK" as both user and root, I saw nothing to back-up this message.

So, here goes: is there an agreed and reliable way to make this relatively simple procedure work as it should? And in the case of the negative answer I somehow anticipate, is there an inelegant kludge that will more-or-less do the job?

Thanks in advance...

*Sidenote: Is there a way to substitute Konqueror for Dolphin here? I've used the mimetype association for file/inode to accomplish this in most situations, but this and a few others still insist on using the execrable Dolphin, which I am dedicated to eradicating from my system.

----------

## Havin_it

Some observations:

1) I looked at the situation on my gf's Kubuntu Intrepid laptop. There, the drive is not automounted on insertion; you need to click 'Open in Dolphin' in the New Device Notifier before this happens. Unmounting via the NDN works fine, even if the drive is still open in Dolphin, and there's no 'zombie' mount left in mtab as there was when I yanked the drive in Gentoo. The Kubuntu install has had absolutely no tinkering from me; so, what are they doing right?

2) http://userbase.kde.org/Tutorials/KDE3toKDE4#Automounting_of_USB_devices

So, KDE4 doesn't do automounting.  So what component is doing it on my system?  This is where I get confused, because there are so many different systems/apps that are said to be involved in this process:

```

udev

ivman 

hal

pmount

/etc/fstab

```

I don't know whether I even need all of these. Is there redundancy here?  I would be really grateful for some info about this, as everything I've found written on the subject does not take all these different mechanisms into account.

The way things are currently seems nearly right, and auto-created mountpoints (e.g. /media/UDISK 2.0) seem the best approach for a system where many different devices may be plugged-in (and I really don't think you should need to write specialised config entries for every device you're going to use), but something's obviously failing because we get this "cannot unmount" message which seems to be spurious.

Are there any other things I can do to try to investigate what application is (or appears to be) accessing the drive and preventing its unmounting?

----------

## i92guboj

I suggest writing an udev rule, so the device node for each drive is always the same and unique. For example, for my chinony videocam I use this in /etc/udev/rules.d/99-usb-storage.rules:

```

KERNEL=="sd*", ATTRS{idVendor}=="04f2", ATTRS{idProduct}=="a217", NAME+="chicony%n", GROUP="usb", MODE="0775" ACTION=="add", NAME=="chicony[1-9]", RUN+="/bin/mkdir -p /mnt/chicony%n"

ACTION=="add", NAME=="chicony[1-9]", RUN+="/bin/mkdir -p /mnt/chicony%n"

ACTION=="add", NAME=="chicony[1-9]", RUN+="/bin/mount -t vfat -o rw,noauto,flush,quiet,nodev,nosuid,noexec,noatime,users,group,umask=000 /dev/chicony%n /mnt/chicony%n"

ACTION=="add", NAME=="chicony[1-9]", RUN+="/bin/chmod 0775 /mnt/chicony%n"

ACTION=="add", NAME=="chicony[1-9]", RUN+="/bin/chown root:usb /mnt/chicony%n"

ACTION=="remove", NAME=="chicony[1-9]", RUN+="/bin/umount -l /mnt/chicony%n"

ACTION=="remove", NAME=="chicony[1-9]", RUN+="/bin/rmdir /mnt/chicony%n"

```

That will not only create the device nodes, but also the stuff in /mnt/, and will also set up the correct permissions. If you decide to leave to kde the mounting stuff, you can just use the first line to at least help with the naming. That way each device will have always the same unique name (so there aren't conflicts like the one you describe).

The final umount stuff is only advised if you don't care about data integrity, or if you are sane enough to run "sync" before unplugging the drive (since the driver is actually unmounted after being unplugged, with all that that implies).Last edited by i92guboj on Wed Dec 31, 2008 7:42 pm; edited 1 time in total

----------

## i92guboj

 *Havin_it wrote:*   

> 
> 
> 2) http://userbase.kde.org/Tutorials/KDE3toKDE4#Automounting_of_USB_devices
> 
> So, KDE4 doesn't do automounting.  So what component is doing it on my system?  This is where I get confused, because there are so many different systems/apps that are said to be involved in this process:
> ...

 

I don't think kde needs anything, as long as you have HAL enabled in kcontrol. It shouldn't need ivman at all. I don't know about pmount these days though... In my humble opinion, all this stuff just makes the thing more complicated. This should be handled system-wide, and not in a desktop. That way you end up with ten different ways to handle mounting and conflicts with each other and require extra work and configuration to tie everything together.

 *Quote:*   

> Are there any other things I can do to try to investigate what application is (or appears to be) accessing the drive and preventing its unmounting?

 

lsof and fuser can usually provide that kind of info.

----------

## Havin_it

Hi, thanks for the replies. I did some more examination of the Kubuntu setup and noticed that ivman was absent, so I disabled it on my machine and now get the same behaviour: no automount until clicking "Open with Dolphin", mountpoint created at /media/<DRIVE LABEL>/, umount via the New Device Notifier completes successfully and removes the mountpoint dir after umounting.

Next thing will be to see if this works OK with a partitioned USB HDD.

----------

## pcmaster

I use XFCE4 and i not need to put any entry in /etc/fstab. When i plug a usb key or similar, the system automaticaly creates a directory in /media and use it to acces the drive.

But if i use the unmount option in xfce4 desttop to unmount the drive, the key led remains on. No priblem but if i use eject, then (the key has just one partidtion):

Now, with gentoo-sources-2.6.28-r5: the led change to off, and the /dev/sdb1 file disapears, but /dev/sdb don't.

with the old gentoo-sources-2.6.27-r8: the les remains on, device files same to 2.6.28-r5 (i tested it weeks ago)

time ago, with older versions, ejecting the device not only switch off the led, both two devices /dev/sdb and /dev/sdb1 dissapears.

I don't know if is a kernel issue , or i just tested if for now after kernel update.

----------

## flacvest

Neither will any of the USB sticks I have. I dunno what could be wrong.

I just recovered from severe system mangling and decided to rebuild everything twice after disabling the hal USE Flag for xorg-server. Is that the hitch?? I DO have Probe All LUNs on in the kernel config...

I'm out of ideas, and a whole weekend where I can't play with my PMP. Fooey.

Care to lend a bit of advice???

Thanks in advance...

----------

