6.12 where to contact the developpers" ?.Is there a mailing-list for autofs ?
- Versions below 1.5 - Authored by Don.
- Version 1.5 - Added the copyright and other minor details.Rahul Sundaram took over maintainance.
- Version 1.5.1 - Added details to the question about VFAT.
- Version 1.5.2 - Revision history and other minor corrections.
- Version 1.6 - Added a few questions and answers.
Automounting is the process where mounting and unmounting of certain
filesystems is done automatically by a daemon. If the filesystem is unmounted,
and a user attempts to access it, it will be automatically (re)mounted. This
is especially useful in large networked environments and for crossmounting
filesystems between a few machines (especially ones which are not always
online). It may also be very useful for removable devices, or a few other
uses, such as easy switching between a forced-on ascii conversion mount of
a dos filesystem and a forced-off ascii conversion mount of the same dos fs.
If you are new to Linux and dont understand what mounting and deamons are,then refer to
some documentation regarding this.
There are two types of automounters in linux; AMD and autofs. AMD is the
automount daemon, and supposedly works like the SunOS AMD. It is implemented in user space, meaning it's not part of the kernel. It's not necessary for the kernel to understand automounting if you NFS mount to the local host, through the AMD daemon, which routes all automount filesystem traffic through the NFS system. Autofs is a newer system assisted by the kernel, meaning that the kernel's filesystem code knows where the automount mount points are on an otherwise normal underlying fs, and the automount program takes it from there. Only autofs will be described in this mini-howto.
This mini-HOWTO is Copyright Rahul Sundaram Sundaram.All rights reserved.This document is licensed under
the
Linux Documentation Project license.I welcome any kind of commercial distrubution but I would like to receive information regarding this.I would
also help anyone willing to translate this document.If you require any exceptions to the licensing terms
please contact me
Rahul Sundaram. The latest version of this document is always available at the Linux Documentation
website at
http://tldp.org/HOWTO/mini/Automount.html.
Although I have tried to do my best to bring out this howto in a good form,I am
not responsible for any damage due to the actions taken based upon the
information contained in this document. It is impossible to test the
things under all the configurations, so probably some of the hints given
in this document may be incorrect and may not work on your system. In case you
find anything wrong, let me know it first.I will rewrite it as soon as possible.
This document is provided ``as is''. I put great effort into writing
it as accurately as I could, but you use the information contained in
it at your own risk. In no event shall I be liable for any damages
resulting from the use of this work.
Autofs is implemented in kernel-space, so your kernel must have support compiled in. All versions of the kernel starting from 2.2.xx supports autofs.
The automount program and its configuration files are also necessary; using the rpms. The RedHat distribution has this package available as part of the installation.
Installing the RPM packages will get you to this point easily enough, but here's the part you might not be sure about if you haven't done this before.
There are two files in /etc, one called auto.master and one called auto.misc.
A sample auto.master looks like this:
/auto /etc/auto.misc --timeout=60
The first entry is not the mount point. It's where the set of mount points
(found in the second entry) are going to be. The third option says that the
mounted filesystems can try to unmount themselves 60 seconds after use. You will have to
stop using the disk before unmounting it.
Auto.misc is a "map file". The map file can have any name; this one is named auto.misc because it originally controlled /misc. Multiple map files can be defined in auto.master.
My auto.misc looks like this:
kernel -ro,soft,intr ftp.kernel.org:/pub/linux
cd -fstype=iso9660,ro :/dev/cdrom
zip -fstype=auto :/dev/hdd4
floppy -fstype=vfat :/dev/fd0
The first column (the "key") is the mount point. In this case it would be
/auto/floppy or whatever. The middle set are the options; read the mount
manpage for details on this. And the last column specifies where the fs
comes from. The "kernel" entry is supposed to be an NFS mount. The : on all
the other lines means its a local device.
Some of you may be eyeing that 60 second timeout and thinking, that's a long
time to wait to eject a floppy.. Maybe I'll just sync the disks and pop
it out mounted and nobody will notice. Let me suggest saner alternatives.
First of all, you can change the timeout. But that could be a little
inefficient; telling the system to unmount stuff after only 15 seconds or
whatever. Depending on your setup, you may be able to simply run the umount
command as a normal user. But there is actually a way to ask the automount program to umount.
If you send (with the program kill) the signal SIGUSR1 to the automount process,
it will unmount everything it can. But before people start making unmount
buttons on their window managers, there's a little problem.
The automount process is run by root, and it will only accept signals from
root. Half of the reason you're probably doing automounting is so you can
mount and unmount without being root. It would be easy to make a suid-root
C program which does the dirty deed. However, by using sudo it is possible
to allow users to send the proper kill signal. The only problem is that
sudo will not let you use to process subcommands, which you would have to
do to find the current PID. You should have a program called killall, which
will let you do this:
ALL ALL=NOPASSWD:/usr/bin/killall -USR1 automount
Otherwise, you would have to allow your users to send -SIGUSR1 to all processes.
That has various effects on programs; it will recycle some window managers,
but kills xemacs. So here's hoping there's no buffer overruns in killall...
If automount is setup properly, whatever mount point you're looking for will be there if you try and use it, even though you don't see it when not in use. If you're browsing the directory with a
graphical tool, you may need to type in the name manually; most programs will try what you give it, and the drive will be mounted before it notices. Unfortunately not
being able to choose from the available invisible mount points is probably the
major drawback of autofs. If it really bugs you, edit the configuration files.
(Hint, the ones that end in .c for "configuration")
One workaround several people have tried is to create symbolic links to where automount will create something once it's mounted. This will likely prevent the program from complaining a directory doesn't exist (if the mount works, that is) but careless directory listings will cause filesystems to be mounted.
The df command. mount with no options will do the same, plus show the options its mounted with.
This is not a problem with automount.The "auto" fs type does not attempt a vfat mount before it successfully mounts an MS-DOS filesystem. VFAT is an extension of the basic FAT filesystem inorder to provide Windows 95 and Windows NT with long filenames.
According to one of the authors of mount, since mount is only a wrapper around a system call which must specify the filesystem type, it's still the responsibility of the user to come up with the fs type. Having mount take a list of filesystems to try in order, rather than the current "heuristic" is under consideration. Some users have simply not compiled msdos into the kernel; this prevents it from being tested prior to vfat. This will work for most people; a few actually need msdos fs and there is actually a work around.
You have to copy the /proc/filesystems as /etc/filesystems and edit it to change the order such that vfat appears before msdos.(Thanks Mark)
Ariel(aslinux At dsgml.com) writes
"
o make mount try vfat before fat, just create or edit the file
/etc/filesystems
List, in order of priority, what filesystems you want the 'auto' fs
type
to try.
Create the file with cp /proc/filesystems /etc/filesystems.
Edit the list to change the order. Put fs types that are detected with
great confidence such as ext2 (which means they are checked very
quickly),
and those that are more common for you first. Just put vfat before
msdos
and you're all set. Make sure to put both, in case you're mounting
something that has no vfat.
Mine looks like:
ext2
vfat
msdos
iso9660
****
I use a timeout of 1 second for removable devices. Create separate
maps, separated by the timeout you need.
You're thinking 1 second? That wastes a lot of resources - but it
doesn't.
Remember that the system only unmounts when it's no longer in use.
So a 1 second unmount means, as soon as no one is using the device,
it's
unmounted.
Also, be very sure to put 'sync' as an option for the floppy!
i.e.
floppy -fstype=auto,sync,user,umask=002,gid=floppy :/dev/fd0"
That should make clear the answer.
It's being used by something. Root probably can't manually unmount it
either. If you're the one who caused it to be mounted (i.e. it can't be someone
else using it) look around for a shell that might be in that directory. If
there are none, look for something else (particularly something that might
have gone though that directory like a directory browser) that might have left
an invisible foot in the door so to speak. If you've given up looking, try
using the fuser program.
I dont recommend it.If you want /grumblesmurf, then I suggest a symbolic link. It would be much safer.
Not as far as I know. Try using one map file, with specific options for individual entries.
Another solution to "timeout not working" problems would be to add a -t time option to the autofs script.
Check the man page for mount for some of the options, such as setting the uid=value or umask=value options. One option that appears to be missing for FAT filesystems is mode=value. Sorry. Check in with the people who do mounting.
This is only a documentation provided for you to grab everyone's attention to what a great
job had been done with autofs, and howeasy it is to use.Compared to the original perpetrators
of AMD,the autofs is very well documented and the implementors have my sincere thanks.
Everything has been copyrighted by the Transmeta company so it's not possible to provide
a credits list, but Peter Anvin is probably responsible for quite a bit of it. Peter also held
a session on autofs at linuxworldexpo on March 3, 1999.
There's a autofs tutorial at
http://www.linuxhq.com/lg/issue24/nielsen.html.
See also am-utils at
http://www.cs.columbia.edu/~ezk/am-utils
I could not locate any information regarding this.Please let me know if you come across anything.
I would like to thank
Don (email id seems to be invalid now) for his original work on this mini-Howto.I thank Ariel for his
answer regarding the question on "win95 vfat" issue.I would thank all my friends for their support and everyone who were patient enough with me while I completed this work.
Please mail me to
Rahul Sundaram in case of any suggestions,improvements or if you have any bright ideas.
Please mail me if you have any good tutorials or stuff that I can add to this document.Thanks in advance.
I dedicate this document to my late parents Mr.V.Sundaram and Mrs.S.Soundara Sundaram.
