autofs.rst 25 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355356357358359360361362363364365366367368369370371372373374375376377378379380381382383384385386387388389390391392393394395396397398399400401402403404405406407408409410411412413414415416417418419420421422423424425426427428429430431432433434435436437438439440441442443444445446447448449450451452453454455456457458459460461462463464465466467468469470471472473474475476477478479480481482483484485486487488489490491492493494495496497498499500501502503504505506507508509510511512513514515516517518519520521522523524525526527528529530531532533534535536537538539540541542543544545546547548549550551552553554555556557558559560561562563564565566567568569570571572573574575576577578579580
  1. =====================
  2. autofs - how it works
  3. =====================
  4. Purpose
  5. =======
  6. The goal of autofs is to provide on-demand mounting and race free
  7. automatic unmounting of various other filesystems. This provides two
  8. key advantages:
  9. 1. There is no need to delay boot until all filesystems that
  10. might be needed are mounted. Processes that try to access those
  11. slow filesystems might be delayed but other processes can
  12. continue freely. This is particularly important for
  13. network filesystems (e.g. NFS) or filesystems stored on
  14. media with a media-changing robot.
  15. 2. The names and locations of filesystems can be stored in
  16. a remote database and can change at any time. The content
  17. in that data base at the time of access will be used to provide
  18. a target for the access. The interpretation of names in the
  19. filesystem can even be programmatic rather than database-backed,
  20. allowing wildcards for example, and can vary based on the user who
  21. first accessed a name.
  22. Context
  23. =======
  24. The "autofs" filesystem module is only one part of an autofs system.
  25. There also needs to be a user-space program which looks up names
  26. and mounts filesystems. This will often be the "automount" program,
  27. though other tools including "systemd" can make use of "autofs".
  28. This document describes only the kernel module and the interactions
  29. required with any user-space program. Subsequent text refers to this
  30. as the "automount daemon" or simply "the daemon".
  31. "autofs" is a Linux kernel module with provides the "autofs"
  32. filesystem type. Several "autofs" filesystems can be mounted and they
  33. can each be managed separately, or all managed by the same daemon.
  34. Content
  35. =======
  36. An autofs filesystem can contain 3 sorts of objects: directories,
  37. symbolic links and mount traps. Mount traps are directories with
  38. extra properties as described in the next section.
  39. Objects can only be created by the automount daemon: symlinks are
  40. created with a regular `symlink` system call, while directories and
  41. mount traps are created with `mkdir`. The determination of whether a
  42. directory should be a mount trap is based on a master map. This master
  43. map is consulted by autofs to determine which directories are mount
  44. points. Mount points can be *direct*/*indirect*/*offset*.
  45. On most systems, the default master map is located at */etc/auto.master*.
  46. If neither the *direct* or *offset* mount options are given (so the
  47. mount is considered to be *indirect*), then the root directory is
  48. always a regular directory, otherwise it is a mount trap when it is
  49. empty and a regular directory when not empty. Note that *direct* and
  50. *offset* are treated identically so a concise summary is that the root
  51. directory is a mount trap only if the filesystem is mounted *direct*
  52. and the root is empty.
  53. Directories created in the root directory are mount traps only if the
  54. filesystem is mounted *indirect* and they are empty.
  55. Directories further down the tree depend on the *maxproto* mount
  56. option and particularly whether it is less than five or not.
  57. When *maxproto* is five, no directories further down the
  58. tree are ever mount traps, they are always regular directories. When
  59. the *maxproto* is four (or three), these directories are mount traps
  60. precisely when they are empty.
  61. So: non-empty (i.e. non-leaf) directories are never mount traps. Empty
  62. directories are sometimes mount traps, and sometimes not depending on
  63. where in the tree they are (root, top level, or lower), the *maxproto*,
  64. and whether the mount was *indirect* or not.
  65. Mount Traps
  66. ===========
  67. A core element of the implementation of autofs is the Mount Traps
  68. which are provided by the Linux VFS. Any directory provided by a
  69. filesystem can be designated as a trap. This involves two separate
  70. features that work together to allow autofs to do its job.
  71. **DCACHE_NEED_AUTOMOUNT**
  72. If a dentry has the DCACHE_NEED_AUTOMOUNT flag set (which gets set if
  73. the inode has S_AUTOMOUNT set, or can be set directly) then it is
  74. (potentially) a mount trap. Any access to this directory beyond a
  75. "`stat`" will (normally) cause the `d_op->d_automount()` dentry operation
  76. to be called. The task of this method is to find the filesystem that
  77. should be mounted on the directory and to return it. The VFS is
  78. responsible for actually mounting the root of this filesystem on the
  79. directory.
  80. autofs doesn't find the filesystem itself but sends a message to the
  81. automount daemon asking it to find and mount the filesystem. The
  82. autofs `d_automount` method then waits for the daemon to report that
  83. everything is ready. It will then return "`NULL`" indicating that the
  84. mount has already happened. The VFS doesn't try to mount anything but
  85. follows down the mount that is already there.
  86. This functionality is sufficient for some users of mount traps such
  87. as NFS which creates traps so that mountpoints on the server can be
  88. reflected on the client. However it is not sufficient for autofs. As
  89. mounting onto a directory is considered to be "beyond a `stat`", the
  90. automount daemon would not be able to mount a filesystem on the 'trap'
  91. directory without some way to avoid getting caught in the trap. For
  92. that purpose there is another flag.
  93. **DCACHE_MANAGE_TRANSIT**
  94. If a dentry has DCACHE_MANAGE_TRANSIT set then two very different but
  95. related behaviours are invoked, both using the `d_op->d_manage()`
  96. dentry operation.
  97. Firstly, before checking to see if any filesystem is mounted on the
  98. directory, d_manage() will be called with the `rcu_walk` parameter set
  99. to `false`. It may return one of three things:
  100. - A return value of zero indicates that there is nothing special
  101. about this dentry and normal checks for mounts and automounts
  102. should proceed.
  103. autofs normally returns zero, but first waits for any
  104. expiry (automatic unmounting of the mounted filesystem) to
  105. complete. This avoids races.
  106. - A return value of `-EISDIR` tells the VFS to ignore any mounts
  107. on the directory and to not consider calling `->d_automount()`.
  108. This effectively disables the **DCACHE_NEED_AUTOMOUNT** flag
  109. causing the directory not be a mount trap after all.
  110. autofs returns this if it detects that the process performing the
  111. lookup is the automount daemon and that the mount has been
  112. requested but has not yet completed. How it determines this is
  113. discussed later. This allows the automount daemon not to get
  114. caught in the mount trap.
  115. There is a subtlety here. It is possible that a second autofs
  116. filesystem can be mounted below the first and for both of them to
  117. be managed by the same daemon. For the daemon to be able to mount
  118. something on the second it must be able to "walk" down past the
  119. first. This means that d_manage cannot *always* return -EISDIR for
  120. the automount daemon. It must only return it when a mount has
  121. been requested, but has not yet completed.
  122. `d_manage` also returns `-EISDIR` if the dentry shouldn't be a
  123. mount trap, either because it is a symbolic link or because it is
  124. not empty.
  125. - Any other negative value is treated as an error and returned
  126. to the caller.
  127. autofs can return
  128. - -ENOENT if the automount daemon failed to mount anything,
  129. - -ENOMEM if it ran out of memory,
  130. - -EINTR if a signal arrived while waiting for expiry to
  131. complete
  132. - or any other error sent down by the automount daemon.
  133. The second use case only occurs during an "RCU-walk" and so `rcu_walk`
  134. will be set.
  135. An RCU-walk is a fast and lightweight process for walking down a
  136. filename path (i.e. it is like running on tip-toes). RCU-walk cannot
  137. cope with all situations so when it finds a difficulty it falls back
  138. to "REF-walk", which is slower but more robust.
  139. RCU-walk will never call `->d_automount`; the filesystems must already
  140. be mounted or RCU-walk cannot handle the path.
  141. To determine if a mount-trap is safe for RCU-walk mode it calls
  142. `->d_manage()` with `rcu_walk` set to `true`.
  143. In this case `d_manage()` must avoid blocking and should avoid taking
  144. spinlocks if at all possible. Its sole purpose is to determine if it
  145. would be safe to follow down into any mounted directory and the only
  146. reason that it might not be is if an expiry of the mount is
  147. underway.
  148. In the `rcu_walk` case, `d_manage()` cannot return -EISDIR to tell the
  149. VFS that this is a directory that doesn't require d_automount. If
  150. `rcu_walk` sees a dentry with DCACHE_NEED_AUTOMOUNT set but nothing
  151. mounted, it *will* fall back to REF-walk. `d_manage()` cannot make the
  152. VFS remain in RCU-walk mode, but can only tell it to get out of
  153. RCU-walk mode by returning `-ECHILD`.
  154. So `d_manage()`, when called with `rcu_walk` set, should either return
  155. -ECHILD if there is any reason to believe it is unsafe to enter the
  156. mounted filesystem, otherwise it should return 0.
  157. autofs will return `-ECHILD` if an expiry of the filesystem has been
  158. initiated or is being considered, otherwise it returns 0.
  159. Mountpoint expiry
  160. =================
  161. The VFS has a mechanism for automatically expiring unused mounts,
  162. much as it can expire any unused dentry information from the dcache.
  163. This is guided by the MNT_SHRINKABLE flag. This only applies to
  164. mounts that were created by `d_automount()` returning a filesystem to be
  165. mounted. As autofs doesn't return such a filesystem but leaves the
  166. mounting to the automount daemon, it must involve the automount daemon
  167. in unmounting as well. This also means that autofs has more control
  168. over expiry.
  169. The VFS also supports "expiry" of mounts using the MNT_EXPIRE flag to
  170. the `umount` system call. Unmounting with MNT_EXPIRE will fail unless
  171. a previous attempt had been made, and the filesystem has been inactive
  172. and untouched since that previous attempt. autofs does not depend on
  173. this but has its own internal tracking of whether filesystems were
  174. recently used. This allows individual names in the autofs directory
  175. to expire separately.
  176. With version 4 of the protocol, the automount daemon can try to
  177. unmount any filesystems mounted on the autofs filesystem or remove any
  178. symbolic links or empty directories any time it likes. If the unmount
  179. or removal is successful the filesystem will be returned to the state
  180. it was before the mount or creation, so that any access of the name
  181. will trigger normal auto-mount processing. In particular, `rmdir` and
  182. `unlink` do not leave negative entries in the dcache as a normal
  183. filesystem would, so an attempt to access a recently-removed object is
  184. passed to autofs for handling.
  185. With version 5, this is not safe except for unmounting from top-level
  186. directories. As lower-level directories are never mount traps, other
  187. processes will see an empty directory as soon as the filesystem is
  188. unmounted. So it is generally safest to use the autofs expiry
  189. protocol described below.
  190. Normally the daemon only wants to remove entries which haven't been
  191. used for a while. For this purpose autofs maintains a "`last_used`"
  192. time stamp on each directory or symlink. For symlinks it genuinely
  193. does record the last time the symlink was "used" or followed to find
  194. out where it points to. For directories the field is used slightly
  195. differently. The field is updated at mount time and during expire
  196. checks if it is found to be in use (ie. open file descriptor or
  197. process working directory) and during path walks. The update done
  198. during path walks prevents frequent expire and immediate mount of
  199. frequently accessed automounts. But in the case where a GUI continually
  200. access or an application frequently scans an autofs directory tree
  201. there can be an accumulation of mounts that aren't actually being
  202. used. To cater for this case the "`strictexpire`" autofs mount option
  203. can be used to avoid the "`last_used`" update on path walk thereby
  204. preventing this apparent inability to expire mounts that aren't
  205. really in use.
  206. The daemon is able to ask autofs if anything is due to be expired,
  207. using an `ioctl` as discussed later. For a *direct* mount, autofs
  208. considers if the entire mount-tree can be unmounted or not. For an
  209. *indirect* mount, autofs considers each of the names in the top level
  210. directory to determine if any of those can be unmounted and cleaned
  211. up.
  212. There is an option with indirect mounts to consider each of the leaves
  213. that has been mounted on instead of considering the top-level names.
  214. This was originally intended for compatibility with version 4 of autofs
  215. and should be considered as deprecated for Sun Format automount maps.
  216. However, it may be used again for amd format mount maps (which are
  217. generally indirect maps) because the amd automounter allows for the
  218. setting of an expire timeout for individual mounts. But there are
  219. some difficulties in making the needed changes for this.
  220. When autofs considers a directory it checks the `last_used` time and
  221. compares it with the "timeout" value set when the filesystem was
  222. mounted, though this check is ignored in some cases. It also checks if
  223. the directory or anything below it is in use. For symbolic links,
  224. only the `last_used` time is ever considered.
  225. If both appear to support expiring the directory or symlink, an action
  226. is taken.
  227. There are two ways to ask autofs to consider expiry. The first is to
  228. use the **AUTOFS_IOC_EXPIRE** ioctl. This only works for indirect
  229. mounts. If it finds something in the root directory to expire it will
  230. return the name of that thing. Once a name has been returned the
  231. automount daemon needs to unmount any filesystems mounted below the
  232. name normally. As described above, this is unsafe for non-toplevel
  233. mounts in a version-5 autofs. For this reason the current `automount(8)`
  234. does not use this ioctl.
  235. The second mechanism uses either the **AUTOFS_DEV_IOCTL_EXPIRE_CMD** or
  236. the **AUTOFS_IOC_EXPIRE_MULTI** ioctl. This will work for both direct and
  237. indirect mounts. If it selects an object to expire, it will notify
  238. the daemon using the notification mechanism described below. This
  239. will block until the daemon acknowledges the expiry notification.
  240. This implies that the "`EXPIRE`" ioctl must be sent from a different
  241. thread than the one which handles notification.
  242. While the ioctl is blocking, the entry is marked as "expiring" and
  243. `d_manage` will block until the daemon affirms that the unmount has
  244. completed (together with removing any directories that might have been
  245. necessary), or has been aborted.
  246. Communicating with autofs: detecting the daemon
  247. ===============================================
  248. There are several forms of communication between the automount daemon
  249. and the filesystem. As we have already seen, the daemon can create and
  250. remove directories and symlinks using normal filesystem operations.
  251. autofs knows whether a process requesting some operation is the daemon
  252. or not based on its process-group id number (see getpgid(1)).
  253. When an autofs filesystem is mounted the pgid of the mounting
  254. processes is recorded unless the "pgrp=" option is given, in which
  255. case that number is recorded instead. Any request arriving from a
  256. process in that process group is considered to come from the daemon.
  257. If the daemon ever has to be stopped and restarted a new pgid can be
  258. provided through an ioctl as will be described below.
  259. Communicating with autofs: the event pipe
  260. =========================================
  261. When an autofs filesystem is mounted, the 'write' end of a pipe must
  262. be passed using the 'fd=' mount option. autofs will write
  263. notification messages to this pipe for the daemon to respond to.
  264. For version 5, the format of the message is::
  265. struct autofs_v5_packet {
  266. struct autofs_packet_hdr hdr;
  267. autofs_wqt_t wait_queue_token;
  268. __u32 dev;
  269. __u64 ino;
  270. __u32 uid;
  271. __u32 gid;
  272. __u32 pid;
  273. __u32 tgid;
  274. __u32 len;
  275. char name[NAME_MAX+1];
  276. };
  277. And the format of the header is::
  278. struct autofs_packet_hdr {
  279. int proto_version; /* Protocol version */
  280. int type; /* Type of packet */
  281. };
  282. where the type is one of ::
  283. autofs_ptype_missing_indirect
  284. autofs_ptype_expire_indirect
  285. autofs_ptype_missing_direct
  286. autofs_ptype_expire_direct
  287. so messages can indicate that a name is missing (something tried to
  288. access it but it isn't there) or that it has been selected for expiry.
  289. The pipe will be set to "packet mode" (equivalent to passing
  290. `O_DIRECT`) to _pipe2(2)_ so that a read from the pipe will return at
  291. most one packet, and any unread portion of a packet will be discarded.
  292. The `wait_queue_token` is a unique number which can identify a
  293. particular request to be acknowledged. When a message is sent over
  294. the pipe the affected dentry is marked as either "active" or
  295. "expiring" and other accesses to it block until the message is
  296. acknowledged using one of the ioctls below with the relevant
  297. `wait_queue_token`.
  298. Communicating with autofs: root directory ioctls
  299. ================================================
  300. The root directory of an autofs filesystem will respond to a number of
  301. ioctls. The process issuing the ioctl must have the CAP_SYS_ADMIN
  302. capability, or must be the automount daemon.
  303. The available ioctl commands are:
  304. - **AUTOFS_IOC_READY**:
  305. a notification has been handled. The argument
  306. to the ioctl command is the "wait_queue_token" number
  307. corresponding to the notification being acknowledged.
  308. - **AUTOFS_IOC_FAIL**:
  309. similar to above, but indicates failure with
  310. the error code `ENOENT`.
  311. - **AUTOFS_IOC_CATATONIC**:
  312. Causes the autofs to enter "catatonic"
  313. mode meaning that it stops sending notifications to the daemon.
  314. This mode is also entered if a write to the pipe fails.
  315. - **AUTOFS_IOC_PROTOVER**:
  316. This returns the protocol version in use.
  317. - **AUTOFS_IOC_PROTOSUBVER**:
  318. Returns the protocol sub-version which
  319. is really a version number for the implementation.
  320. - **AUTOFS_IOC_SETTIMEOUT**:
  321. This passes a pointer to an unsigned
  322. long. The value is used to set the timeout for expiry, and
  323. the current timeout value is stored back through the pointer.
  324. - **AUTOFS_IOC_ASKUMOUNT**:
  325. Returns, in the pointed-to `int`, 1 if
  326. the filesystem could be unmounted. This is only a hint as
  327. the situation could change at any instant. This call can be
  328. used to avoid a more expensive full unmount attempt.
  329. - **AUTOFS_IOC_EXPIRE**:
  330. as described above, this asks if there is
  331. anything suitable to expire. A pointer to a packet::
  332. struct autofs_packet_expire_multi {
  333. struct autofs_packet_hdr hdr;
  334. autofs_wqt_t wait_queue_token;
  335. int len;
  336. char name[NAME_MAX+1];
  337. };
  338. is required. This is filled in with the name of something
  339. that can be unmounted or removed. If nothing can be expired,
  340. `errno` is set to `EAGAIN`. Even though a `wait_queue_token`
  341. is present in the structure, no "wait queue" is established
  342. and no acknowledgment is needed.
  343. - **AUTOFS_IOC_EXPIRE_MULTI**:
  344. This is similar to
  345. **AUTOFS_IOC_EXPIRE** except that it causes notification to be
  346. sent to the daemon, and it blocks until the daemon acknowledges.
  347. The argument is an integer which can contain two different flags.
  348. **AUTOFS_EXP_IMMEDIATE** causes `last_used` time to be ignored
  349. and objects are expired if the are not in use.
  350. **AUTOFS_EXP_FORCED** causes the in use status to be ignored
  351. and objects are expired ieven if they are in use. This assumes
  352. that the daemon has requested this because it is capable of
  353. performing the umount.
  354. **AUTOFS_EXP_LEAVES** will select a leaf rather than a top-level
  355. name to expire. This is only safe when *maxproto* is 4.
  356. Communicating with autofs: char-device ioctls
  357. =============================================
  358. It is not always possible to open the root of an autofs filesystem,
  359. particularly a *direct* mounted filesystem. If the automount daemon
  360. is restarted there is no way for it to regain control of existing
  361. mounts using any of the above communication channels. To address this
  362. need there is a "miscellaneous" character device (major 10, minor 235)
  363. which can be used to communicate directly with the autofs filesystem.
  364. It requires CAP_SYS_ADMIN for access.
  365. The 'ioctl's that can be used on this device are described in a separate
  366. document `autofs-mount-control.txt`, and are summarised briefly here.
  367. Each ioctl is passed a pointer to an `autofs_dev_ioctl` structure::
  368. struct autofs_dev_ioctl {
  369. __u32 ver_major;
  370. __u32 ver_minor;
  371. __u32 size; /* total size of data passed in
  372. * including this struct */
  373. __s32 ioctlfd; /* automount command fd */
  374. /* Command parameters */
  375. union {
  376. struct args_protover protover;
  377. struct args_protosubver protosubver;
  378. struct args_openmount openmount;
  379. struct args_ready ready;
  380. struct args_fail fail;
  381. struct args_setpipefd setpipefd;
  382. struct args_timeout timeout;
  383. struct args_requester requester;
  384. struct args_expire expire;
  385. struct args_askumount askumount;
  386. struct args_ismountpoint ismountpoint;
  387. };
  388. char path[0];
  389. };
  390. For the **OPEN_MOUNT** and **IS_MOUNTPOINT** commands, the target
  391. filesystem is identified by the `path`. All other commands identify
  392. the filesystem by the `ioctlfd` which is a file descriptor open on the
  393. root, and which can be returned by **OPEN_MOUNT**.
  394. The `ver_major` and `ver_minor` are in/out parameters which check that
  395. the requested version is supported, and report the maximum version
  396. that the kernel module can support.
  397. Commands are:
  398. - **AUTOFS_DEV_IOCTL_VERSION_CMD**:
  399. does nothing, except validate and
  400. set version numbers.
  401. - **AUTOFS_DEV_IOCTL_OPENMOUNT_CMD**:
  402. return an open file descriptor
  403. on the root of an autofs filesystem. The filesystem is identified
  404. by name and device number, which is stored in `openmount.devid`.
  405. Device numbers for existing filesystems can be found in
  406. `/proc/self/mountinfo`.
  407. - **AUTOFS_DEV_IOCTL_CLOSEMOUNT_CMD**:
  408. same as `close(ioctlfd)`.
  409. - **AUTOFS_DEV_IOCTL_SETPIPEFD_CMD**:
  410. if the filesystem is in
  411. catatonic mode, this can provide the write end of a new pipe
  412. in `setpipefd.pipefd` to re-establish communication with a daemon.
  413. The process group of the calling process is used to identify the
  414. daemon.
  415. - **AUTOFS_DEV_IOCTL_REQUESTER_CMD**:
  416. `path` should be a
  417. name within the filesystem that has been auto-mounted on.
  418. On successful return, `requester.uid` and `requester.gid` will be
  419. the UID and GID of the process which triggered that mount.
  420. - **AUTOFS_DEV_IOCTL_ISMOUNTPOINT_CMD**:
  421. Check if path is a
  422. mountpoint of a particular type - see separate documentation for
  423. details.
  424. - **AUTOFS_DEV_IOCTL_PROTOVER_CMD**
  425. - **AUTOFS_DEV_IOCTL_PROTOSUBVER_CMD**
  426. - **AUTOFS_DEV_IOCTL_READY_CMD**
  427. - **AUTOFS_DEV_IOCTL_FAIL_CMD**
  428. - **AUTOFS_DEV_IOCTL_CATATONIC_CMD**
  429. - **AUTOFS_DEV_IOCTL_TIMEOUT_CMD**
  430. - **AUTOFS_DEV_IOCTL_EXPIRE_CMD**
  431. - **AUTOFS_DEV_IOCTL_ASKUMOUNT_CMD**
  432. These all have the same
  433. function as the similarly named **AUTOFS_IOC** ioctls, except
  434. that **FAIL** can be given an explicit error number in `fail.status`
  435. instead of assuming `ENOENT`, and this **EXPIRE** command
  436. corresponds to **AUTOFS_IOC_EXPIRE_MULTI**.
  437. Catatonic mode
  438. ==============
  439. As mentioned, an autofs mount can enter "catatonic" mode. This
  440. happens if a write to the notification pipe fails, or if it is
  441. explicitly requested by an `ioctl`.
  442. When entering catatonic mode, the pipe is closed and any pending
  443. notifications are acknowledged with the error `ENOENT`.
  444. Once in catatonic mode attempts to access non-existing names will
  445. result in `ENOENT` while attempts to access existing directories will
  446. be treated in the same way as if they came from the daemon, so mount
  447. traps will not fire.
  448. When the filesystem is mounted a _uid_ and _gid_ can be given which
  449. set the ownership of directories and symbolic links. When the
  450. filesystem is in catatonic mode, any process with a matching UID can
  451. create directories or symlinks in the root directory, but not in other
  452. directories.
  453. Catatonic mode can only be left via the
  454. **AUTOFS_DEV_IOCTL_OPENMOUNT_CMD** ioctl on the `/dev/autofs`.
  455. The "ignore" mount option
  456. =========================
  457. The "ignore" mount option can be used to provide a generic indicator
  458. to applications that the mount entry should be ignored when displaying
  459. mount information.
  460. In other OSes that provide autofs and that provide a mount list to user
  461. space based on the kernel mount list a no-op mount option ("ignore" is
  462. the one use on the most common OSes) is allowed so that autofs file
  463. system users can optionally use it.
  464. This is intended to be used by user space programs to exclude autofs
  465. mounts from consideration when reading the mounts list.
  466. autofs, name spaces, and shared mounts
  467. ======================================
  468. With bind mounts and name spaces it is possible for an autofs
  469. filesystem to appear at multiple places in one or more filesystem
  470. name spaces. For this to work sensibly, the autofs filesystem should
  471. always be mounted "shared". e.g. ::
  472. mount --make-shared /autofs/mount/point
  473. The automount daemon is only able to manage a single mount location for
  474. an autofs filesystem and if mounts on that are not 'shared', other
  475. locations will not behave as expected. In particular access to those
  476. other locations will likely result in the `ELOOP` error ::
  477. Too many levels of symbolic links