Using the automounter to mount the user's home directory at login is inviting especially if the user account is a network (NIS, LDAP) account. This is more convenient if you use a special capability of the automounter, to specify a line in the home directory's indirect map to mount any directory beneath a mount point. Using the automounter to mount the user's home directory at login is inviting especially if the user account is a network (NIS, LDAP) account. This is more convenient if you use a special capability of the automounter, to specify a line in the home directory's indirect map to mount any directory beneath a mount point. SYSTEMD.AUTOMOUNT(5) systemd.automount SYSTEMD.AUTOMOUNT(5) NAME top systemd.automount - Automount unit configuration SYNOPSIS top automount.automount.
By Joey Prestia
In a Windows networked environment, you can go to any machine, log in tothe system, and have access to your home directories and files on theserver. This seems like a convenience until you realize that in doingthis, the server and the client machines are eating up resources by keepingall network shares hard-mounted at all times. The Linux solution to this isthe autofs daemon known as the automounter.
In the past, Linux networks would have various types of Network File System(NFS) servers being utilized in different ways: some for network backup,some exporting users' Network Information Service (NIS) mapped directories,and some exporting other network resources. One of the problems was that booting a system that used traditional fstab-based mounts whilethe NFS server was down could be a long process: it would take a long timeto come up as it waited for the server to time out. Similarly, when youhave two servers, each mounting directory hierarchies from the other, andboth systems are down, both may hang as they are brought up (this is called server-server dependency). The automount facility getsaround these issues by mounting a directory hierarchy from another systemonly when a process tries to access it. [1] If a client attempts a hard mount andthe server is unavailable, then the Linux kernel treats the process as itwould if a local drive's file system was unavailable. The user can donothing until the server becomes available; the process is in anun-interruptible sleep until the server is back on line. Often, the processcan't even be killed, and a 'ps aux' command will reveal a 'D' state.
[ For anyone not familiar with 'ps' output, 'D' means 'Uninterruptiblesleep (usually IO)'. For more information, please see the 'PROCESS STATECODES' section in 'man ps'. -- Ben ]
Automounting is the process where the mounting and unmounting of filesystems is done automatically by the autofs service. If the filesystem isunmounted, and a user attempts to access it, it will be automaticallymounted or re-mounted. Using the automounter saves on resources by mountinga directory only when you need to enter it, then unmounting itautomatically when you don't need it anymore. This is usually done after adefault timeout (usually 300 seconds) that is specified in the/etc/sysconfig/autofs file, the main configuration file for this service.The other configuration files are located in the /etc directory and arecalled auto.master, auto.misc, auto.net, and auto.smb. The last twoare executable scripts.
Let's say we have some NFS directories and our company's employees are onlytrained in use of the GNOME desktop environment; they could use theautomounter if you were to set up the configuration files and copy them totheir machines. They would be able to point and click their way around, andthe remote file systems would do the right thing, invisibly. Using theautomounter is not restricted to the console.
Procedure:
- Verify that /etc/sysconfig/autofs options will accommodate your particular needs(i.e., browse mode and timeouts)
- Modify /etc/auto.master as appropriate
- Create any /etc/auto.files that were referenced in /etc/auto.master
- Start or restart the autofs service
- Change into the appropriate directory
/etc/sysconfig/autofs
Let's check out the configuration files. (Note: this guide waswritten using RHEL 5.1, so other distributions may differ slightly in someaspects.) The main configuration file, '/etc/sysconfig/autofs', has thetimeout for mounts defined as 300 seconds (or five minutes) of inactivity,and the default browse mode set to 'no'; this prevents shares that are notbeing directly referenced from being automounted. There are lots of otherconfigurable options for different setups, so it is worth your time to readthrough this file just so you know what is in there. Look particularly closelyat any uncommented directives.
/etc/auto.master
'auto.master', contains three uncommented lines:
The first line means that the configured devices in auto.misc will bemounted in the '/misc' directory; the second one means that the exportsfrom the network hosts will be mounted in '/net'. '+auto.master' is areference to an external NIS or NIS+ master map. Entries in this fileconsist of a mount point followed by the path to a file which defines thedetails and the options of what will be mounted where. You can callthe files anything you want, or whatever suits the need. The followingentries would be valid:
Audiobook converter. We would then create the file that we referenced in the auto.master and define the mount details in it.
It is also useful to consider mounting the users' remote home directoriesin a non-standard location (e.g., '/rhome/username' or'/export/home/username'.) This would be considered a violation of the FHS(Filesystem Hierarchy Standard), since the mount point is located in theroot of the filesystem; on the other hand, it's only a temporary directory,created and destroyed by the autofs daemon as necessary. The advantages areobvious: you get to have access to the content of your '/home/username'directory as well as the remote one, and you get to keep the use of the/mnt mount point for other devices or shares.
/etc/auto.file
This is the file that you create for your custom automounts. The auto.files would have three columns in them:
The 'key' is the subdirectory under the mount point that you listed in theauto.master file. As an example, if in our auto.master we had thefollowing:
We would then create, for example, the /etc/auto.remote file with our desired options:
Once we restart the autofs service, changing to the /mnt/remote/recordsdirectory will create the demand for the exported resourceserver1.example.com:/srv/nfs/medical/records to be mounted on/mnt/remote/records. It is important to note that if you use host names(rather than IPs) and don't have DNS available, you will need an entry in/etc/hosts that maps the hostname to the IP address.
The following example uses wildcard substitution. Placing an asterisk in thekey field and an ampersand at the end of the location or device path fieldwill map the end of the location path (directory structure and files) towhatever is found at the location. In the example below, the entire remotehome directory structure located on server1.example.com:/home/username would berecreated when the user attempts to log in. By using this technique, a usercould log into any machine and have their home directory mappedappropriately.
/etc/auto.misc
The /etc/auto.misc file contains a lot of sample configurations forautomounting various types of devices; to use one of these, merelyuncomment a specific line in this file and adjust the appropriate deviceaccordingly. But just as different machines have different hardwareconfigurations, different distros may have different setups so a littlecustomization will probably be necessary.
Most distros now automatically mount USB devices under the /mediadirectory and several of the devices listed above are fading away - butthere is still some use for this file. It can be configured in a multitudeof ways, e.g. to automount partitions that you don't need to have mountedat all times (backup devices are just one example). A good way to getfamiliar with this file is to come up with a configuration scenario and putit into practice. For example, try mounting a USB flash drive with theautomounter and setting up different configurations until you get familiarwith it. Remember to always back up the original file before making anychanges.
Suppose we want to be able to automount the NFS share on the network serverinstead of, say, manually typing 'mount -t nfs192.168.0.254:/var/ftp/pub/directory/subdirectory /mnt'.) In this case, wewould just need the hostname of the machine with the exported filesystem(if there is an entry in DNS) or the IP address of the machine. The'showmount -e hostname' or 'showmount -e IP_address' command can be usedto discover what directories a host has exported by NFS. Example:'showmount -e 192.168.0.254' will display the exports for that host.
/etc/auto.net
The auto.net file is an executable script which searches foravailable NFS shares to mount; the NFS service must be running for the auto.net script to be able to connect to remote shares. To invoke this ability, you need to ensure that the autofs and NFS services are running:
Since they are stopped, we start the service with the 'service' command, and ensure that they stay on through a reboot by using the 'chkconfig' command on Red Hat based systems.
The 'chkconfig' arguments just ensure that this service will remain onthrough a reboot in runlevels 3 and 5. Now we can see if any network serverexports are available. First, we'll go to /net; assuming that our serverwith the NFS export is 'server1' and has a DNS entry, we could execute thefollowing:
or, if we know the IP address of the machine, this would work:
The directory magically appears - but if we didn't know the machine'shostname or IP address, we would not be able to find it. The automounterdoes not list directories unless they have been accessed, so unless a userknows what to access they will not be able to blindly find it. This suremakes mounting NFS shares a lot easier - and you don't have to remember tomanually unmount them!
As an exercise to see this work on our machine, let's execute the following commands.
We've exported our /var/www/html directory as a read/write NFSexport to our loopback IP address just to try this (in case you're not in a networked environment). Don't forget to remove the line in /etc/exports that we echoed into the file when you are done checking out the network mounting capabilities. Do note that typing 'mount' at the command line will not show what is mounted by the automounter: you will have to execute a 'cat /proc/mounts' to see what is currently mounted by the autofs daemon.
/etc/auto.smb
The default auto.smb file is also an executable script, and the use of itmay require the Samba servername/username/password, or that a credentialsfile be specified for your particular setup. You can also use the guideincluded with your Samba documentation, as I did, to create your ownauto.smb file; it follows the same format as the auto.misc file.If you want to automount Samba shares, you may want to just go ahead andcreate your own configuration file customized for your own needs. Justremember to back up the original file if you're not going to use theexecutable.
The automounter will work with NFS exports, Samba, NIS, NIS+, LDAP, andvarious other devices, not to mention being scriptable and veryconfigurable. In this article, I've just touched on the basics verybriefly; don't forget to read the autofs(5) man page, since it has someinteresting concepts. Also, be sure to consult it when setting upautomounting, as well as any other distro-specific documentation whenconfiguring the automounter to meet your needs.
Resources
- Michael Jang's book 'Red Hat Certified Engineer Linux Study Guide', Fifth Edition
- Mark G. Sobell's book 'A Practical Guide to Red Hat Linux' Third Edition
[1] Taken from Mark G. Sobell's book 'A Practical Guide to Red Hat Linux' Third Edition, page 691
Talkback: Discuss this article with The Answer Gang
Joey was born in Phoenix and started programming at the age fourteen on a Timex Sinclair 1000. He was driven by hopes he might be able to do something with this early model computer. He soon became proficient in the BASIC and Assembly programming languages. Joey became a programmer in 1990 and added COBOL, Fortran, and Pascal to his repertoire of programming languages. Since then has become obsessed with just about every aspect of computer science. He became enlightened and discovered RedHat Linux in 2002 when someone gave him RedHat version six. This started off a new passion centered around Linux. Currently Joey is completing his degree in Linux Networking and working on campus for the college's RedHat Academy in Arizona. He is also on the staff of the Linux Gazette as the Mirror Coordinator.
Copyright © 2008, Joey Prestia. Released under the Open Publication Licenseunless otherwise noted in the body of the article. Linux Gazette is notproduced, sponsored, or endorsed by its prior host, SSC, Inc.
Published in Issue 155 of Linux Gazette, October 2008
You need to configure autofs manually by editing its configuration files with a text editor, such as vim. There are two basic steps to configure autofs—the master map file, and specific map files.
The default master configuration file for autofs is /etc/auto.master. You can change its location by changing the value of the DEFAULT_MASTER_MAP_NAME option in /etc/sysconfig/autofs. Here is the content of the default one for SUSE Linux Enterprise Server:
The |
Although commented out (#) by default, this is an example of a simple automounter mapping syntax. |
In case you need to split the master map into several files, uncomment the line, and put the mappings (suffixed with |
|
Entries in auto.master have three fields with the following syntax:
/etc/auto.file
This is the file that you create for your custom automounts. The auto.files would have three columns in them:
The 'key' is the subdirectory under the mount point that you listed in theauto.master file. As an example, if in our auto.master we had thefollowing:
We would then create, for example, the /etc/auto.remote file with our desired options:
Once we restart the autofs service, changing to the /mnt/remote/recordsdirectory will create the demand for the exported resourceserver1.example.com:/srv/nfs/medical/records to be mounted on/mnt/remote/records. It is important to note that if you use host names(rather than IPs) and don't have DNS available, you will need an entry in/etc/hosts that maps the hostname to the IP address.
The following example uses wildcard substitution. Placing an asterisk in thekey field and an ampersand at the end of the location or device path fieldwill map the end of the location path (directory structure and files) towhatever is found at the location. In the example below, the entire remotehome directory structure located on server1.example.com:/home/username would berecreated when the user attempts to log in. By using this technique, a usercould log into any machine and have their home directory mappedappropriately.
/etc/auto.misc
The /etc/auto.misc file contains a lot of sample configurations forautomounting various types of devices; to use one of these, merelyuncomment a specific line in this file and adjust the appropriate deviceaccordingly. But just as different machines have different hardwareconfigurations, different distros may have different setups so a littlecustomization will probably be necessary.
Most distros now automatically mount USB devices under the /mediadirectory and several of the devices listed above are fading away - butthere is still some use for this file. It can be configured in a multitudeof ways, e.g. to automount partitions that you don't need to have mountedat all times (backup devices are just one example). A good way to getfamiliar with this file is to come up with a configuration scenario and putit into practice. For example, try mounting a USB flash drive with theautomounter and setting up different configurations until you get familiarwith it. Remember to always back up the original file before making anychanges.
Suppose we want to be able to automount the NFS share on the network serverinstead of, say, manually typing 'mount -t nfs192.168.0.254:/var/ftp/pub/directory/subdirectory /mnt'.) In this case, wewould just need the hostname of the machine with the exported filesystem(if there is an entry in DNS) or the IP address of the machine. The'showmount -e hostname' or 'showmount -e IP_address' command can be usedto discover what directories a host has exported by NFS. Example:'showmount -e 192.168.0.254' will display the exports for that host.
/etc/auto.net
The auto.net file is an executable script which searches foravailable NFS shares to mount; the NFS service must be running for the auto.net script to be able to connect to remote shares. To invoke this ability, you need to ensure that the autofs and NFS services are running:
Since they are stopped, we start the service with the 'service' command, and ensure that they stay on through a reboot by using the 'chkconfig' command on Red Hat based systems.
The 'chkconfig' arguments just ensure that this service will remain onthrough a reboot in runlevels 3 and 5. Now we can see if any network serverexports are available. First, we'll go to /net; assuming that our serverwith the NFS export is 'server1' and has a DNS entry, we could execute thefollowing:
or, if we know the IP address of the machine, this would work:
The directory magically appears - but if we didn't know the machine'shostname or IP address, we would not be able to find it. The automounterdoes not list directories unless they have been accessed, so unless a userknows what to access they will not be able to blindly find it. This suremakes mounting NFS shares a lot easier - and you don't have to remember tomanually unmount them!
As an exercise to see this work on our machine, let's execute the following commands.
We've exported our /var/www/html directory as a read/write NFSexport to our loopback IP address just to try this (in case you're not in a networked environment). Don't forget to remove the line in /etc/exports that we echoed into the file when you are done checking out the network mounting capabilities. Do note that typing 'mount' at the command line will not show what is mounted by the automounter: you will have to execute a 'cat /proc/mounts' to see what is currently mounted by the autofs daemon.
/etc/auto.smb
The default auto.smb file is also an executable script, and the use of itmay require the Samba servername/username/password, or that a credentialsfile be specified for your particular setup. You can also use the guideincluded with your Samba documentation, as I did, to create your ownauto.smb file; it follows the same format as the auto.misc file.If you want to automount Samba shares, you may want to just go ahead andcreate your own configuration file customized for your own needs. Justremember to back up the original file if you're not going to use theexecutable.
The automounter will work with NFS exports, Samba, NIS, NIS+, LDAP, andvarious other devices, not to mention being scriptable and veryconfigurable. In this article, I've just touched on the basics verybriefly; don't forget to read the autofs(5) man page, since it has someinteresting concepts. Also, be sure to consult it when setting upautomounting, as well as any other distro-specific documentation whenconfiguring the automounter to meet your needs.
Resources
- Michael Jang's book 'Red Hat Certified Engineer Linux Study Guide', Fifth Edition
- Mark G. Sobell's book 'A Practical Guide to Red Hat Linux' Third Edition
[1] Taken from Mark G. Sobell's book 'A Practical Guide to Red Hat Linux' Third Edition, page 691
Talkback: Discuss this article with The Answer Gang
Joey was born in Phoenix and started programming at the age fourteen on a Timex Sinclair 1000. He was driven by hopes he might be able to do something with this early model computer. He soon became proficient in the BASIC and Assembly programming languages. Joey became a programmer in 1990 and added COBOL, Fortran, and Pascal to his repertoire of programming languages. Since then has become obsessed with just about every aspect of computer science. He became enlightened and discovered RedHat Linux in 2002 when someone gave him RedHat version six. This started off a new passion centered around Linux. Currently Joey is completing his degree in Linux Networking and working on campus for the college's RedHat Academy in Arizona. He is also on the staff of the Linux Gazette as the Mirror Coordinator.
Copyright © 2008, Joey Prestia. Released under the Open Publication Licenseunless otherwise noted in the body of the article. Linux Gazette is notproduced, sponsored, or endorsed by its prior host, SSC, Inc.
Published in Issue 155 of Linux Gazette, October 2008
You need to configure autofs manually by editing its configuration files with a text editor, such as vim. There are two basic steps to configure autofs—the master map file, and specific map files.
The default master configuration file for autofs is /etc/auto.master. You can change its location by changing the value of the DEFAULT_MASTER_MAP_NAME option in /etc/sysconfig/autofs. Here is the content of the default one for SUSE Linux Enterprise Server:
The |
Although commented out (#) by default, this is an example of a simple automounter mapping syntax. |
In case you need to split the master map into several files, uncomment the line, and put the mappings (suffixed with |
|
Entries in auto.master have three fields with the following syntax:
The base location where to mount the autofs file system, such as /home.
The name of a map source to use for mounting. For the syntax of the maps files, see Section 36.2.2, 'Map Files'.
These options (if specified) will apply as defaults to all entries in the given map.
Tip: For More Information For more detailed information on the specific values of the optional map-type, format, and options, see the auto.master manual page (man 5 auto.master).
The following entry in auto.master tells autofs to look in /etc/auto.smb, and create mount points in the /smb directory.
Direct mounts create a mount point at the path specified inside the relevant map file. Instead of specifying the mount point in auto.master, replace the mount point field with /-. For example, the following line tells autofs to create a mount point at the place specified in auto.smb:
If the map file is not specified with its full local or network path, it is located using the Name Service Switch (NSS) configuration:
Automounter Dmg
Important: Other Types of Maps Although files are the most common types of maps for auto-mounting with autofs, there are other types as well. A map specification can be the output of a command, or a result of a query in LDAP or database. For more detailed information on map types, see the manual page man 5 auto.master.
Map files specify the (local or network) source location, and the mount point where to mount the source locally. The general format of maps is similar to the master map. The difference is that the options appear between the mount point and the location instead of at the end of the entry:
Make sure that map files are not marked as executable. You can remove the executable bits by executing chmod -x MAP_FILE.
Specifies where to mount the source location. This can be either a single directory name (so-called indirect mount) to be added to the base mount point specified in auto.master, or the full path of the mount point (direct mount, see Section 36.2.1.1, 'Direct Mounts').
Specifies optional comma-separated list of mount options for the relevant entries. If auto.master contains options for this map file as well, theses are appended.
Automounter
Specifies from where the file system is to be mounted. It is usually an NFS or SMB volume in the usual notation host_name:path_name. If the file system to be mounted begins with a '/' (such as local /dev entries or smbfs shares), a colon symbol ':' needs to be prefixed, such as :/dev/sda1.
