Date: Tue, 23 Jan 2001 16:29:30 +0100 From: Matthias Andree <matthias.andree@stud.uni-dortmund.de> To: Guy Harris <gharris@flashcom.net>, Neil Brown <neilb@cse.unsw.edu.au>, Linux NFS mailing list <nfs@lists.sourceforge.net>, reiserfs-list@namesys.com, FreeBSD Stable <freebsd-stable@freebsd.org> Subject: Re: [NFS] Incompatible: FreeBSD 4.2 client, Linux 2.2.18 nfsv3 server, read-only export (was: Incompatible: FreeBSD 4.2 client, Linux 2.2.18 nfsv3 server, ReiserFS) Message-ID: <20010123162930.B5443@emma1.emma.line.org> In-Reply-To: <20010123015612.H345@quadrajet.flashcom.com>; from gharris@flashcom.net on Tue, Jan 23, 2001 at 01:56:12 -0800 References: <20010123015612.H345@quadrajet.flashcom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Note: when replying, please remove the (was: ) part of the Subject and the reiserfs-list from the recipients. On Tue, 23 Jan 2001, Guy Harris wrote: > Perhaps the Linux server should, in "nfsd_access()", treat "nfserr_rofs" > the same way it treats "nfserr_perm" and "nfserr_acces", and just say > the access type is denied but the access query succeeded, doing the same > thing that Solaris and a future release of the NetApp software will do. > > (It looks as if the FreeBSD NFS server already does that - it treats all > errors from "nfsrv_access()" as meaning "access denied", not "access > call failed", so it treats EROFS in that fashion. The same probably > applies to other BSDs.) > > As for why the V2 client doesn't appear to have this problem, the V2 > client doesn't make an ACCESS call, because NFS V2 doesn't have an > ACCESS call to make. Ah, so it's a protocol difference which keeps Linux server <-> FreeBSD client compatibility here. > If it *was* mounted read-only, was the ext2 file system also mounted > read-only? If not, that might explain it. I looked again, closely, and found in /etc/exports: /space 192.168.0.0/255.255.255.0 /home 192.168.0.0/255.255.255.0(rw) I looked into exports(5) and found that exports assumes ro unless overriden with rw. Not reporting this and attributing the problem to ReiserFS instead of the RO mount (which looks strange to me as a response to a READ request) was my fault, and I apologize to the ReiserFS people for this bogus allegation. ReiserFS is now out of the play. > As for why it's a problem with the FreeBSD client but not the Solaris > client, I'm not sure - a quick look at the 4.2 client code doesn't seem > to show any way in which the EROFS is "sticky" to the extent that it > affects all client accesses, as it doesn't cache the result of an ACCESS > call that failed. It may just be that the Solaris client just ignores > NFS3ERR_ROFS from an ACCESS call and does an access check based on the > permission bits, rather than returning EROFS, whilst the FreeBSD client > returns EROFS; if ReiserFS is returning EROFS bogusly, that might cause > the symptoms in question. 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? -- Matthias Andree 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?20010123162930.B5443>