[NFS-Ganesha-Support] Re: NFS4 reexporter question

Sure, should work fine.  Ganesha handles multiple exports fine, either by the same FSAL, or multiple FSALs, or combinations.  The only caveat is that, if one of the exports uses the pseudo path "/", then all the paths to the other exports must exist in the backing FS for that export.  It's much easier to just give every export a unique pseudo path. Daniel On 2/5/19 12:44 PM, Jeff Becker wrote: > Thanks to everyone for their help. I got this working on a single > NFS4 proxy export. My use case is a bit different. What I'd like to > do is export a ganesha server directory that mounts several remote > directories over NFS. Can I do this using FSAL PROXY or possibly even > VFS? Thanks. > > -Jeff > > On 1/28/19 1:51 PM, Frank Filz wrote: >>> Another question.. >>> >>> On 1/28/19 9:58 AM, Daniel Gryniewicz wrote: >>>> On 1/28/19 12:45 PM, Jeff Becker wrote: >>>>> One more question below... >>>>> >>>>> On 1/28/19 9:37 AM, Daniel Gryniewicz wrote: >>>>>> A lot of that looks very out-of-date. The description of what goes >>>>>> in the Path statement is correct, but there is no longer an >>>>>> NFSv4_Proxy section.  Instead, configuration goes in the FSAL >>>>>> subsection of the export.  You can look at the sample proxy.conf in >>>>>> the repo here: >>>>>> >>>>>> https://github.com/nfs-ganesha/nfs-ganesha/blob/next/src/config_samp >>>>>> >>>>>> les/proxy.conf >>>>>> >>>>>> >>>>>> Or you can look at the man page for FSAL PROXY here: >>>>>> >>>>>> https://github.com/nfs-ganesha/nfs-ganesha/blob/next/src/doc/man/gan >>>>>> >>>>>> esha-proxy-config.rst >>>>>> >>>>>> >>>>>> (And sorry for writing PSEUDO in my last email, I meant PROXY) >>>>>> >>>>>> Daniel >>>>>> >>>>>> On 1/28/19 12:29 PM, Jeff Becker wrote: >>>>>>> Hi, >>>>>>> >>>>>>> On 1/25/19 5:36 AM, Daniel Gryniewicz wrote: >>>>>>>> The path given to PSEUDO needs to be the full path exported by >>>>>>>> the >>>>>>>> other NFS server, not any kind of local mount. So, when you mount >>>>>>>> the other server directly, you do this: >>>>>>>> >>>>>>>> mount -t nfs <server>:<remotepath> <localpath> >>>>>>>> >>>>>>>> What needs to go in that Path config statement is <remotepath> >>>>>>>> not >>>>>>>> <localpath>.  PSEUDO isn't accessing a mount (and, indeed, you >>>>>>>> probably should not have the remote server mounted on the Ganesha >>>>>>>> box), it's acting as it's own NFS client, and translating NFS >>>>>>>> calls directly. >>>>> Do you mean on the client mounting the Ganesha server, I should not >>>>> also be directly mounting the remote filesystem for which the >>>>> Ganesha >>>>> server is proxying access? Thanks. >>>>> >>>> Hmm...  I think a full explanation is necessary.  There are three >>>> machines involved here.  First, the original NFS server, hosting the >>>> base filesystem.  Lets call this server O, for original. Next, >>>> there's >>>> the Ganesha server, which we'll call G.  Finally, there's the Client, >>>> which we'll call C.  They're likely connected something like this: >>>> >>>> O -------- G -------- C >>>> >>>> O has one path, when it comes to NFS: it's export path. Let's call >>>> this /exportO.  If you were to mount this on a client directly, you >>>> would use a command like this: >>>> >>>> mount -t nfs O:/exportO /mnt >>> >>> This is helpful. However, it's not clear how to specify specific >>> clients or client >>> ranges in the Export block. I don't want it to be the case that >>> anyone can mount >>> the Ganesha test server. Thanks. >> So in your EXPORT block, make sure the Access is something you want >> all clients to have (maybe none, could be read-only). >> >> Add at least one CLIENT sub-block, here's a sample from my >> development test config: >> >>    CLIENT >>    { >>        Access_Type=RW; >>        Squash=None; >> Clients=simple1*,127.0.0.1,local*,192.168.0.119,192.168.0.111; >>        SecType = sys; >>        Anonymous_gid = -5; >>    } >> >> The clients list can list individual host names, host name wild >> cards, individual IP addresses, netgroups, and IP net masks (in CIDR >> form, for example 127.0.0.0/8). IPv6 addresses should be supported... >> >> The CLIENT blocks are considered in order (thus they form an ACL, >> you could exclude part of a sub-net by listing it with >> Access_Type=none; first, and then the sub-net with Access_Type=RW; >> second). The permissions in the EXPORT are considered next, and then >> the global EXPORT_DEFAULTS block and finally the code defaults. >> >> Any option that is not specified at one layer will pick it's value >> of from the first layer specified (finally the code defaults if not >> specified at all). >> >> Frank >> >