* NFS4ERR_DENIED becomes EIO?
@ 2009-02-18 21:19 Jeff Garzik
2009-02-18 21:59 ` Trond Myklebust
0 siblings, 1 reply; 3+ messages in thread
From: Jeff Garzik @ 2009-02-18 21:19 UTC (permalink / raw)
To: linux-nfs; +Cc: linux-fsdevel
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
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: NFS4ERR_DENIED becomes EIO?
2009-02-18 21:19 NFS4ERR_DENIED becomes EIO? Jeff Garzik
@ 2009-02-18 21:59 ` Trond Myklebust
[not found] ` <1234994399.8412.206.camel-rJ7iovZKK19ZJLDQqaL3InhyD016LWXt@public.gmane.org>
0 siblings, 1 reply; 3+ messages in thread
From: Trond Myklebust @ 2009-02-18 21:59 UTC (permalink / raw)
To: Jeff Garzik; +Cc: linux-nfs, linux-fsdevel
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
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: NFS4ERR_DENIED becomes EIO?
[not found] ` <1234994399.8412.206.camel-rJ7iovZKK19ZJLDQqaL3InhyD016LWXt@public.gmane.org>
@ 2009-02-19 1:22 ` Jeff Garzik
0 siblings, 0 replies; 3+ messages in thread
From: Jeff Garzik @ 2009-02-19 1:22 UTC (permalink / raw)
To: Trond Myklebust; +Cc: linux-nfs, linux-fsdevel
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
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2009-02-19 1:22 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-02-18 21:19 NFS4ERR_DENIED becomes EIO? Jeff Garzik
2009-02-18 21:59 ` Trond Myklebust
[not found] ` <1234994399.8412.206.camel-rJ7iovZKK19ZJLDQqaL3InhyD016LWXt@public.gmane.org>
2009-02-19 1:22 ` Jeff Garzik
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox