Buyer Beware: A Major Change in NFS is about to happen

[Steve Dickson]

On 09/30/2009 07:22 AM, Howard Wilkinson wrote:
> Steve,
> 
> just for clarity what you are actually saying is that.
> On Tue, 2009-09-29 at 22:45 -0400, Steve Dickson wrote:
>> On 09/29/2009 09:42 PM, Chris Adams wrote:
>>> Once upon a time, Steve Dickson <SteveD at redhat.com> said:
>>>> On the server (Which is suggested):
>>>>    * Add the following entry to the /etc/exports file:
>>>>      / *(ro,fsid=0) Note: 'fsid=0' is explained in the exports(5) man pages.
>>>
>>> The "suggested solution" is to change your NFS servers (that work just
>>> fine with other clients today) to export the root filesystem to
>>> everybody?
>>>
>> Unfortunately the answer to your question yes... 
>>
>> With version 4 there is this concept of a pseudo root. Which meanings
>> one can define, through exports, what the root of an export
>> can be. Which is a good idea because you can define /export as
>> the root, and nothing above /export can be accessed... 
> But if there is a /data *(ro,fsid=0) export then that will do, but it
> becomes the root of the export tree against which mounts are made?
Yes.. For example say the directory tree under /data looks like
   /data
        dir1/
            subdir1/
        dir2/
            subdir2/

Then the client could do a
     mount server:/ /mnt/

which would make every thing under /data visible, meaning
     ls /mnt/dir1
     ls /mnt/dir2

Now the client could also do a
     mount server:/dir1 /mnt

which would only make the the directories under /data/dir1 visible, meaning
    ls /mnt/subdir1

        
>>
>> So the idea was to use 'fsid=0' to define the V4 root of the
>> exports. Which, in theory is a good idea because you can define
>> the namespace the client have access to. A feature, I believe,
>> is not available in any other NFS implementation... But...  
>>
>> The problem is the V4 protocol requires a pseudo root to exist. 
>> So with Linux servers, if the fsid=0 export does not exist, the
>> mount will die with ENOENT (or 'No such file or directory').
>>
>> Other NFS implementation decided not to support a definable pseudo
>> roots and they just made, under the covers, their '/' as the pseudo 
>> root, along with the appropriate protections.
> So putting the / *(ro,fsid=0) is only adding an export of that part of
> the name space into the tree to make it compatible with pre-V4 name
> spaces.
Exactly...

>>
>> With F-12, I have added code to both the kernel and nfs-utils that will 
>> do both. Allow the 'fsid=0' export to define the pseudo root and 
>> make '/' the pseudo root (with the appropriate protections) when
>> there is not an fsid=0 entry.
>>
>> So Yes, one work around to make F-12 mounts work with Linux servers is 
>> to define a pseudo root on the server with a fsid=0 export. But if
>> that is not an option, you can make the F12 clients only use V3 mount
>> (which would avoid the problem, but not take advantage of the
>> V4 protocol) by set either setting the '-o v3' mount option or 
>> set the Nfsvers=3 in the new /etc/nfsmount.conf file (which would make
>> all mounts from that machine v3 mounts).
>>
> But the downside of the / *(ro,fsid=0) approach is we now have all of
> the root files (but not any other filing systems visible).
No, other mounts files systems would be visible as well..

> 
> So perhaps a better approach would be to specify a /V4root *(ro,fsid=0)
> directory being created and a bind mount for each export from the pre-V3
> name space being made into that tree. Or have I missed something
> entirely?
That sounds like it could work, although it may not be too scalable with
large and complicated export tree... 

The real answer is use a F-12 NFS server since all this stuff goes away..

steved.