Jay Maybe I should write a better phrased and more comprehensive overview on amd (although I have probably more compelling discoveries to share 😏). It is one of those things which never got enough attention and was eventually shadowed by the flow of time. It is a fine tool, even in its ancient and very Unixish design.
I've written maps for all kind of stuff and possible disk arrangements, so that whenever I plug in some flash storage device, it's made immediately accessible. I've also experimented auto-mounting NFS shares and ZFS pools. Well, the target directory for amd maps is itself a NFS export.
Ideally the base should come with some ready to use amd examples, possibly combined with additional devpubd hooks but the default one. Until a we have a better replacement at least.
rvp There's even automountd, but, that needs a custom kernel and is also marked experimental. But, I haven't messed around with either...yet
I don't have exactly fond memories of automountd running on illumos and FreeBSD, whereas I remember several threads on FreeBSD forums about people struggling with it, including myself. Easier to setup than amd, but at the end of the day it's the same story: amd and autofs reflect their Sun legacy to which they're tightly bound. They're designed for shared systems, with a client/server approach in mind. Have a look at How AutoFs Works works. The last time I played with it on NetBSD was on early 7-current, when it was considered not much more experimental than it is today. As I had to spent time configuring mount maps either way I eventually chose the stable fallback, which was already in base.
I'm positive neither autofs nor amd can fully solve the automounting issue on NetBSD as they do on FreeBSD/Solaris. This is again because NetBSD lacks a good udev/devd/hal replacement with editable rulesets and device access privilege control, which is needed to automatically set write permissions on automounted storage devices and network shares for unprivileged users.