[Bug 147881] [zfs] [patch] ZFS "sharenfs" doesn't allow different "exports" options for different hosts

From: <bugzilla-noreply_at_freebsd.org>
Date: Tue, 25 May 2021 16:05:56 +0000
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=147881

--- Comment #23 from dgilbert_at_eicat.ca ---
Before ZFS, sharing filesystems was rare and special.  Before ZFS, you
generally wouldn't have a filesystem per user or a filesystem per jail.

So the current "idea" (it's really more idea than method --- or if it's a
method, it's a horribly flawed one) in ZFS is to have an attribute per
filesystem that controls the share --- which is then implemented by collecting
all the attributes into a file (for compatibility).  This is almost required by
ZFS.

The alternative I see is to share a tree of filesystems as a unit --- I have no
idea if ZFS inodes could be trivially be combined into one NFS share --- that
would be the barrier to this idea --- and understand that I'm not suggesting it
--- I'm just exploring the head-space of shares being rare and special again.

Maybe the answer is to have the sharenfs specify an include file for exports
(or some future format)?  One in which $PATH is replaced (maybe a few other
substitution opportunities --- maybe even using other sharenfs attributes). 
Example:

/home's sharenfs="/usr/local/etc/shares.d/sharehome"
/home's sharenfs_FOO="nobody"

/usr/local/etc/shares.d/sharehome:

PATH -maproot=FOO -network 192.168.0.0/24
PATH -maproot=FOO -network 2525:2525:1:2:3::/64

and this is injected into /etc/exports (assuming /home/dgilbert exists and
inherits):

/home -maproot=nobody -network 192.168.0.0/24
/home -maproot=nobody -network 2525:2525:1:2:3::/64
/home/dgilbert -maproot=nobody -network 192.168.0.0/24
/home/dgilbert -maproot=nobody -network 2525:2525:1:2:3::/64

equally, sharenfs could just specify a label... but y'all get the point.

-- 
You are receiving this mail because:
You are the assignee for the bug.
Received on Tue May 25 2021 - 16:05:56 UTC

Original text of this message