Date: Sat, 28 Nov 2020 05:46:15 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 251363] use unionfs as a disk-cache for NFS [feature] Message-ID: <bug-251363-227-xqY8umM5UZ@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-251363-227@https.bugs.freebsd.org/bugzilla/> References: <bug-251363-227@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=3D251363 Gunther Schadow <raj@gusw.net> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.freebsd.org/bu | |gzilla/show_bug.cgi?id=3D2= 514 | |33 --- Comment #14 from Gunther Schadow <raj@gusw.net> --- Cross referencing the bug 251433 I just filed, since that is in fact a real bug. The question is does it really matter to me? What is my workaround? Clearly I need to be able to make the copy on the upper layer. And it is ro= ot that must make that copy. The effective user id to decide if the VOP_CREATE= is allowed must be root, or whatever user did the mount_unionfs. Not the user accessing the file right now. The owner uid and gid should be exactly that from the lower layer. Not the = euid of the user accessing the file. I need to understand how this VOP_CREATE ultimately works.=20 Note that it seems to work right with the shadow directories. So that might= be a clue. --=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-251363-227-xqY8umM5UZ>