I found that I was unable to selectively NFS export my ZFS filesystems such that some hosts had "-maproot=0" and others had "-maproot=nobody:nobody". The syntax and operation of 'zfs set sharenfs="xxx" <poolname>' followed by "zfs share -a" doesn't allow for a multi-valued 'xxx'. Fix: Here's a patch to the compatibility shim "fsshare.c" that allows the following syntax for "sharenfs='xxxx' where 'xxxx' can be: (1) <export_options>... <export_hosts>... (2) <export_options_1>... <export_hosts_1> ; <export_options_2>... <export_hosts_2>... ; ... <export_options_n>... <export_hosts_n>... Empty sets of '<exports_options_n>... <exports_hosts_n>...' are allowed (i.e.: multiple ';'s with only whitespace between them. Comments (with a leading '#') for '<exports_options_n>... <exports_hosts_n>...' are supported to allow a ZFS administrator to disable a particular configuration. Patch attached with submission follows: How-To-Repeat: (1) Set up ZFS based NFS host (2) Set up two NFS clients, one which should have "root" access to the NFS exports from the ZFS host, one which shouldn't (3) Try to make it so.
Responsible Changed From-To: freebsd-bugs->freebsd-fs Over to maintainer(s).
Please implement this or a similar patch. I need this in my dual IPv4/IPv6 setup, where it is necessary to have something like /tank/vol -network 192.168.0.0 -mask 255.255.0.0 /tank/vol -network fec0:0:0:1::/56 in /etc/zfs/exports in order to get both IPv4 and IPv6 clients to work. Regards, Martin
My patch is IPv4/IPv6/DNS agnostic - it ought to work either way. NFSv4 = might be a problem due to the syntax differences in /etc/exports = (/etc/zfs/exports). All my patch does is use ';' as a special character to allow multiple = values (like you want) for each export. Each value is prefixed by the = mount point and written to /etc/zfs/exports. I'm still running it - but it's for a home file server where I want to = restrict "root" access from certain VPNs. Given that all it does is = change the output to /etc/zfs/exports, which is handled by the regular = NFS export mechanism, I don't think that there should be any significant = difference between home and production/enterprise use - unless NFS = exports keel over when there's hundreds of mount points (easy to do with = ZFS) rather than tens. My home set up is exporting only 25 mount = points. --- Richard On Oct 15, 2010, at 3:15 AM, Martin Birgmeier wrote: > Please implement this or a similar patch. I need this in my dual = IPv4/IPv6 setup, where it is necessary to have something like >=20 > /tank/vol -network 192.168.0.0 -mask 255.255.0.0 > /tank/vol -network fec0:0:0:1::/56 >=20 > in /etc/zfs/exports in order to get both IPv4 and IPv6 clients to = work. >=20 > Regards, >=20 > Martin
I made another similar patch which does not include commented lines. It's for RELENG_9_0 -- Quentin Rameau
Thank you very much for patch, is there any time perspective of aplying thi= s patch (or possibility) to system? Richard, your patch has a little bug, if there is - in the hostname, it is = expanded as whitespace and throw mistake to log. Radek
On Aug 17, 2012, at 7:14 AM, Radek Krej=E8a wrote: > Thank you very much for patch, is there any time perspective of = aplying this patch (or possibility) to system? >=20 > Richard, your patch has a little bug, if there is - in the hostname, = it is expanded as whitespace and throw mistake to log. >=20 > Radek I've just applied my patch to FreeBSD-9 - and was thinking of expanding = it in order to be able to deal with NFS-V4 exports. (I was thinking of expanding '%f' as the filesystem name so the = filesystem name can occur in any part of the string.) Do you mean that if there is a "-" (hyphen) in the hostname, such as = "my-nfs-clients.local.com"), it gets mangled? I'll look at that.=
The purpose of the sharenfs property is not to completely replace /etc/exports. What we have is just a tricky workaround that populates /etc/zfs/exports. T he commands to NFS-share filesystems on illumos are different and our options are mostly incompatible with illumos. So you e.g. sharenfs="-maproot=root" is invalid if imported on a Openindiana system. Have you considered using just /etc/exports for more-complex configurations? -- Martin Matuska FreeBSD committer http://blog.vx.sk
On Sep 6, 2012, at 9:36 AM, Martin Matuska wrote: > The purpose of the sharenfs property is not to completely replace > /etc/exports. > What we have is just a tricky workaround that populates = /etc/zfs/exports. > T > he commands to NFS-share filesystems on illumos are different and our > options are mostly incompatible with illumos. > So you e.g. sharenfs=3D"-maproot=3Droot" is invalid if imported on a > Openindiana system. >=20 > Have you considered using just /etc/exports for more-complex = configurations? Yes. It doesn't scale - and scaling is the whole purpose of NFS. It = also makes it difficult for distributed management of access rights to = end-user NFS exports. I wouldn't mind using a FreeBSD specific attribute to populate = /etc/zfs/exports with FreeBSD specific values such as is used for = swapping to ZFS. Merging the two different attributes would either be = tricky, or the use of the FreeBSD one should cause "sharenfs" to be = ignored entirely. > --=20 > Martin Matuska > FreeBSD committer > http://blog.vx.sk >=20
On Fri, Sep 07, 2012 at 06:10:07PM +0000, Richard Conto wrote: > > > The purpose of the sharenfs property is not to completely replace > > /etc/exports. > > What we have is just a tricky workaround that populates = > /etc/zfs/exports. > > T > > he commands to NFS-share filesystems on illumos are different and our > > options are mostly incompatible with illumos. > > So you e.g. sharenfs=3D"-maproot=3Droot" is invalid if imported on a > > Openindiana system. > >=20 > > Have you considered using just /etc/exports for more-complex = > configurations? > > Yes. It doesn't scale - and scaling is the whole purpose of NFS. It = > also makes it difficult for distributed management of access rights to = > end-user NFS exports. > > I wouldn't mind using a FreeBSD specific attribute to populate = > /etc/zfs/exports with FreeBSD specific values such as is used for = > swapping to ZFS. Merging the two different attributes would either be = > tricky, or the use of the FreeBSD one should cause "sharenfs" to be = > ignored entirely. This is a limitation of exports(5) format, that does not allow to specify all settings for one file system in one line. When I had similar task I allowed to redefine options in one line, so address specifications can inherit already specified settings and can get changed or new settings. For example: /fs -ro -mapall user1 host1 -mapall user2 host2 host3 -rw host4 Here, /fs is exported read-only for host{1,2,3} and read-write for host4, all users are mapped to user1 for host1 and all users are mapped to user2 for host{2,3,4}. More information about format of NFS exports settings that I propose is available here: http://nfse.sourceforge.net/nfs.exports.5.html
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.
Please note, on dual stack systems this is required by practically the _default_ configuration. I was just rejiging my network a bit. I had 100's of hosts listed in my nfsshare property. It would all boil down to two network statements ... one ipv4 and one ipv6. EPHASIS MINE: this is a DEFAULT CONFIG IMHO on DUAL STACK systems. Something like sharenfs="-network 1234:5678:9012:3456::/64 -network 192.168.0.0/24"
I considered re-writing my patch to use a FreeBSD specific attribute for my syntax (or an expanded one that would allow white-space in the pathnames - but that would have involved modifying how the "exportfs" command parsed .../exports files.) But frankly, this was a sort of proof-of-concept that addressed a need for adapting to the FreeBSD .../exports file format that wasn't being addressed. And the FreeBSD project didn't care enough. Of course there are compatibility issues with the Solaris version of ZFS - because "sharenfs" is implemented as a hack to begin with. Pushing the administration of ZFS mount points into a hand-administered /etc/exports files ignores scalability issues. The FreeBSD .../exports file format doesn't scale well and is an ugly hack itself. A proper fix to this should include revisiting whether that file format should be extended or supplemented.
So where do we go to have this "larger" conversation? Is there a PR for the exports format? Is there anyone working on the issue? Can I work on the issue (still need to have the discussion since the format needs to make people happy to get adopted)...
If I knew, I'd try. The format of the "exports" files in Linux, FreeBSD, and Solaris are different. The FreeBSD "fsshare" utility is an attempt to approximate some of the functionality without considering the other aspects of Solaris sharing (including CIFS file sharing) and system administration that ZFS filesystem attributes encode. Having a FreeBSD specific attribute for this seems like the best solution, as "nfsshare" is really a Solaris specific solution.
(In reply to Richard S. Conto from comment #14) ... hrm... this is becoming _the_ place to discuss this, it seems. Several people I've talked to have already noticed the activity. Anyways... someone proposed the ';' solution ... to make multiple lines. Someone else, I think (somewhere) said that there are hard limits on the length of zfs attributes. The auto-snapshot bit in zfs-tools uses a "custom" attribute. Putting these all together makes me think: freebsd.org:export_0 = <line 1 of export> freebsd.org:export_1 = <line 2 of export> ... it may even be true that export_<*> is available where the suffix could just be something meaninful to the admin in question. To be clear, "<line 1 of export>" is the /etc/exports line without the path.
Personally, I think Quentin Rameau's patch is all you need. I don't think embedded comments in the sharenfs property are needed and it just makes the patch much more involved. The one slightly scary thing about it is that "; ;" is allowed and results in the file system being exported read/write to the world, because it will generate a line with just the mountpoint in it. (I never use ZFS, so I don't know if a blank sharenfs property is allowed and results in the same thing?) It might be safer to not allow that case? One other change would be to take the "const" off the argument for translate_opts() and don't have it strlcpy() the shareopts, since they have already be copied by the caller with Quentin's patch. I don't recommend changing the exports(5) syntax for two reasons: 1- Any change must be 100% backwards compatible or it is a POLA violation and can't go in FreeBSD. (ie. Any exports file that worked before must still work and provide the same semantics.) 2 - Parsing of exports file(s) is done by a function called get_exportlist_one() in src/usr.sbin/mountd/mountd.c and, if you look at it, you will find the code convoluted and difficult to modify without breaking it. I'm not a ZFS guy, so I can't help w.r.t. getting this in FreeBSD. I'd suggest you post on a FreeBSD mailing list about this and hope that someone on the ZFS side is interested in getting the patch in.
Is there any chance of seeing this patch (fsshare.c-multipleexports.patch) soon in releng/12.1? stable/12? head?
Does this patch have any problems? https://bugs.freebsd.org/bugzilla/attachment.cgi?id=107165&action=diff
Do we have an official solution for that? Or is it abandoned ?
I've abandoned it. My use-case no longer applies. Given the limits expressed in this discussion - a technical limitation on the length of ZFS property value lengths, and a political reluctance to allow self-documenting configurations, if I were to re-implement this, I'd do this entirely outside of ZFS as it'd be a FreeBSD-only solution anyway. A generic "share export builder" tool, like "rebuilder" for firewall rules, that would implement a common configuration format and produce appropriate configurations for FreeBSD, Linux, Solaris - for NFS, NFS4, CIFS, et. al. comes to mind - and would likely be a dead-end. The classic "exports" format is crufty. The inability to share filesystems/paths that contain whitespace was tolerable in a teletype focused world 40 years ago. Continuing to support that old format is not the same thing as supporting ONLY that old format, but the later is where we're at.
TBH, if attribute length is any issue, why not have a set of attributes? share_nfs.<label> where each attribute specifies it's own portion of the share record?
I've seen configuration schemes like that, and they tend to be fragile. The questions that come to my mind off-hand are: (1) Are multiple attributes concatenated as a single string or as separate statements? (2) How is ordering done? Lexically, such that "freebsd_share_10" comes before "freebsd_share_2" or is some syntax imposed on the attribute name itself (and what happens to attributes that partially match the syntax?) (3) What happens if "intermediate" attributes are removed or edited? Also, different protocols seem to require different sharing syntax, especially when identity management is involved. ---- And any solution will be FreeBSD specific - and not necessarily portable to other systems. At that point, just implement it outside of ZFS anyway.
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.
Keyword: patch or patch-ready – in lieu of summary line prefix: [patch] * bulk change for the keyword * summary lines may be edited manually (not in bulk). Keyword descriptions and search interface: <https://bugs.freebsd.org/bugzilla/describekeywords.cgi>
ping?
See comment #9 by Andrey Simonenko - this really seems the right thing to do. See also my feature request in bug #261411. -- Martin
Wow, and here I thought I was just too stupid to figure out the syntax... Seeing that this problem has been known for 14 years, I don't assume a fix is incoming? :'(