Date: Wed, 24 Jan 2001 04:19:41 +0100 From: Matthias Andree <matthias.andree@stud.uni-dortmund.de> To: Bjoern Groenvall <bg@sics.se> Cc: FreeBSD Stable <freebsd-stable@FreeBSD.ORG>, Linux NFS mailing list <nfs@lists.sourceforge.net> Subject: Re: [NFS] Incompatible: FreeBSD 4.2 client, Linux 2.2.18 nfsv3 server, read-only export Message-ID: <20010124041941.B28212@emma1.emma.line.org> In-Reply-To: <wuofwynsj5.fsf_-_@bg.sics.se>; from bg@sics.se on Tue, Jan 23, 2001 at 17:26:54 %2B0100 References: <20010123015612.H345@quadrajet.flashcom.com> <20010123162930.B5443@emma1.emma.line.org> <wuofwynsj5.fsf_-_@bg.sics.se>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 23 Jan 2001, Bjoern Groenvall wrote: > Or perhaps we should blame RFC1813? No. > However, 1813 says that ACCESS > should return one of the following errors > NFS3ERR_IO > NFS3ERR_STALE > NFS3ERR_BADHANDLE > NFS3ERR_SERVERFAULT > ,and "The client encodes the > set of permissions that are to be checked in a bit mask. > The server checks the permissions encoded in the bit mask. > A status of NFS3_OK is returned along with a bit mask > encoded with the permissions that the client is allowed.". That's what Linux does not do ATM. > It also says > "NFS3ERR_ROFS > Read-only file system. A modifying operation was > attempted on a read-only file system." ACCESS is not a modification attempt, so ROFS in response to ACCESS is always bogus. There is no contradiction here, so the server is at fault. > The RFC does not explicitly mention how to handle read-only file > systems. No need to. > I think it would be really nice if the server returns those > permissions that the client is allowed with the write bits unset. That > is also the solution that Guy came up with. Agreed. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010124041941.B28212>