On Mon, Sep 24, 2001 at 10:11:19PM -0700, Andrew Gillham wrote:

> > then I think the behaviour is particularly broken (and the error
> > mentioned didn't even come close to describing the real problem or
> > cause, which doesn't help).
> 
> While I agree the restriction is not ideal, it is not as bad as you're
> thinking.

All situations are different, and this is certainly not a worst-case
scenario - I believe even the mid-sized NFS server would be limited by
such unjust restrictions.

> You basically must have the same _options_ for each exported directory
> that shares a common file system on the server. 
> e.g.:
>   /home/export/root -maproot=0 host1 host2
>   /home/export/swap -maproot=0 host3
> 
> This should work fine, sinces the options are matching.

that makes sense.

> > or did I misinterpret?
> 
> Only slightly, and it is non-obvious I will agree.  One other major flaw
> in our mountd is that if a non-existent host is listed in /etc/exports, mountd
> will invalidate the entire exported file system!  If "host1" has can't be
> resolved in my example above, /home/export/root is _not_ exported, even though
> host2 exists.  Imagine if you have 10 machines listed on the exports line and
> make a change to a server that has been up for weeks.  Oops!  Forgot that host
> xyzzy no longer exists and I just ran /etc/rc.d/mountd reload and screwed my
> remote clients!

Indeed, I also ran into this while trying to export a directory to only
IPv6 clients and with different options - the only way I could make it
work was to not export anything else in the same file system.

If you were exporting a few directories, and wanted to add one with
maproot=0, the only way for it to work would be if you used maproot=0
on _all_ of them - obviously an unacceptable situation in any real-world
production system.

g.