Re: mount.nfs: access denied by server

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Aug 25, 2009, at 2:10 PM, J. Bruce Fields wrote:
On Tue, Aug 25, 2009 at 01:40:44PM -0400, Chuck Lever wrote:
On Aug 25, 2009, at 12:49 PM, Tom Haynes wrote:
The MOUNT Version 3 protocol, associated with NFS Version 3, solves
the problem by having the response to the MNT procedure include a
list of flavors in the MNT procedure. Note that because some NFS
servers will export file systems to specific lists of clients, with
different access (read-only versus read-write), and with different
security flavors, it is possible a client might get back multiple
security flavors in the list returned in the MNT response. The use of
one flavor instead of another might imply read-only instead of read-
write access, or perhaps some other degradation of access. For this
reason, a NFS client SHOULD use the first flavor in the list that it
supports, on the assumption that the best access is provided by the
first flavor. NFS servers that support the ability to export file
systems with multiple security flavors SHOULD either present the best
accessing flavor first to the client, or leave the order under the
control of the system administrator.



It sounds pretty clear,

Depends on how you define "best access." Besides there's no indication in the returned list of whether the access granted by the server will be
r/w, r/o, or what.

For that reason, all servers I know of have decided to leave the "best
access" decision to the server administrator.

the server SHOULD order them in some fashion and the client SHOULD
pick the first one it supports in the list. It is not 'MUST', but if
all servers and clients follow the same
algorithm, it becomes accepted practice.

There was a reason for picking the last one on the list rather than the
first, but I don't remember what it was.  Clients ought to behave
consistently across implementations, but we unfortunately have some
behavioral precedents.

Yes, and we need some workarounds for those, as previously discussed,
but the above-quoted SHOULD can still be mostly honored.

I appreciate the use cases Tom posted, but given that our server sometimes tries to compensate for the "use the last flavor listed" behavior of some clients, I would like to understand better what our kernel client needs to do.

Perhaps we should discuss this in person.

Having said that, our nfssec(5) states that a client can pick any of
the modes in the list.

But our server returns them in the order entered in the share by the
admin.

Which seems like it too ignores the 2623 prescription...?

We declare the ordering a policy issue and leave it to the server
administrator. The linux server does this as well, and the behavior is
documented in the exports(5) man page.

--b.

--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com



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

[Index of Archives]     [Linux Filesystem Development]     [Linux USB Development]     [Linux Media Development]     [Video for Linux]     [Linux NILFS]     [Linux Audio Users]     [Yosemite Info]     [Linux SCSI]

  Powered by Linux