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.
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!
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.
I could not locate any information regarding this.Please let me know if you come across anything.