Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 12 Apr 2001 19:10:38 +0200
From:      Martin Blapp <mb@imp.ch>
To:        Thomas Quinot <quinot@inf.enst.fr>
Cc:        current@freebsd.org
Subject:   Re: NFS export to netgroup with duplicate hosts
Message-ID:  <Pine.SGI.4.10.10104121836360.3093471-100000@harem.imp.ch>
In-Reply-To: <20010412182900.B30764@cuivre.fr.eu.org>

next in thread | previous in thread | raw e-mail | index | archive | help

> If we manage it, mountd should soon be able to allow different mount flags
> for each path you export in /etc/exports.

I'm sorry. But now after some investigations and talks with Robert
Watson it seems to be clear that this is not possible due the way nfs
works.

It would be easy to fix mountd, and to store somewhere the path where
the export is tied to, but how should nfsd handle this ? He get's a
request for a inode (the namei translation is done on the client side).
The server has now to look which flag set belongs the inode. How can he
see which set of flags belongs to that inode ?

man share_nfs on solaris 7:

     Unlike previous  implementations  of  share_nfs(1M),  access
     checking  for  the  window=, rw, ro, rw=, and ro= options is
     done per NFS request, instead of per mount request.

In suns implementation of nfs is written (man share)

     If  share  commands are invoked multiple times on  the  same
     filesystem,  the  last   share   invocation  supersedes  the
     previous-the options set by the last share  command  replace
     the  old  options. For example, if read-write permission was
     given to usera on /somefs, then to give  read-write  permis-
     sion also to userb on  /somefs:

That means that it's not possible as I get it. I'll do further
investigations to be sure how it works on Solaris exactly.

Martin


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.SGI.4.10.10104121836360.3093471-100000>