funmount forcibly attempts to unmount the file system
mounted on path. It is roughly equivalent to running
umount -f path. However, on most operating systems the
umount command does a great deal more than simply execute
the unmount system call(--for instance it may attempt to read
the attributes of the file system being unmounted and/or contact a
remote NFS server to notify it of the unmount operation. These extra
actions make umount hang when a remote NFS server is
unavailable or a loopback server has crashed, which in turn causes the
client to become ever more wedged. funmount can avoid such
situations when you are trying to salvage a machine with bad NFS
mounts without rebooting it.
CAVEATS
SFS will get very confused if you ever unmount file systems from
beneath it. SFS's nfsmounter program tries to clean up the
mess if the client software ever crashes. Running funmount
will generally only make things worse by confusing
nfsmounter.
The full documentation for SFS is maintained as a Texinfo
manual. If the info and SFS programs are properly installed
at your site, the command info SFS
should give you access to the complete manual.
For updates, documentation, and software distribution, please
see the SFS website at http://www.fs.net/.
BUGS
If /a is a mount point, and /a/b is another mount point,
unmounting /a before /a/b will cause the latter file
system to become ``lost.'' Once a file system is lost, there is no
way to unmount it without rebooting. Worse yet, on some operating
systems, commands such as df may hang because of a lost file
system.
Many operating systems will not let you unmount a file system (even
forcibly) if a process is using the file system's root directory (for
instance as a current working directory). Under such circumstances,
funmount may fail. To unmount the file system you must find
and kill whatever process is using the directory. Utilities such as
fstat and lsof may be helpful for identifying
processes with a particular file system open.
