Date: Tue, 23 Jan 2001 11:10:05 -0800 From: Guy Harris <gharris@flashcom.net> To: Guy Harris <gharris@flashcom.net>, Neil Brown <neilb@cse.unsw.edu.au>, Linux NFS mailing list <nfs@lists.sourceforge.net>, FreeBSD Stable <freebsd-stable@freebsd.org> Subject: Re: [NFS] Incompatible: FreeBSD 4.2 client, Linux 2.2.18 nfsv3 server, read-only export Message-ID: <20010123111005.D344@quadrajet.flashcom.com> In-Reply-To: <20010123162930.B5443@emma1.emma.line.org>; from matthias.andree@stud.uni-dortmund.de on Tue, Jan 23, 2001 at 04:29:30PM %2B0100 References: <20010123015612.H345@quadrajet.flashcom.com> <20010123162930.B5443@emma1.emma.line.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Jan 23, 2001 at 04:29:30PM +0100, Matthias Andree wrote: > Okay. So, as a conclusion, my original bug report boils down to: > > "You cannot mount read-only file systems with NFS v3 from a Linux 2.2.18 > server to a FreeBSD 4.2-STABLE client. Use NFS v2 instead." > > The question remains: Linux kernel problem or FreeBSD client problem? I'd consider the Linux kernel sending NFS3ERR_ROFS over the wire in the response to an ACCESS call checking write access to be an error on the part of the Linux NFS server, as 1) the spec doesn't list NFS3ERR_ROFS as a valid reply and 2) as per my other mail, it means it can't properly report what's permitted if the ACCESS call checks both read and write access - NFS3ERR_ROFS doesn't say "reading is OK, writing isn't" Presumably that's why the protocol spec doesn't list NFS3ERR_ROFS (Perhaps it would've been better had the V3 protocol specified that either 0 or an NFS3ERR_xxx value be supplied for each of the permission bits checked, although that raises the question of whether any server would, say, allow read access and allow write access but disallow simultaneous read/write access.) One might also consider it a FreeBSD client problem that it can't cope with this, if the Solaris client can, although that one might be a weaker claim (i.e., the Linux server is arguably violating the spec, whilst the FreeBSD client is merely apparently not doing as good a job of coping with servers violating the spec as the Solaris client is, in this case). 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?20010123111005.D344>