I am trying to expose a hierarchy of home directories to a number of FreeBSD jails. The home directories are configured such that each is a unique ZFS dataset. The jails are used for development work and hence are created and destroyed on a regular basis.

My first thought was simply to use nullfs to mount /home inside the jail, but nullfs doesn't provide any way to access subordinate filesystems.

My second thought was to export the directories via NFS and then run the automounter daemon (amd) inside each jail. This would have Just Worked...if it were possible to perform NFS mounts inside a jail. But it's not.

My third thought was to run amd on the host and provision nullfs mounts into the jails...but amd support for nullfs doesn't exist.

My fourth thought was to go back to exporting the directories using NFS, because of course amd works with NFS, right? Unfortunately, rather than mounting a directory on the target mountpoint, amd likes to mount things in a temporary location (/.amd_mnt/...) and then create a symlink...which, of course, is useless inside the jail environment.

So maybe you could use nullfs to expose a subdirectory of /.amd_mnt to the jail? No! This brings us back to my first attempt, in which we find that there is no way to access subordinate filesystems using nullfs.

And then my head exploded.

Is there a good solution for what I'm trying to do? A bad solution would be to run a script after booting the jail that would create multiple nullfs mountpoints for each home directory, but this is pretty clunky -- it would need to be run periodically to take into account new directories or removed directories. So basically I would have to write a bad automounter.

There must be a better way. Help me, Serverfault, you're my only hope!

UPDATE 1: It occurred to me that I might be able to solve part of the problem with pam_mount, although this would at best be incomplete. Also, it's not clear from the documentation whether or not pam_mount can automatically create the target mountpoint. If it requires the mountpoint to exist a priori, this solution wouldn't be any better than the bad automounter I've already proposed.

UPDATE 2: As discussed in the answers below, setting VFCF_JAIL on the NFS filesystem does allow jails to perform NFS mounts. Unfortunately, the automounter continues to behave that are unhelpful, and when run in a jail appears to be very good at getting wedged in such a way that a system reboot is necessary to remove the process entry.

  • 1
    And if you're willing to port those features over to FreeBSD that would be awesome. Seriously, the behavior of the standard Linux automounter would be perfect for this, too, since it actually mounts filesystems on the target mountpoint, rather than using symlinks. – larsks Jun 16 '11 at 13:40
  • 4
    I blame a severe lack of time. And perhaps just a little bit of a lack of motivation... >.> – Ignacio Vazquez-Abrams Jun 16 '11 at 13:42
  • 15
    +1 Solely for the awesome title. :) – Shauna Jun 16 '11 at 17:12
  • 4
    It concerns me how specific your particular method of execution is – Mark Henderson Jun 17 '11 at 1:22
  • 2
    Oh, @Wilshire, you're no fun. – larsks Jun 17 '11 at 18:22

Why, hello there Lars! That's a fascinating question you've asked, and after some research I may have found an answer for you.

According to this and other posts out there, it may be possible to set the VFCF_JAIL attribute on the NFS filesystem provider, which would in theory allow jails to perform NFS mounts. This may, in turn, allow one to run amd inside the jail...which would neatly solve this issue.

I'll try rebuilding the kernel this evening to see how things work out. It's not necessarily the greatest solution (since it means you need to make sure this change persists across future kernel updates), but it would be interesting if it works.

And remember...

           ___________    ____                                           
    ______/   \__//   \__/____\                             
  _/   \_/  :           //____\\                             
 /|      :  :  ..      /        \                         
| |     ::     ::      \        /                             
| |     :|     ||     \ \______/     Don't try to rebuild the
| |     ||     ||      |\  /  |        kernel remotely because
 \|     ||     ||      |   / | \         you know you're just
  |     ||     ||      |  / /_\ \        going to hose the server.
  | ___ || ___ ||      | /  /    \    
   \_-_/  \_-_/ | ____ |/__/      \   
                _\_--_/    \      /   
               /____             /  
              /     \           /    
  • 6
    Thanks, Lars; I wish I had taken your advice, because now I can't access the server and I'll have to wait until I get home to try this out. – larsks Jun 17 '11 at 19:52
  • 10
    +1 for the LOLs. Also consider this a right of passage - Driving out to your server in the middle of the night to boot KERNEL.OLD (or KERNEL.GENERIC - You do keep an up-to-date GENERIC on your systems, right? If not, you should start.) teaches many lessons... – voretaq7 Jun 17 '11 at 20:36
  • I keep a net-bootable copy of mfsbsd handy, too, which has saved me from a number of boot-loader related problems. – larsks Jun 17 '11 at 20:45
  • 1
    Setting VFCF_JAIL made NFS mounts work, but the automounter continues to bedevil me. – larsks Jun 19 '11 at 12:47
  • 1
    Eh, I've been using automount for home directories for better than a decade in various environments and I've been happy with it. Mind you, this is the Linux (and Solaris) automounter, not amd. – larsks Jun 20 '11 at 19:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.