OK. I found some issues in my config file which I fixed. Now when I try to start ganesha.nfsd, I get the following: 24/01/2019 15:03:50 : epoch 5c4a4456 : tpfe2 : ganesha.nfsd-72287[main] init_export_root :EXPORT :CRIT :Lookup failed on path, ExportId=12345 Path=/nex FSAL_ERROR=(No such file or directory,2) 24/01/2019 15:03:50 : epoch 5c4a4456 : tpfe2 : ganesha.nfsd-72287[main] mdcache_exp_release :FSAL :INFO :Releasing PROXY export 12345 for /pseudonex Yet it does exist bash-4.3# ls /nex datapool datapoolne modules nex projects warasin What could be the problem? Thanks. Jeff ________________________________________ From: Becker, Jeffrey C. (ARC-TN)[InuTeq, LLC] [jeffrey.c.becker(a)nasa.gov] Sent: Thursday, January 24, 2019 2:55 PM To: support(a)lists.nfs-ganesha.org Subject: [non-nasa source] [NFS-Ganesha-Support] Re: NFS4 reexporter question Sorry. Of course I meant the PROXY FSAL. ________________________________________ From: Becker, Jeffrey C. (ARC-TN)[InuTeq, LLC] [jeffrey.c.becker(a)nasa.gov] Sent: Thursday, January 24, 2019 2:39 PM To: support(a)lists.nfs-ganesha.org Subject: [non-nasa source] [NFS-Ganesha-Support] NFS4 reexporter question Hello, I've built nfs-ganesha v2.7.1, and am trying to use the PSEUDO FSAL to reexport an nfs4 mounted directory from the ganesha server to a client. I used the base ganesha.conf (uncommenting out stuff I needed), and followed the examples in /usr/share/doc/packages/ganesha/config_samples/. The mount command on the client succeeds but when I do an ls in the mountpoint dir, there's nothing there. One issue is the client is also mounting the filesystem directly from the same place the ganesha server is, but I didn't think that mattered. I can send config files if needed. Please help me get this working. Thanks. -Jeff _______________________________________________ Support mailing list -- support(a)lists.nfs-ganesha.org To unsubscribe send an email to support-leave(a)lists.nfs-ganesha.org _______________________________________________ Support mailing list -- support(a)lists.nfs-ganesha.org To unsubscribe send an email to support-leave(a)lists.nfs-ganesha.org _______________________________________________ Support mailing list -- support(a)lists.nfs-ganesha.org To unsubscribe send an email to support-leave(a)lists.nfs-ganesha.org

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. Thanks for the reply. To make sure I'm configuring this correctly, I'm following directions at: https://github.com/nfs-ganesha/nfs-ganesha/wiki/PROXY Is that correct? Thanks again. -Jeff > > Daniel > > On 1/24/19 6:10 PM, Becker, Jeffrey C. (ARC-TN)[InuTeq, LLC] wrote: >> OK. I found some issues in my config file which I fixed. Now when I >> try to start ganesha.nfsd, I get the following: >> >> 24/01/2019 15:03:50 : epoch 5c4a4456 : tpfe2 : >> ganesha.nfsd-72287[main] init_export_root :EXPORT :CRIT :Lookup >> failed on path, ExportId=12345 Path=/nex FSAL_ERROR=(No such file or >> directory,2) >> 24/01/2019 15:03:50 : epoch 5c4a4456 : tpfe2 : >> ganesha.nfsd-72287[main] mdcache_exp_release :FSAL :INFO :Releasing >> PROXY export 12345 for /pseudonex >> >> Yet it does exist >> >> bash-4.3# ls /nex >> datapool  datapoolne  modules  nex  projects  warasin >> >> What could be the problem? Thanks. >> >> Jeff >> >> ________________________________________ >> From: Becker, Jeffrey C. (ARC-TN)[InuTeq, LLC] >> [jeffrey.c.becker(a)nasa.gov] >> Sent: Thursday, January 24, 2019 2:55 PM >> To: support(a)lists.nfs-ganesha.org >> Subject: [non-nasa source] [NFS-Ganesha-Support] Re: NFS4 reexporter >> question >> >> Sorry. Of course I meant the PROXY FSAL. >> ________________________________________ >> From: Becker, Jeffrey C. (ARC-TN)[InuTeq, LLC] >> [jeffrey.c.becker(a)nasa.gov] >> Sent: Thursday, January 24, 2019 2:39 PM >> To: support(a)lists.nfs-ganesha.org >> Subject: [non-nasa source] [NFS-Ganesha-Support] NFS4 reexporter >> question >> >> Hello, >> >> I've built nfs-ganesha v2.7.1, and am trying to use the PSEUDO FSAL >> to reexport an nfs4 mounted directory from  the ganesha server to a >> client. I used the base ganesha.conf (uncommenting out stuff I >> needed), and followed the examples in >> /usr/share/doc/packages/ganesha/config_samples/. The mount command on >> the client succeeds but when I do an ls in the mountpoint dir, >> there's nothing there.  One issue is the client is also mounting the >> filesystem directly from the same place the ganesha server is, but I >> didn't think that mattered. I can send config files if needed. Please >> help me get this working. Thanks. >> >> -Jeff >> _______________________________________________ >> Support mailing list -- support(a)lists.nfs-ganesha.org >> To unsubscribe send an email to support-leave(a)lists.nfs-ganesha.org >> _______________________________________________ >> Support mailing list -- support(a)lists.nfs-ganesha.org >> To unsubscribe send an email to support-leave(a)lists.nfs-ganesha.org >> _______________________________________________ >> Support mailing list -- support(a)lists.nfs-ganesha.org >> To unsubscribe send an email to support-leave(a)lists.nfs-ganesha.org >> > _______________________________________________ > Support mailing list -- support(a)lists.nfs-ganesha.org > To unsubscribe send an email to support-leave(a)lists.nfs-ganesha.org

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_samples/p... > > > Or you can look at the man page for FSAL PROXY here: > > https://github.com/nfs-ganesha/nfs-ganesha/blob/next/src/doc/man/ganesha-... > > > (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.

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.

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 >

