On Wed, 2009-02-18 at 16:19 -0500, Jeff Garzik wrote: > I think I may have found a tiny NFSv4 client bug. What I am seeing: > > 1. On Linux NFS client (2.6.29-rc2), issue chown(1) to change the owner > of the file (causing SETATTR:OWNER to be issued) > > 2. My userland NFS server returns NFS4ERR_DENIED for the SETATTR op > > 3. Linux NFS client returns EIO (I/O error) to userland > > That was a bit unexpected. I would have guessed EPERM, perhaps. > > Jeff I'd put this down as a server bug, as rfc 3530 really reserves the error NFS4ERR_DENIED for the LOCK/LOCKT/LOCKU operations. In the case of a chown(), I'd expect the server to return NFS4ERR_PERM when failing because the caller is not root or the file owner. The client will then correctly translate that into an EPERM... Cheers Trond -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
