{"id":310,"date":"2020-08-18T19:23:47","date_gmt":"2020-08-18T20:23:47","guid":{"rendered":"http:\/\/www.linux-tutorial.info\/?page_id=77"},"modified":"2020-08-22T19:25:16","modified_gmt":"2020-08-22T20:25:16","slug":"this-is-the-page-title-toplevel-145","status":"publish","type":"page","link":"http:\/\/www.linux-tutorial.info\/?page_id=310","title":{"rendered":"Automount"},"content":{"rendered":"\nAutomount<\/title>\n<question id=\"396\" text=\"What is the term user for the ability to mount NFS shares without having to issue the mount command?\" \/>\n<question id=\"397\" text=\"What program provides you with the ability to mount NFS filesystems only when you need them?\" \/>\n<question id=\"\" type=\"mc\" text=\"What is the purpose of the NFS automounter?\" \/>\n<p>\nIf you are used to later versions of Windows, you certainly know how nice it is to be able to\naccess files on remote systems without having to explicitely <glossary>mount<\/glossary>\nthem each time.\nOccassionally, I get comments from Windows fans that the lack of this feature in Linux is\none of it’s major shortcoming. Well, that would be true, if Linux was missing this functionality.\nIn fact, this feature has been available for <glossary>UNIX<\/glossary>\nlonger than Windows NT has been around and\nhas been with Linux from the beginning. This is called “automount” or “<glossary>automounter<\/glossary>“.\n<p>\nIn order to be able to <glossary>mount<\/glossary> a remote <glossary>filesystem<\/glossary>\nusing <command>automount<\/command>, you would first need to be able to <glossary>mount<\/glossary>\nit using normal <glossary>NFS<\/glossary>. That is to say that there are no flags that you\ncan set on the remote side (where the <glossary>filesystem<\/glossary>\nis being exported) that says either to explicitly allow or deny\naccess via automount. The remote filesystem\nsimply makes a resource available and you access it with whatever tool you see fit.\nTherefore, for the purpose of this discussion, we are going to simply\nassume that in each case, the remote <glossary>host<\/glossary>\nhas given us permission to access that filesystem.\nFor more details, see the <site id=\"151\">previous section on NFS configuration<\/site>.\n<\/p>\n<p>\nThe <command>amd<\/command> program provides you with the ability to <glossary>mount<\/glossary>\n<glossary>NFS<\/glossary> filesystems only when you need them, automatically. They are\nautomatically mounted by automount, hence the name. Actually, conventional NFS mounted filesystems\ncan also be mounted automatically in the sense that you can configure them in <file type=\"fstab\">\/etc\/fstab<\/file> and they\nare automatically mounted as the system boots. Automount filesystems, on the other hand, are first mounted\nwhen a user tries to access files or directories under the <glossary>mount<\/glossary>\npoint. Also, if the files or\ndirectories are not accessed within a specific time, (five minutes by default) they are unmounted,\nthereby saving <glossary>network<\/glossary>\nresources. When booting you could also save time since the system might be waiting to\nconnect to a remote machine that possibly could be down.\n<\/p>\n<p>\nKeep in mind that the server side is oblivious to the fact that the request is coming from\nautomount. As far as it knows it is just your normal every day <glossary>NFS<\/glossary>\n<glossary>mount<\/glossary>, therefore <glossary>automounter<\/glossary>\ncan be used with systems that don’t know about it.\n<\/p>\n<question id=\"\" type=\"mc\" text=\"What is the basic 'configuration unit' with automounter?\" \/>\n<question id=\"\" type=\"mc\" text=\"What is an automounter 'map'?\" \/>\n<concept id=\"\" description=\"The basic configuration unit with the automounter is one or more files called 'maps.'\" \/>\n<p>\nThe basic configuration unit with the <glossary>automounter<\/glossary>\nis one or more files called “maps.” These map the filesystems you want to access to the\ndirectory where you want to <glossary>mount<\/glossary> them (the mount points). These map\nfiles are fairly easy to configure and can be edited with any text\neditor. All automount connections are based on references in a map file.\n<\/p>\n<p>\nThe <command>amd<\/command> program is command-line based, so you can specify the name of the map file directly.\nAn example map file would look like this:<\/p>\n<p>\n<filecontents type=\"\">\n\/defaults opts:=rw;type=nfs jmohr_home rhost:=jmohr;rfs:=\/home\n<\/filecontents>\n<\/p>\n<p>\nThe first line specifies default parameters that are used during the <glossary>mount<\/glossary>.\nIn this case, we say that the <glossary>filesystem<\/glossary>\nshould be read-write (opts:=rw) and of type nfs (type=nfs). The next line specifies the directories to be\nmounted. The syntax for these lines is:<\/p>\n<p>\n<filecontents type=\"\">directory rhost:=<remote_host>;rfs:=<remote_filesystem><\/filecontents>\n<\/p>\n<p>\nwhere directory is the name of the\ndirectory on the local machine where the <glossary>filesystem<\/glossary>\nshould be mounted, <remote_host> is the\nname of the machine from which you are mounting the <glossary>filesystem<\/glossary>\nand <remote_filesystem> is the name of the remote <glossary>filesystem<\/glossary>.\n<\/p>\n<p>\nTo start <command>amd<\/command> the general syntax is:<\/p>\n<p>\n<commandexample command=\"amd\">\/usr\/sbin\/amd -a <temp_dir> — \/<real_dir> <map_file><\/commandexample>\n<\/p>\n<question id=\"\" type=\"mc\" text=\"What is used in an aoutmounter configration file to say that there are no more options to process?\" \/>\n<concept id=\"\" description=\"Two dashes (--) is used in an automounter configration file to say that there are no more options to process.\" \/>\n<p>\nHere, <temp_dir> is the name of a\ntemporary directory where the remote filesystems are actually mounted. This directory is created by\namd and should be removed if you start amd automatically through the rc scripts. A common convention\nis to define this directory as \/amd. The two dashes (–) is a common construct and tell amd that there\nare no more option to process. The \/<real_dir> indicates the directory where the users will\nsee the filesystems mounted. Finally, <map_file> is the name of the map file where amd should\nget its configuration information.\n<\/p>\n<p>\nTo run amd using the example configuration file, we might start it like this:<\/p>\n<p>\n<commandexample command=\"amd\">\/usr\/sbin\/amd -a \/amd — \/usr\/jmohr\/homes \/etc\/amd.junior<\/commandexample>\n<\/p>\n<p>\nHere we\nmount the remote filesystems under <directory>\/amd<\/directory> and the users see them under <directory>\/usr\/jmohr\/homes<\/directory>. So, if my\nhome directory on <i>junior<\/i> was <directory>\/usr\/jmohr\/homes\/jimmo<\/directory> every time I log into junior, amd kicks\nin and mounts the \/home directory from <i>jmohr<\/i>.\n<\/p>\n<p>\nDon’t think of automount as your only means of mounting <glossary>NFS<\/glossary>\n<glossary>filesystem<\/glossary> just because of it’s advantages. If you are constantly accessing\ncertain filesystems, then you gain nothing by making them automounted. In fact, you might lose\nsomething since each time the connection is made, you need to wait. If mounted in the conventional\nmanner, then you only need to wait once. If you have filesystems that are accessed regularly, but\nothers that are accessed only on occasion, you simply <glossary>mount<\/glossary>\nsome at <glossary>boot<\/glossary> and the rest via automount.\n<\/p>\n<p>\nA common use of automount is with <glossary>NIS<\/glossary>. NIS is used to distribute configuration\nfiles from the NIS server across the net to the <glossary>NIS<\/glossary>\nclients. Why not include the automount maps in the set of files\nthat is being distributed? This could be useful if you wanted to have all the documentation on a\nsingle machine to save space and access to the doc is made through automount. Since doc is not being\nconstantly access, this saves the problem of having the <glossary>filesystem<\/glossary>\ncontaining the doc be continually\nmounted.\n<\/p>\n<p>\nAnother use is when you want each user to have the same <glossary>home directory<\/glossary>\nno matter\nwhere they are. Something similar to what we had in the example above. If mounted by automount and\ndistributed via <glossary>NIS<\/glossary>,\nevery time they logged in, no matter on what machine, they would have the same\nhome directory. Granted, there is the problem of not being able to access their\n<glossary>home directory<\/glossary> if\nthe server is down. However, the problem of not being able to access the home directory still applies\nwhen <glossary>login<\/glossary> into a single machine. For example, if the home directory was on\na filesystem that wasn’t mounted.\n<\/p>\n<concept id=\"\" description=\"Automount behaves very similarly to traditional NFS mounts.\" \/>\n<question id=\"\" type=\"TF\" text=\"There is a special daemon to mount filesystem with automounter.\" \/>\n<question id=\"\" type=\"\" text=\"Automount uses the normal NFS daemon: nfsd.\" \/>\n<concept id=\"\" description=\"Automount uses the normal NFS daemon: nfsd.\" \/>\n<p>\nIn reality, automount behaves very similarly to traditional <glossary>NFS<\/glossary>\nmounts. The system knows that the\nspecified directory is an <glossary>NFS<\/glossary>\n<glossary>mount<\/glossary>\npoint. When something is accesses on the other side of the mount\npoint, the automount <glossary>daemon<\/glossary>\nreacts to the request basically the same way <command>nfsd<\/command> does with a normal NFS\nfilesystem. The automount <glossary>daemon<\/glossary> then checks the <glossary>mount<\/glossary>\ntable (<file type=\"\">\/etc\/mnttab<\/file>) to see if the filesystem is already <glossary term=\"mount\">mounted<\/glossary>\nand mounts it if it isn’t. Once the file system is mounted, requests are handled\nnormally.\n<\/p>\n<p>\nLike other filesystems, an entry is maintained in the system <glossary>mount<\/glossary> table\n(<file type=\"\">\/etc\/mnttab<\/file>) for all <glossary>filesystem<\/glossary>\nthat have been mounted with <glossary>automounter<\/glossary>.\n When the timeout has\nexpired (five minutes by default), <glossary>automounter<\/glossary>\nremoves the entry from \/etc\/mnttab, but still\nmaintains a copy in its memory. This copy is updated whenever mounting or unmounting a <glossary>filesystem<\/glossary>.\n<\/p>\n<p>\nThe version of amd that I installed with Caldera OpenLinux has some really nifty\nfeatures. (These feature may be available in other releases, I just didn’t test them). The most\nexciting feature for me required me to reconsider what amd was there for.\n<\/p>\n<p>\nI had always used <command>amd<\/command> (as well as the <glossary>automounter<\/glossary>\nof other UNIXes) to automatically <glossary>mount<\/glossary>\nfiles systems from other machines. That is, mounting them via <glossary>NFS<\/glossary>.\nOn the surface, one thinks of <glossary>UNIX<\/glossary> system administrators\nas being lazy. They spend all day trying to get out of work. That is, they develop programs that save\nthem work. Never mind that the work that is saved is much less than the work that they invested in\ntrying to save that work.\n<\/p>\n<p>\nThis is not a bad thing, for two reasons. First, the mentality of\nmost <glossary>UNIX<\/glossary>\nadministrators is that this <em>really<\/em> isn’t an attempt to get out work. There should be a\nbetter way of doing something, so they set out to find it. Just like the great inventors and\nexplorers of the past, they try it because “it’s there.”\n<\/p>\n<p>\nThe reason that this is not a bad\nthing is because like other kinds of inventions, the results are there for others. Once the program\nexists, then other administrators can use it. In keeping with the Linux mentality, you create a\nprogram that _you_ want to write, share it with others and they share theirs with you. You now have\nan entire tool chest of utilities that didn’t exist a year ago.\n<\/p>\n<p>\nSo, what does this have to do\nwith <command>amd<\/command>? Well, how often have you wanted to access a floppy, <glossary>CD-ROM<\/glossary>\nor <glossary>DOS<\/glossary> <glossary>partition<\/glossary>\non your machine? First, you need to find the device that it’s on, then find a place to <glossary>mount<\/glossary>\nit and then finally you get around to mounting it. Wouldn’t it be nice if you could access these filesystem\nwithout having to go through all of this? You <em>can<\/em>!\n<\/p>\n<p>\nThat’s the nice thing about <command>amd<\/command>. You can use it to <glossary>mount<\/glossary>\nall sorts of filesystems, including those on floppy, CD-ROMs and <glossary>DOS<\/glossary>\npartitions. In fact, that’s what I did. I have a handful of applications that do not run under VMWare, so\nI am forced to switch to <glossary>Windows 95<\/glossary>\nwhen I want to run them. Therefore, I cannot make my entire system Linux. Often, I need to transfer\ndata from one system to other. That means finding the device that it’s on, then finding a place\nto <glossary>mount<\/glossary> it and then finally getting around to mounting it.\n<\/p>\n<p>\nWhat a waste of time!\n<\/p>\n<question id=\"398\" text=\"Automount cannot be used to mount local filesystem.\" \/>\n<concept id=\"\" description=\"Automount can be used to mount local filesystem.\" \/>\n<p>\nI noticed that amd was running on my system, using the configuration file\n<file>\/etc\/amd.localdev<\/file>. Seeing that I thought, “localdev? local devices? Hmmm….” Checking in this file,\nI discovered that you can, in fact, <glossary>mount<\/glossary>\nlocal <glossary>filesystem<\/glossary> via <command>amd<\/command>. So, let’s take a look at the\nfile that had on my system:\n<\/p>\n<p>\n<filecontents>\n# \/etc\/amd.localdev : automounter map for local devices\n# Don’t forget to unmount floppies with “amq -u \/auto\/floppy” before\n# ejecting them, especially when they are mounted read-write !!!\n\/defaults opts:=nodev,nosuid,ro;dev:=\/dev\/${key};type:=msdos;\n# floppy -dev:=\/dev\/fd0;type:=msdos opts:=rw opts:=ro\nfloppy dev:=\/dev\/fd0;type:=msdos;\n# floppy95 -dev:=\/dev\/fd0;type:=vfat; opts:=rw opts:=ro\nfloppy95 dev:=\/dev\/fd0;type:=vfat;\ncdrom type:=iso9660\nc_drive dev:=\/dev\/sda1;type:=vfat; opts=rw\nd_drive dev:=\/dev\/sda5;type:=vfat; opts=rw\ne_drive dev:=\/dev\/sdb1;type:=vfat; opts=rw\nf_drive dev:=\/dev\/sdb5;type:=vfat; opts=rw\ng_drive dev:=\/dev\/sdb6;type:=vfat; opts=rw\nh_drive dev:=\/dev\/sdb7;type:=vfat; opts=rw\n* dev:=\/dev\/${key}\n<\/filecontents>\n<p>\nIn principle the options are the similar to those for the fstab and exports files.\nI leave it to you to check amd(8) <glossary>man-page<\/glossary> for the details.\n<\/p>\n<p>\nThe thing I want to first point out is the last line:\n<\/p>\n<p>\n<filecontents>* dev:=\/dev\/${key} <\/filecontents>\n<\/p>\n<p>\nAs one might guess from the asterisk, this is a wild\ncard and represents every <glossary>filesystem<\/glossary>\nthat we have not specified previously. Since we did not specify any options,\nthe options used are those in the \/default line. The nifty part of this\nis the ${key} part of the device name. This is translated to\nmean the name of the sub-directory under \/auto. For example,\nmy C: drive is <device>\/dev\/sda1<\/device>. If I did cd\n<device>\/auto\/sda1<\/device>, amd would see the name of the sub-directory as sda1, then it\nwould look for a matching device. Since it finds one, it can <glossary>mount<\/glossary>\nthat device. Therefore, if you\nhave mountable <glossary>filesystem<\/glossary>,\n you do *not* need to explicitely define them.\n<\/p>\n<p>\nIn this file are two\nlines for floppies (floppy and floppy95). The type of <glossary>filesystem<\/glossary>\nin the first line is msdos and this\nsecond is vfat, which allows you to <glossary>mount<\/glossary>\na floppy and still have access to the long filenames. The\nnext line is one for a cdrom. These were the lines that were originally in my amd.localdev file.\n<\/p>\n<p>\nWhen you start amd, you tell it the name of where it should <glossary>mount<\/glossary>\nthese filesystems. By\ndefault, on my system, this is the directory, \/auto. So,\nwhen I do a cd <directory>\/auto\/cdrom<\/directory>, the cdrom is automatically\nmounted and I find myself in the root directory of the cdrom without going through the hassle of\nmounting it first.\n<\/p>\n<p>\nOnce I discovered this, I add the lines that look like this:\n<\/p>\n<p>\n<filecontents>c_drive dev:=\/dev\/sda1;type:=vfat; opts=rw<\/filecontents>\n<\/p>\n<p>\nAs you might guess, this automatically mounts my <glossary>DOS<\/glossary>\nfilesystems. I originally had them\nall in \/etc\/fstab, so they would automatically <glossary>mount<\/glossary>\nat <glossary>boot<\/glossary>\nup. Since I only use them occasionally,\nthis didn’t make sense. I changed the entries so that they weren’t mounted automatically, all I had\nto do was run “mount \/dev\/sda1! (or whatever) and they were mounted.\n<\/p>\n<p>\nNote in this case that\nthe <glossary>filesystem<\/glossary>\ntype is actually VFAT, and not the standard <glossary>DOS<\/glossary>\nFAT filesystem. Now, when I do\ncd <directory>\/auto\/c_drive<\/directory>, I find myself on the C: drive of my\nWindows 95 system. (<device>\/dev\/sda1<\/device>) When I do\ncd <directory>\/auto\/g_drive<\/directory>, I am then on the G: drive.\n<\/p>\n<p>\nBeing a normal Linux system <glossary>administrator<\/glossary>,\nthis was too much for me. Not that the work was too much, I had too many\nentries in there that were basically all the same. In essence, the default behavior that I wanted was\nthat I would cd into a directory under \/auto and I would be\non one of my <glossary>Windows 95<\/glossary>\ndrives. Therefore, I could change the\n\/default like to look like this:<\/p>\n<p>\n<filecontents>\n\/defaults opts:=nodev,nosuid;dev:=\/dev\/${key};type:=vfat;\n<\/filecontents>\n<\/p>\n<p>\nNote that I not only changed the <glossary>filesystem<\/glossary>\ntype to vfat, but I also removed the options to say that this was a read-only\nfilesystem (ro). Now when I do a cd \/auto\/sda1 I am on the\nC: drive or \/auto\/sdb6 I am on the G: drive.\n<\/p>\n<p>\nHmmmm.\nHow do I know that \/dev\/sdb6 is the G: drive? Trying to\nfigure that out each time is as much work as mounting it by hand. (Well, not quite.) To save me some\nwork, I simply created a handful on links in \/dev that look\nlike this:\n<\/p>\n<p>\n<screenoutput>\nlrwxrwxrwx 1 root root 4 Jan 26 10:46 \/dev\/c_drive -> sda1\nlrwxrwxrwx 1 root root 4 Jan 26 10:46 \/dev\/d_drive -> sda5\nlrwxrwxrwx 1 root root 4 Jan 26 10:46 \/dev\/e_drive -> sdb1\nlrwxrwxrwx 1 root root 4 Jan 26 10:46 \/dev\/f_drive -> sdb5\nlrwxrwxrwx 1 root root 4 Jan 26 10:46 \/dev\/g_drive -> sdb6\nlrwxrwxrwx 1 root root 4 Jan 26 10:46 \/dev\/h_drive -> sdb7\n<\/screenoutput>\n<\/p>\n<p>\nNow, I all need to do is cd \/auto\/g_drive and I end up on the right drive.\n<\/p>\n<p>\nOne might ask what advantage this has over traditional mounts via \/etc\/fstab. When dealing\nwith <glossary>NFS<\/glossary> mounts across the\nnetwork, there is the issue of <glossary>bandwidth<\/glossary>\nand the problems that occur when the server side goes down.\nSince you are accessing a local drive, there are no issues of <glossary>bandwidth<\/glossary>\nand if the server goes down, the <glossary>client<\/glossary>\ngoes with it.\n<\/p>\n<p>\nWell, that last part is the point. If I only need to access the\nfilesystem for a short time, it is safer to umount when I am done. By using amd, I don’t need to\nworry about forgetting it. After specific period of time (default: 5 minutes), the system will\nunmount any unused filesystems.\n<\/p>\n<p>\n<center><table BORDER cellspacing=1 CELLPADDING=7 >\n<tr><td><b>File<\/b><\/td><td><b>Function<\/b><\/td><\/tr>\n<tr><td>\/etc\/amd.local<\/td><td>Automount configuration file for local devices <\/td><\/tr>\n<tr><td>\/etc\/exports<\/td><td>NFS files systems being exported<\/td><\/tr>\n<tr><td>\/usr\/sbin\/rpc.portmap<\/td><td>Portmapper. Converts DARPA ports to <glossary>RPC<\/glossary> program number.<\/td><\/tr>\n<tr><td>\/usr\/sbin\/rpc.mountd<\/td><td>NFS <glossary>mount<\/glossary> request server.<\/td><\/tr>\n<tr><td>\/usr\/sbin\/rpc.nfsd<\/td><td>NFS daemon to handle <glossary>client<\/glossary> requests.<\/td><\/tr>\n<tr><td>\/usr\/sbin\/amd<\/td><td>The automount program.<\/td><\/tr>\n<tr><td>\/usr\/sbin\/rpc.rusersd<\/td><td>Network user <glossary>name server<\/glossary>.<\/td><\/tr>\n<tr><td>\/usr\/sbin\/rpc.rwalld<\/td><td>Network wall server.<\/td><\/tr>\n<tr><td>\/usr\/bin\/rpcinfo<\/td><td>Reports RPC information.<\/td><\/tr>\n<tr><td>\/usr\/bin\/rusers<\/td><td>Reports information on <glossary>network<\/glossary> users.<\/td><\/tr>\n<tr><td>\/usr\/bin\/rwall<\/td><td>Write to all users on the <glossary>network<\/glossary>.<\/td><\/tr>\n<tr><td>\/usr\/bin\/showmount<\/td><td>Shows information on remotely mounted filesystems.<\/td><\/tr>\n<\/table><\/center>\n<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Automount If you are used to later versions of Windows, you certainly know how nice it is to be able to access files on remote systems without having to explicitely mount them each time. Occassionally, I get comments from Windows … <a href=\"http:\/\/www.linux-tutorial.info\/?page_id=310\">Continue reading <span class=\"meta-nav\">→<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"parent":0,"menu_order":0,"comment_status":"closed","ping_status":"closed","template":"","meta":{"footnotes":""},"class_list":["post-310","page","type-page","status-publish","hentry"],"_links":{"self":[{"href":"http:\/\/www.linux-tutorial.info\/index.php?rest_route=\/wp\/v2\/pages\/310","targetHints":{"allow":["GET"]}}],"collection":[{"href":"http:\/\/www.linux-tutorial.info\/index.php?rest_route=\/wp\/v2\/pages"}],"about":[{"href":"http:\/\/www.linux-tutorial.info\/index.php?rest_route=\/wp\/v2\/types\/page"}],"author":[{"embeddable":true,"href":"http:\/\/www.linux-tutorial.info\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/www.linux-tutorial.info\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=310"}],"version-history":[{"count":1,"href":"http:\/\/www.linux-tutorial.info\/index.php?rest_route=\/wp\/v2\/pages\/310\/revisions"}],"predecessor-version":[{"id":486,"href":"http:\/\/www.linux-tutorial.info\/index.php?rest_route=\/wp\/v2\/pages\/310\/revisions\/486"}],"wp:attachment":[{"href":"http:\/\/www.linux-tutorial.info\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=310"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}