NFS4ERR_DENIED becomes EIO?

NFS4ERR_DENIED becomes EIO?

[Jeff Garzik]

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


--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: NFS4ERR_DENIED becomes EIO?

[Trond Myklebust]

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-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: NFS4ERR_DENIED becomes EIO?

[Jeff Garzik]

Trond Myklebust wrote:
> 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...

So noted...  thanks a bunch!  I'll make that change.

	Jeff


--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html