Date: Thu, 19 Sep 2024 17:52:51 +0000 From: bugzilla-noreply@freebsd.org To: jail@FreeBSD.org Subject: [Bug 274263] Access to zfs snapshots within a jail return EPERM after a while of operation Message-ID: <bug-274263-29815-TlIbSOCkoJ@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-274263-29815@https.bugs.freebsd.org/bugzilla/> References: <bug-274263-29815@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=3D274263 Jamie Gritton <jamie@FreeBSD.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Closed |In Progress Resolution|FIXED |--- Assignee|jail@FreeBSD.org |jamie@FreeBSD.org --- Comment #15 from Jamie Gritton <jamie@FreeBSD.org> --- Created attachment 253669 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D253669&action= =3Dedit Hack to set the zfs.mount_snapshot parameter It looks like I implemented half a solution, which was worse than no soluti= on at all. I change the description of the parameter to boolean, without realizing that continuing to expect an integer made the kernel reject jail(= 8)'s attempts to set it. I must have tested my fix on a mismatched kernel and userspace, or something. All is not lost, as there's a hack available to work around this. jail_set= (2) can still send an integer, even though jail(8) and libjail(3) will try not = to.=20 I've attached a small hack program than can do the job. You'll need to run= it after the jail is created, e.g. with the following in jail.conf: exec.created +=3D "/path/to/setzfsmount $name"; Unfortunately, this workaround will remain necessary until the kernel is fixed, probably on the next release. --=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-274263-29815-TlIbSOCkoJ>