Date: Wed, 11 Sep 2024 13:02:06 +0000 From: bugzilla-noreply@freebsd.org To: fs@FreeBSD.org Subject: [Bug 281417] Inconsistent restrictions on jailed and sharenfs properties affecting NFS in a VNET jail Message-ID: <bug-281417-3630-1UuCSytXz4@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-281417-3630@https.bugs.freebsd.org/bugzilla/> References: <bug-281417-3630@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D281417 --- Comment #4 from Oliver Kiddle <okiddle@yahoo.co.uk> --- (In reply to Rick Macklem from comment #3) The 'zoned' property is directly analagous to the FreeBSD 'jailed' property. And in this case, it is the 'jailed' property that I have set. I then use zfs-jail(8)/unjail from the vnet jail's exec.created/exec.prestop so the datasets are only mounted and controlled from inside the jail. Setting sharenfs is rather easier and more flexible than /etc/exports. As I mention it is possible to set jailed on a parent dataset and sharenfs on a child. The error message and attempts to treat the two properties as mutual= ly exclusive are thus incompletely applied. And while that could be treated as= the bug making the two properties work together would be more useful. I've just realised that I did have a manual entry in /etc/exports so was not really u= sing the property. With jailed NFS, it should perhaps instead be /etc/zfs/exports within the j= ail that is modified for a jailed dataset. I've been trying different combinations in an effort to get rpc.rquotad to = work from the jail - something I've not as yet been successful with. It needed z= fs allow -e just for zfs userspace to work in the jail. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-281417-3630-1UuCSytXz4>