Here we are going to use NFS exported shares with Autofs to automatically mount it. To check the NFS exports just run the below command. # showmount -e 192.168.0.104 Export list for 192.168.0.104: /packages. /database. As we can see above we have two NFS exports i.e. /package and /database. Now create a directory for Autofs to mount the.
One drawback to using /etc/fstab is that, regardless of how infrequently a user accesses the NFS mounted file system, the system must dedicate resources to keep the mounted file system in place. This is not a problem with one or two mounts, but when the system is maintaining mounts to many systems at one time, overall system performance can be affected. An alternative to /etc/fstab is to use the kernel-based automount utility. An automounter consists of two components. One is a kernel module that implements a file system, while the other is a user-space daemon that performs all of the other functions. The automount utility can mount and unmount NFS file systems automatically (on demand mounting) therefore saving system resources. The automount utility can be used to mount other file systems including AFS, SMBFS, CIFS and local file systems.
autofs uses /etc/auto.master (master map) as its default primary configuration file. This can be changed to use another supported network source and name using the autofs configuration (in /etc/sysconfig/autofs) in conjunction with the Name Service Switch mechanism. An instance of the version 4 daemon was run for each mount point configured in the master map and so it could be run manually from the command line for any given mount point. This is not possible with version 5 because it uses a single daemon to manage all configured mount points, so all automounts must be configured in the master map. This is in line with the usual requirements of other industry standard automounters. Mount point, hostname, exported directory, and options can all be specified in a set of files (or other supported network sources) rather than configuring them manually for each host. Please ensure that you have the autofs package installed if you wish to use this service.
Ensure that nfs-utils is installed on the system first before attempting to automount an NFS share. Autofs is also part of the 'Network File System Client' group. Autofs uses /etc/auto.master (master map) as its default primary configuration file. If the share was being mounted via autofs the mount point should be /home/user/Jackknife/Exports and not /home/user/Jackknife. When you access the mount point, autofs should automatically mount the share. You can manually mount the share via the mount command which would indicate that basic nfs is working but be sure to stop autofs service.
Autofs direct maps provide a mechanism to automatically mount file systems at arbitrary points in the file system hierarchy. A direct map is denoted by a mount point of '/-' in the master map. Entries in a direct map contain an absolute path name as a key (instead of the relative path names used in indirect maps).
Multimount map entries describe a hierarchy of mount points under a single key. A good example of this is the '-hosts' map, commonly used for automounting all exports from a host under '/net/' as a multi-mount map entry. When using the '-hosts' map, an 'ls' of '/net/' will mount autofs trigger mounts for each export from and mount and expire them as they are accessed. This can greatly reduce the number of active mounts needed when accessing a server with a large number of exports.
The Lightweight Directory Access Protocol, or LDAP, support in autofs version 5 has been enhanced in several ways with respect to autofs version 4. The autofs configuration file (/etc/sysconfig/autofs) provides a mechanism to specify the autofs schema that a site implements, thus precluding the need to determine this via trial and error in the application itself. In addition, authenticated binds to the LDAP server are now supported, using most mechanisms supported by the common LDAP server implementations. A new configuration file has been added for this support: /etc/autofs_ldap_auth.conf. The default configuration file is self-documenting, and uses an XML format.
The Name Service Switch configuration file exists to provide a means of determining from where specific configuration data comes. The reason for this configuration is to allow administrators the flexibility of using the back-end database of choice, while maintaining a uniform software interface to access the data. While the version 4 automounter is becoming increasingly better at handling the name service switch configuration, it is still not complete. Autofs version 5, on the other hand, is a complete implementation. See the manual page for nsswitch.conf for more information on the supported syntax of this file. Please note that not all nss databases are valid map sources and the parser will reject ones that are invalid. Valid sources are files, yp, nis, nisplus, ldap and hesiod.
One thing that is frequently used but not yet mentioned is the handling of multiple master map entries for the direct mount point '/-'. The map keys for each entry are merged and behave as one map.
An example is seen in the connectathon test maps for the direct mounts below:
The primary configuration file for the automounter is /etc/auto.master, also referred to as the master map which may be changed as described in the introduction section above. The master map lists autofs-controlled mount points on the system, and their corresponding configuration files or network sources known as automount maps. The format of the master map is as follows:
Antidote 9 2 download free. where:
mount-point is the autofs mount point e.g /home.
map-name is the name of a map source which contains a list of mount points, and the file system location from which those mount points should be mounted. The syntax for a map entry is described below.
options if supplied, will apply to all entries in the given map provided they don't themselves have options specified. This behavior is different from autofs version 4 where the options where cumulative. This has been changed to meet our primary goal of mixed environment compatibility.
The following is a sample /etc/auto.master file:
The general format of maps is similar to the master map, however the 'options' appear between the mount point and the location instead of at the end of the entry as in the master map:
where:
is the autofs mount point. This can be a single directory name for an indirect mount or the full path of the mount point for direct mounts. Each direct and indirect map entry key ( above) may be followed by a space separated list of offset directories (sub directory names each beginning with a '/') making them what is known as a mutli-mount entry.
if supplied, are the mount options for the map entries that do not specify their own options.
is the file system location such as a local file system path (preceded with the Sun map format escape character ':' for map names beginning with '/'), an NFS file system or other valid file system location. Mailtags 5 0 0 download free.
The following is a sample map file:
The first column in a map file indicates the autofs mount point (sales and payroll from the server called personnel). The second column indicates the options for the autofs mount while the third column indicates the source of the mount. Following the above configuration, the autofs mount points will be /home/payroll and /home/sales. The -fstype= option is often omitted and is generally not needed for correct operation.
The automounter will create the directories if they do not exist. If the directories exist before the automounter was started, the automounter will not remove them when it exits. You can start or restart the automount daemon by issuing the following command:
Using the above configuration, if a process requires access to an autofs unmounted directory such as /home/payroll/2006/July.sxc, the automount daemon automatically mounts the directory. If a timeout is specified, the directory will automatically be unmounted if the directory is not accessed for the timeout period.
You can view the status of the automount daemon by issuing the following command in your terminal:
18.3.3.1. Overriding or augmenting site configuration files
It can be useful to override site defaults for a specific mount point on a client system. For example, assuming that the automounter maps are stored in NIS and the /etc/nsswitch.conf file has the following directive:
and the NIS auto.master map file contains the following:
Also assume the NIS auto.home map contains the following:
and the file map /etc/auto.home does not exist.
Linux Automount Nfs
For the above example, lets assume that the client system needs to mount home directories from a different server. In this case, the client will need to use the following /etc/auto.master map:
And the /etc/auto.home2 map contains the entry:
Because only the first occurrence of a mount point is processed, /home will contain the contents of /etc/auto.home2 instead of the NIS auto.home map.
Alternatively, if you just want to augment the site-wide
map with a few entries, create a /etc/auto.home file map, and in it put your new entries and at the end, include the NIS auto.home map. Then the /etc/auto.home file map might look similar to:
Given the NIS auto.home map listed above, an ls of /home would now give:
This last example works as expected because autofs knows not to include the contents of a file map of the same name as the one it is reading and so moves on to the next map source in the nsswitch configuration.
LDAP client libraries must be installed on all systems which are to retrieve automounter maps from LDAP. On RHEL 5, the openldap package should be installed automatically as a dependency of the automounter. To configure LDAP access, modify /etc/openldap/ldap.conf. Ensure that BASE and URI are set appropriately for your site. Please also ensure that the schema is set in the configuration.
The most recently established schema for storing automount maps in LDAP is described by rfc2307bis. To use this schema it is necessary to set it in the autofs configuration (/etc/sysconfig/autofs) by removing the comment characters from the schema definition. For example:
How To Configure Autofs
Ensure that these are the only schema entries not commented in the configuration. Please also note that the automountKey replaces the cn attribute in the rfc2307bis schema. An LDIF of a sample configuration is described below:
v4 Multi-map entriesAutofs version 4 introduced the notion of a multi-map entry in the master map. A multi-map entry is of the form:
Any number of maps can be combined into a single map in this manner. This feature is no longer present in v5. This is because Version 5 supports included maps which can be used to attain the same results. Consider the following multi-map example: /home file /etc/auto.home -- nis auto.home
This can be replaced by the following configuration for v5:
/etc/nsswitch.conf must list:
/etc/auto.master should contain:
/etc/auto.home should contain:
Ensure that these are the only schema entries not commented in the configuration. Please also note that the automountKey replaces the cn attribute in the rfc2307bis schema. An LDIF of a sample configuration is described below:
v4 Multi-map entriesAutofs version 4 introduced the notion of a multi-map entry in the master map. A multi-map entry is of the form:
Any number of maps can be combined into a single map in this manner. This feature is no longer present in v5. This is because Version 5 supports included maps which can be used to attain the same results. Consider the following multi-map example: /home file /etc/auto.home -- nis auto.home
This can be replaced by the following configuration for v5:
/etc/nsswitch.conf must list:
/etc/auto.master should contain:
/etc/auto.home should contain:
In this way, the entries from /etc/auto.home and the nis auto.home map are combined.
Multiple master mapsIn autofs version 4, it is possible to merge the contents of master maps from each source, such as files, nis, hesiod, and LDAP. The version 4 automounter looks for a master map for each of the sources listed in /etc/nsswitch.conf. The map is read if it exists and its contents are merged into one large auto.master map.
In version 5, this is no longer the behaviour. Only the first master map found from the list of sources in nsswitch.conf is consulted. If it is desirable to merge the contents of multiple master maps, included maps can be used. Consider the following example:
The above configuration will merge the contents of the file-based auto.master and the NIS-based auto.master. However, because included map entries are only allowed in file maps, there is no way to include both an NIS auto.master and an LDAP auto.master.
This limitation can be overcome by creating a master maps that have a different name in the source. In the example above if we had an LDAP master map named auto.master.ldap we could also add '+auto.master.ldap' to the file based master map and provided that 'ldap' is listed as a source in our nsswitch configuration it would also be included.
Note (2016-07-03): This article still might be interesting if you want tolearn about autofs on Linux, but if you want to share files with a local VM Irecommend readingthis updated article instead.
Autofs Nfs3
There is this really cool feature on Unix systems called autofs. It is reallycrazy, really magical, and really convenient. In a previous life I had tomaintain what is likely the world's most complicated hierarchical autofs setup(distributed in an hierarchical manner across thousands of NetApp filers), so Ilearned a lot about autofs and how it works. In this post though, I'm just goingto explain what it is, why you'd want to use it, and how to set it up.
I'm explicitly going to explain the workflow for using autofs with a local VM,not how to use it in production.
Let's say you're in the habit of doing dev work on a VM. A lot of people do thisbecause they are on OS X or Windows and need to do dev work on Linux. I do itbecause I'm Fedora and need to do dev work on Debian, so I have a VM that runsDebian. You can set up autofs on OS X too. However, I don't use OS X so I can'texplain how to set it up. I believe it works exactly the same way, and it Ithink it's even be installed by default, so I think you can follow this guidewith OS X and it might be even easier. But no guarantees.
Now, there are a lot of ways to set it up so that you can access files on yourVM. A lot of people use sshfs because it'ssuper easy to set up. There's nothing wrong per se with sshfs, but it works viaFUSE and therefore iskind of weird and slow. The slowness is what really bothers me personally.
There's this amazing things calledNFS that has been availableon Unix systems since the 1980s and is specifically designed to be an efficientPOSIX network filesystem. It has a ton of features, you can do tons offine-grained control over your NFS mounts, and the Linux kernel has both nativesupport for being an NFS client and server. That's right, there's an NFSserver in the Linux kernel (there's also a userspace one). So if you're tryingto access remote files on a Linux system for regular work, I highly recommendusing NFS instead of sshfs. It has way higher performance and has beenspecifically designed from day one for Unix systems remotely accessingfilesystems on other Unix systems.
Setting up the NFS Server on Debian
There's one package you need to install, nfs-kernel-server. To install it:
Now you're going to want to set this up to actually run and be enabled bydefault. On a Debian Jessie installation you'll do:
If you're using an older version of Debian (or Ubuntu) you'll have to futz withthe various legacy systems for managing system startup service e.g.by usingUpstart or update-rc.d.
Great, now you have an NFS server running. You need to set it up so that otherpeople can actually access things using it. You do this by modifying the file/etc/exports. I have a single line in mine:
This makes it possible for any remote system on the 192.168.124.0/24 subnetpossible to mount /home/evan with read/write permissions on my server withoutany authentication. Normally this would be incredibly insecure, but the defaultway that Linux virtualization works with libvirt is that 192.168.124.0/24 isreserved for local virtual machines, so I'm OK with it. In my case I know thatonly localhost can access this machine, so in my case it's only insecure insofaras if I give someone else my laptop they can access my VM.
Please check your network settings to verify that remote hosts on your networkcan't mount your NFS export since if they can you've exposed your NFS mount toyour local network. Your firewall may already disable NFS exports by default, ifnot just change the host mask. There are also ways to set up NFS authentication,but you shouldn't need to do that just to use a VM and that topic is outside thescope of this blog post.
Now reload nfs-kernel-server so it knows about the new export:
Update: It waspointed out to methat if you're accessing the VM from OS X you have to use high ports forautomounted NFS, meaning that in the /etc/exports file on the guest VM you'llneed to add 'insecure' as an export option.
Setting up the NFS Client on Debian/Fedora
On client you'll need the autofs package. On Fedora that will be:
and on Debian/Ubuntu it will be
I think it's auto-installed on OS X?
Again, I'm going to assume you're on a recent Linux distro (Fedora, or a modernDebian/Ubuntu) that has systemd, and then you'll do:
Before we proceed, I recommend that you record the IP of your VM and put it in/etc/hosts. There's some way to set up static networking with libvirt hosts,but I haven't bothered to figure it out yet, so I just logged into the machineand recorded its IP (which is the same every time it boots). On my system, in my/etc/hosts file I added a line like:
So now I can use the hostname d8 as an alias for 192.168.124.252. You canverify this using ssh or ping.
Due to some magic that I don't understand, on modern NFS systems there's a wayto query a remote server and ask what NFS exports it knows about. You can querythese servers using the showmount command. So in my case I now see:
This confirms that for the host alias d8 I added that the host is actuallyexporting NFS mounts in the way I expect. If you don't have a showmountcommand you may need to install a package called nfs-utils to get it.
Actually Using Autofs
Now here's where it gets magical.
When you do any filesystem operation (e.g. change directory, open a file, list adirectory, etc.) that would normally fail with ENOENT, the kernel checks ifthat file should have been available via autofs. If it is, it will mount thefilesystem using autofs and then proceed with the operation as usual.
This is really crazy if you think about it. Literally every filesystem relatedsystem call has logic in it that understands this autofs thing and cantransparently mount remote media (which doesn't just have to be NFS, this usedto be how Linux distros auto-mounted CD-ROMs) and then proceeds with theoperation. And this is all invisible ot the user.
There's a ton of ways to configure autofs, but here's the easiest way. Your/etc/auto.master file will likely contain a file like this already (if not,add it):
Autofs Nfs
This means that there is a magical autofs directory called /net, which isn't areal directory. And if you go to /net//mnt/point then it willautomatically NFS mount /mnt/point from on your behalf.
If you want to be really fancy you can set /etc/auto.masster to use a timeout,e.g.:
So here's what I do. I added a symlink like this:
So now I have an 'empty' directory called ~/d8. When I start up my computer, Ialso start up my local VM. Once the VM boots up, if I enter the ~/d8 directoryor access data in it, it's automatically mounted! And if I don't use thedirectory, or I'm not running the VM, then it's just a broken symlink.
This solves a major problem with the conventional way you would use NFS with aVM. Normally what you would do is you'd have a line in /etc/fstab that has thedetails of the NFS mount. However, if you set it up to be automatically mounted,you have a problem where your machine will try to mount the VM before the VM isfinished booting. You can use the user option in your /etc/fstab optionsline which lets you subsequently mount the VM NFS server without being root, butthen you have to manually invoke the mount command once you know the VM isstarted.
By using autofs, you don't ever need to type the mount command, and you don'teven need to change /etc/fstab. I recommend editing /etc/hosts because it'sconvenient, but you don't need to do that either. I could have just as easilyused /net/192.168.124.252/home/evan and not created a hosts entry.
