On Aug 6, 2009, at 11:48 AM, Mike Mackovitch wrote: >> >> 6869153 Problems reported with NFSv4 access to .zfs >> >> When it percolates through the system, you should be able >> to track it with this link: >> >> http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6869153 > > Thanks Rob. > > I imagine the two issues might be different enough that you may want > to separate it into two bugs. > > Regarding the ACCESS issue: it affects both NFSv4 and NFSv3. > Also, it appears that even when performed directly on the ZFS file > system on the server, access(2) calls on the snapshot directory always > return no WRITE access ("Permission Denied"). So, the issue likely > lies deeper than the NFS server code. > Hi Mike,
The .zfs directory isn't a normal directory -- it's more of a meta-directory which provides namespace access to interesting "ZFS things" like snapshots. The .zfs/snapshot directory is populated by zfs itself through non-posix operations (snapshot creation/deletion/rename) as opposed to file creation/rename/removal. I don't expect that ZFS will ever allow the normal/posix operations to modify .zfs or any of its immediate subdirs. I suspect that this is the reason that .zfs and its subdirs are created without write perms. ZFS reports no write access for .zfs and friends, and that seems correct. From a NFS server point of view, if the app running on the client receives the same perms as local user on the server, then the NFS server is doing the right thing. In this case, the access result is the same for NFS clients and local access. I looked at the first issue (GETATTR failing NFS4ERR_INVAL) yesterday, and dtrace showed that it is caused by an error path problem exposed by a VOP_PATHCONF(_PC_XATTR_EXISTS) failure (on .zfs or immediate subdirs). One could argue that ZFS should be more polite when the NFS server drives VOP_PATHCONF() to see if the object has named attrs (as in disclaim support vs. fail the vop), but the NFS server should generate a default value for a mandatory attr regardless (as in return a value of false). This is definitely a bug in our server. Jeff
