These scripts work for me on Fedora Core 2 and Redhat 9. Several people have
reported that they can be made to function on many other Linux distributions
with minor configuration changes and some editing. To get them to
work on your system you may need knowledge of Linux and shell scripting. If
the scripts don't work out of the box, you should look for errors in
/var/log/messages (or where ever your system log is kept). If you are
not comfortable with reading logs and editing scripts - perhaps these scripts
aren't for you.
I no longer have any Linux systems with 2.4 kernels, I think the scripts
will still work. All recent
modifications have only been tested on Fedora Core 4 running kernel 2.6.
Many distributions are now adequately handling usb - so I haven't
spent much time improving usb-mount. If anyone wants to fork a
new version, feel free. The new kernel, dbus, etc should make it
quite easy to create a simpler script from scratch.
Here is a tar that contains a the scripts,
starting config files, documentation and installation instructions.
Here is a URL describing setting it up under Debian with udev
A small bunch of changes:
- More fixes for newer kernels/distibutions that take longer to setup usb devices;
- Handle flash card readers that have more than one device (thanks to Edward);
- Ignore non usb-storage devices (thanks to Wolfgang Klein).
Fix for newer kernels/distibutions that take longer to setup usb devices.
- Usb-mount now loops for up to 10 seconds waiting for a device to be fully setup.
- Added a DESKTOP_FOLDER_NAME variable to the config.
This release contains significant improvements to partition recognition:
- The diskpart utility, which used to be optional, is now mandatory.
Usb-mount now uses diskpart to detect whether a device has a valid partition table.
- Devices with no partition tables will now be correctly recognised
and mounted. Note that the default value of
the NO_PARTITIONS_SUFFIX variable is now "" - which works for
both Redhat with kernel 2.4 and and Fedora on kernel 2.6.
Multiple partition devices are now
handled as under one device icon. For example, a 5 partition USB IDE
enclosure will now appear as one disk-icon with sub folders for each
of the 5 partitions. The mount/umount actions will
apply to the entire multi-partition device.
I've changed to the old-style awk -v argument to support distros that use mawk.
Changed to a default mount option of shortname=mixed for fat32 this seems to work better
when dealing with Java source etc.
Added a SUDO variable in case sudo isn't in the default path.
Added a USE_WHO setting to distros where DO_CONSOLE_USER doesn't work.
Some minor fixes and improvements stemming from feedback after the v0.92
If you enable DESKTOP_SIGNALS, you will have to delete any existing desktop
icons so that they will be recreated with the new options. I'm unsure has to
how useful the desktop signal actions will be - feedback is welcome. They
might be useful if the following combination of settings are enabled:
- Fixed ownership of desktop files on Icon changes.
- Added a directory mask.
- Made the location of lockfile a config option.
- Finished desktop signal actions that accidentally made it into v0.92.
Controlled by the DESKTOP_SIGNALS and ONLY_SIGNAL_ON_REQUEST options.
- Made the terminate signal default to -HUP
- Use -o vfat for FAT16 - fixes mouting problems for some users.
This will disable the lazy option to umount - you will then get an error on
unmounts if processes are still using the device. In theory you should
then be able to then manual select an unmount-with-signal action to
terminate the processes and properly unmount the device. But if you
have already removed the device, you may still run into problems with
corruption and possibly some confusion in the kernel layers.
- Usb-mount has been enhanced in several areas:
- Usb-mount now uses the fuser command to determine if processes are
using a device during an unmount processing.
If Usb-mount v0.92 is configured not to use the lazy (-l) option in UMOUNT_OPTIONS,
it will now raise errors if a process is using a device during unmounting and the umount
will not actually take place - so you will now know that there is a problem - but if
you have already removed the device you may still be in a fix.
Some background info: by default usb-mount uses the -l lazy umount option to allow a
umount to proceed even if processes are using the mounted media -
processes still using a removed device may attempt to write to the device and these
processes may possibly corrupt any replacement device. In practice if you treat
usb devices like floppies, and not like permanent working spaces, this isn't
usually a problem.
The kernel currently lacks a perfect way out in this situation and the -l
umount option is a hack to get around the problem that umount -f (force) option
- Usb-mount may now optionally signal and
kill processes that are using a device during unmount processing. This
has the advantage that the filesystem will (truly) unmount immediately, but on
the downside applications may terminate without saving work. By default this
new behavior is turned off. This feature is controlled by TERMINATE_SIGNAL and
KILL_SIGNAL. If you decide to use this option, be careful to save your work
before unplugging any devices.
Under kernel 2.6, usb-mount now fully matches SCSI host-number, bus, scsi-id, and lun.
Until kernel 2.6 it wasn't possible to deterministically cross reference from the
SCSI sub-system to the USB sub-system and obtain anything more than the host-number.
There are situations under 2.4 where the host-number is insufficient to recognise a
device and it will fail to mount. In practice no one using usb-mount on 2.4 has
reported any problems - probably because complex SCSI-based desktop systems are relatively rare.
The differences in the usb-mount code for kernel 2.4 and 2.6 have been reduced.
The ALPHABETIC_DEVICE_NAMES option is now unnecessary and has been removed.
If all of the above gives you the impression that USB-removable-media is a
bit hackey in the linux world - then you would be right - but similar issues
exist on more popular operating systems (which is not really an excuse, but
it makes me feel better anyway).
Fix a potential security problem - anyone with privilege to run usb-mount
can umount devices other than those mounted under the usb mount path (pointed
out by Jeff Minelli). Added a dirsync to help prevent data loss when
a device is yanked out. Cleaned up the mount options - added vfat
handling. Added an option for systems that don't use alphabetic device names.
Added an option to try and resolve the issues with devices with no partitions -
if you have one one these please give me some feedback on what works.
I've cleaned up the procedure for handling detached devices that haven't
first been unmounted. Under Linux 2.6, I found I could detect detached devices by using
a combination of sg_map and mount. Under 2.4 I used /proc/partitions
to do the same job (thanks to due to Alan McCluskey for drawing my attention
to /proc/partitions). These changes also eliminated the use of /var/run/usb
to store partition maps. The /var/run/usb directory is still used to store
a lock file, but that's all (for now). Richard Tresidder pointed out I
should create /var/run/usb if it doesn't exist.
I've made some more changes because now that more than a year has past, I realise
usb-mount is no longer a temporary solution.
There are new installation instructions because I've changed the organisation of
installation directory to be more practical.
To make upgrades easier config parameters have been removed to an /etc/usb-mount.conf
or /usr/local/etc/usb-mount.conf - a config file is now required.
Usb-mount's behavior on kernel 2.6 has been improved - got rid of bogus messages.
MOUNT_OPTIONS and and UMOUNT_OPTIONS settings have been added to allow for
additional generic mount/umount options.
Feedback messages have been further improved.
A DEBUG setting has been added.
Added more doc's including a couple of man pages. Richard Tresidder
contributed some distro portability fixes, additional messages,
a sync option on mount.
Added (slightly) more accurate version history comments.
Added a TODO list.
- Fixes the major problem of correctly identifying the scsi
device(s) to mount, but requires an additional package,
do so. You might not see this problem if you only have a single device
plugged in at any given time. This version also supports Linux 2.6 and
benefits from it by being able to
more precisely identify what to mount. Remember, you will need to get
sg3_utils as part of
When I bought my first usb device
I had to figure out a way for it
interact with the KDE desktop. I rejected playing with /etc/fstab
and a modified KDE floppy desktop entry for several reasons:
- The device pops up on different /dev/sd* device every time
it is reinserted until you remove the usb-module. This is
because the device serial number doesn't remain constant.
- I don't like the idea of Redhat's removable media tool
rewriting /etc/fstab - it's not a file I like to see toyed with.
- The KDE floppy desktop entry doesn't seem to detect when a device has
been removed by some other means.
I decided to side step the issues by interacting directly with the
Linux hotplug utilities without involving fstab, kudzu or the
automounter. It might not be appropriate on a server system, but
on a desktop system it provides a reasonably intuitive interface.
When the hotplug module signals a change in the usb-storage, I run
a script that does the following:
- Obtain a list of all current mounts.
- Gather the state of all /proc/scsi/usb-* devices.
- Unmount any listed in (1) that are listed as unattached by (2).
As well as umounting unattached devices, remove their mount-points,
so that any attempt to access them will cause an error.
- Mount any listed as attached in (2) that weren't listed in (1) by
creating generic mount points called usb-device-1, usb-device-2, an so on.
Mount them with the uid option set to the owner of the console.
- As each mount-point is created, optionally create .desktop
files for each mount-point, The .desktop files are created in
the Desktop folder of the console user.
Once a desktop file has been created, further mounts and umounts
will toggle the icon of the desktop file to indicate whether the
mount-point is active.
The uid and console-owner related behavior can be disabled or
hardwired to specific uid's and gids by editing definitions at the
top of the usb-mount script.
By default errors are logged to the syslog at the emerg priority.
On Redhat this will cause a dialog window to pop up.
Here are some desktop screen shots.
The todo list includes Firewire and storage devices with removable media.
I think Firewire might be easy. Devices with removable media might
require the integration of supermount - but I'm not sure because
I don't own such a device (yet).
There are many issues involved with fully automated desktop integration
of USB/Firewire/IEEE1394 drives. As a guide to anyone else
seeking to address this problem, here are the major issues I have encountered,
as well as some notes on how usb-mount addresses them:
- Identifying the right /dev/sd scsi device.
This is not straight forward - its slightly beyond a script.
The sequence /dev/sg does not have to line
up with the sequence /dev/sd[abc] and the alignment
can vary within any uptime period due to devices
coming and going. Sg3_utils
can sort this out.
Identifying the right device can't be easily done in 2.4,
but instead I detect all unmounted usb devices and
mount them all (a hack).
It's possible in 2.6, but needs sg3_utils.
- Identifying the partitions within a device and
choosing mount options based on partition type.
It's not good enough to let mount choose the options,
some file systems, such as NTFS, require special options.
This part of the usb-mount code is dependent on fdisk and
(Thanks to Alessandro Fiorino for figuring out this approach).
- Dealing with completely bogus partition tables.
The widely used operating systems seem to ingore or cope
with completely bogus partition tables on usb-keys - how
should this be detected and delt with on Linux - I have no
idea at this time. But the answer is not to demand that
such devices should not exist.
- Devices with removable media - the device stays the same but the
media changes - currently usb-mount requires you to
issue a "Mount All" from any usb-mount desktop icon to
force device re-evaluation. It would be nice to
use something like submount,
but I don't think submount can automatically handle the situation where
the new media has a different partition layout from
the old media?
- Identifying the desktop owner - who should own the device.
This varies from distro to distro.
The script can be easily changed to accommodate each, but it
would be nice if there was a standard mechanism.
- Getting something visible on the desktop.
I put icons on the desktop by creating files
in the desktop folder (actually the location is configurable).
The KDE desktop automagically displays changes
to the desktop folder - so I don't need to interact with
the desktop system other than creating the files.
- Showing the device status on the desktop.
I change the icon on insert/removal.
The script can optionally remove the icons on
removal. Again the desktop detects the changes
without me having to interact with it.
- Allowing the desktop user to control mount/unmount.
I use sudo to allow limited root access from the
- Notifying the desktop user of problems.
I use the syslog - KDE/Gnome will alert the
user of sufficiently high priority syslog messages,
so I don't have to actually talk to the desktop
system. But perhaps the forwarding of the kernel
or OS messages to the desktop needs a richer mechanism -
perhaps a desktop oriented syslogd would do the trick - or
at least tighter integration of the two - I actually
started down this track three years ago with a modified
syslogd and a ksyslog viewer -
but I never had the time to finish it.
The current /var/log/messages format doesn't help - it doesn't
retain facility and priority, doesn't retain the year.
- Avoid anything too dangerous.
I totally disagree with having to insert fstab entries for
devices that come and go - stuffing up an fstab can
stop a system from functioning.
Labelling and recognition of media. I haven't addressed
the problem of recognising each unique piece of media. I had
originally attempted to do so by using the USB GUID, but see
the following point concerning the GUID.
- Ignore the USB GUID.
I used to use GUID - but it's a disaster area - not all devices have
them, they're not always unique, they're not always constant.
For example: I have a usb key that
reports a GUID based on its USB bus location - so the GUID changes
depending on where it is plugged in - and if I plug two devices
into the same location on two different busses and they wind up with
the same GUID.
Last modified: Wed Jan 25 10:35:02 NZDT 2006