I guess I wasn't clear. What I'd like is to have a single export with subdirectories that are NFS mount points. This would have a single corresponding pseudo path. Is that possible? Thanks. -Jeff On 2/7/19 5:13 AM, Daniel Gryniewicz wrote: > 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 >>> >> >

-----Original Message----- From: Jeff Becker [mailto:jeffrey.c.becker@nasa.gov] Sent: Thursday, February 7, 2019 12:08 PM To: dang(a)redhat.com; Frank Filz <ffilzlnx(a)mindspring.com>; support(a)lists.nfs- ganesha.org Subject: [NFS-Ganesha-Support] Re: NFS4 reexporter question That looks promising. Just to be clear, /top/export* are all PROXY FSAL? Thanks.

-Jeff On 2/7/19 11:30 AM, Daniel Gryniewicz wrote: > No, NFSv4 doesn't work that way. However, because of the way the > pseudoFS works, you can put all the exports on subdirs of a single > directory, and then mount the root dir, like this: > > /top/export1 > > /top/export2 > > /top/export3 > > /top/export4 > > then, on the client, you mount /top, which is a directory in the > pseudoFS that's automatically created for you. You can even, if you > want, export in /export1, /export2, and so on, and then mount / > > Daniel > > On 2/7/19 1:45 PM, Jeff Becker wrote: >> I guess I wasn't clear. What I'd like is to have a single export with >> subdirectories that are NFS mount points. This would have a single >> corresponding pseudo path. Is that possible? Thanks. >> >> -Jeff >> >> On 2/7/19 5:13 AM, Daniel Gryniewicz wrote: >>> 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/confi >>>>>>>>> g_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/m >>>>>>>>> an/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 >>>>> >>>> >>> >> > _______________________________________________ Support mailing list -- support(a)lists.nfs-ganesha.org To unsubscribe send an email to support-leave(a)lists.nfs-ganesha.org

> -----Original Message----- > From: Jeff Becker [mailto:jeffrey.c.becker@nasa.gov] > Sent: Thursday, February 7, 2019 12:08 PM > To: dang(a)redhat.com; Frank Filz <ffilzlnx(a)mindspring.com>; support(a)lists.nfs- > ganesha.org > Subject: [NFS-Ganesha-Support] Re: NFS4 reexporter question > > That looks promising. Just to be clear, /top/export* are all PROXY FSAL? > Thanks. Yes, what I'm not sure is that PROXY indeed supports multiple exports. That may have been added in the recent work. Frank

> -Jeff > > On 2/7/19 11:30 AM, Daniel Gryniewicz wrote: >> No, NFSv4 doesn't work that way. However, because of the way the >> pseudoFS works, you can put all the exports on subdirs of a single >> directory, and then mount the root dir, like this: >> >> /top/export1 >> >> /top/export2 >> >> /top/export3 >> >> /top/export4 >> >> then, on the client, you mount /top, which is a directory in the >> pseudoFS that's automatically created for you. You can even, if you >> want, export in /export1, /export2, and so on, and then mount / >> >> Daniel >> >> On 2/7/19 1:45 PM, Jeff Becker wrote: >>> I guess I wasn't clear. What I'd like is to have a single export with >>> subdirectories that are NFS mount points. This would have a single >>> corresponding pseudo path. Is that possible? Thanks. >>> >>> -Jeff >>> >>> On 2/7/19 5:13 AM, Daniel Gryniewicz wrote: >>>> 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/confi >>>>>>>>>> g_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/m >>>>>>>>>> an/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 >>>>>> > _______________________________________________ > Support mailing list -- support(a)lists.nfs-ganesha.org To unsubscribe send an > email to support-leave(a)lists.nfs-ganesha.org _______________________________________________ Support mailing list -- support(a)lists.nfs-ganesha.org To unsubscribe send an email to support-leave(a)lists.nfs-ganesha.org