[Bug 147881] [zfs] [patch] ZFS "sharenfs" doesn't allow different "exports" options for different hosts
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Tue, 25 May 2021 16:05:56 UTC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=147881 --- Comment #23 from dgilbert@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.