I have 10.1 running on various systems and tried using the new automounter for the first time. For testing, with the stock /etc/auto_master is issued the following commands on the client: # service automount onestart # service automountd onestart # service autounmountd onestart The server exports the following filesystems (partial list only): / /z/SRC/FreeBSD /z/SRC/FreeBSD-doc /z/SRC/FreeBSD-ports /z/SVN/FreeBSD /z/SVN/FreeBSD-doc /z/SVN/FreeBSD-ports Note that /z, /z/SRC, and /z/SVN are not exported. In fact, the root of the zfs filesystem hierarchy is mounted elsewhere, and therefore /z cannot be exported separately. Only starting from the first-level sub-filesystems the zfs filesystems are mounted under /z. Now doing # ls /net/server ==> yields the server's root directory # ls /net/server/z ==> lists "SRC SVN" # ls /net/server/z/SRC ==> lists nothing, but should list "FreeBSD FreeBSD-doc FreeBSD-ports" # ls /net/server/z/SRC/FreeBSD ==> gives "ls: /net/hal/z/SRC/FreeBSD: No such file or directory", but should list "head release releng stable" The third and fourth cases are wrong. Also, at all times only the server's root directory is mounted, as shown by "df -t nfs".
It's a known problem, I'm afraid. Basically, the current version of autofs doesn't work with what's called "multiple mounts", ie mount points "shadowed" by other mount points. In this example here, the "/" shadows everything underneath it. The workaround would be to not export "/", or export it under some other path.
I have come across another issue which has the same cause. The server hal also exports: /z/srcs/test /z/srcs/test/rpi /z/srcs/test/rpi/DexterInd /z/srcs/test/rpi/FreeBSD /z/srcs/test/rpi/tmp_ports The corresponding map (with "/auto/srcs auto_srcs" in auto_master) is: hal/test hal:/z/srcs/test hal/test/rpi hal:/z/srcs/test/rpi hal/test/rpi/DexterInd hal:/z/srcs/test/rpi/DexterInd hal/test/rpi/FreeBSD hal:/z/srcs/test/rpi/FreeBSD hal/test/rpi/tmp_ports hal:/z/srcs/test/rpi/tmp_ports Result: - On the client, I can see /auto/srcs/hal/test, but nothing under /auto/srcs/hal/test/rpi. Expected result: - Contents of the subdirectories should also be visible. This problem gets worse with zfs because zfs makes it easy (and for various reasons desirable) to create many filesystems. I think a solution could be that autofs only starts serving a mountpoint when that mountpoint becomes available and does not create all mountpoints it serves right away. This should also take care of the unmount case: The parent filesystem would remain busy as long as a subdir is used as a mountpoint, and could therefore not be unmounted by autounmountd. And while I am already writing a wish list: I have been a heavy user of the various conditions amd(8) offers, plus its "link" target. Would that be possible also for autofs? -- Martin
An important difference between indirect and direct automount maps is that for the former, autofs is mounted at the root of the indirect map, whereas for the latter, autofs is mounted at each leaf of the direct map. Indirect map: # cat /etc/auto_master /auto/system auto_system # cat /etc/auto_system host1/ROOT host1:/ host1/usr host1:/usr host2/ROOT host2:/ # mount -p ... map auto_system /auto/system autofs rw 0 0 ... Direct map: # cat /etc/auto_master /- auto_system # cat /etc/auto_system /auto/system/host1/ROOT host1:/ /auto/system/host1/usr host1:/usr /auto/system/host2/ROOT host2:/ # mount -p ... map auto_system /auto/system/host1/ROOT autofs rw 0 0 map auto_system /auto/system/host1/usr autofs rw 0 0 map auto_system /auto/system/host2/ROOT autofs rw 0 0 ... I think this should be mentioned in the man page somewhere (maybe I have overlooked it). Also it might be mentioned that only with direct maps is it possible to mount a filesystem directly alongside existing files; for example, only for direct maps other unrelated files may exist in /auto/system/host1, for example /auto/system/host1/README. This last point actually is related to my comment #2 from yesterday: I think that even for indirect maps, autofs should be mounted at the leaves instead of the indirect map's root. This might then help in implementing the feature of mounting remote filesystems in subdirectories of remote filesystems. And, again, it would be nice to have -fstype=symlink. And conditions together with multiple alternate mounts for a single mountpoint, as in amd(8) (although I understand that this could be approximated using the executable map feature, albeit without autofs following dynamic updates to such maps). :-) -- Martin
batch change: For bugs that match the following - Status Is In progress AND - Untouched since 2018-01-01. AND - Affects Base System OR Documentation DO: Reset to open status. Note: I did a quick pass but if you are getting this email it might be worthwhile to double check to see if this bug ought to be closed.
Seems this won't ever be supported.