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. 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@nasa.gov] Sent: Thursday, January 24, 2019 2:55 PM To: support@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@nasa.gov] Sent: Thursday, January 24, 2019 2:39 PM To: support@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@lists.nfs-ganesha.org To unsubscribe send an email to support-leave@lists.nfs-ganesha.org _______________________________________________ Support mailing list -- support@lists.nfs-ganesha.org To unsubscribe send an email to support-leave@lists.nfs-ganesha.org _______________________________________________ Support mailing list -- support@lists.nfs-ganesha.org To unsubscribe send an email to support-leave@lists.nfs-ganesha.org

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/prox... 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-pro... (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.

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@nasa.gov] Sent: Thursday, January 24, 2019 2:55 PM To: support@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@nasa.gov] Sent: Thursday, January 24, 2019 2:39 PM To: support@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@lists.nfs-ganesha.org To unsubscribe send an email to support-leave@lists.nfs-ganesha.org _______________________________________________ Support mailing list -- support@lists.nfs-ganesha.org To unsubscribe send an email to support-leave@lists.nfs-ganesha.org _______________________________________________ Support mailing list -- support@lists.nfs-ganesha.org To unsubscribe send an email to support-leave@lists.nfs-ganesha.org

_______________________________________________ Support mailing list -- support@lists.nfs-ganesha.org To unsubscribe send an email to support-leave@lists.nfs-ganesha.org

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_samples/prox...

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-pro...

(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 Next, G has 2 paths: The export from O that's it's accessing (O:/exportO) and the export it's providing to clients (call this /exportG). In the Ganesha config, the Path statement refers to the export from O, and the Pseudo statement refers to the export from G. So the config snippit would look like this: EXPORT { # ... # Export on the original server O Path = /exportO; # Path we are exporting to clients Pseudo = /exportG; FSAL { Name = PROXY; Srv_Addr = O; } # ... } C, again, only has one path to worry about, the one exported from G. To mount this, you would use a command like this: mount -n nfs G:/exportG /mnt So, in effect, Ganesha is acting as both a client and as a server. It needs to configure it's client using the Path and Srv_Addr statements, and it's server with the Pseudo statement. Hope this helps. Daniel

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

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

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/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@redhat.com; Frank Filz <ffilzlnx@mindspring.com>; support@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@lists.nfs-ganesha.org To unsubscribe send an email to support-leave@lists.nfs-ganesha.org

On 02/07/19 22:14, Frank Filz wrote:

...

-----Original Message----- From: Jeff Becker [mailto:jeffrey.c.becker@nasa.gov] Sent: Thursday, February 7, 2019 12:08 PM To: dang@redhat.com; Frank Filz <ffilzlnx@mindspring.com>; support@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

Hi everyone, Ganesha FSAL_PROXY has been providing the ability to serve multiple exports since V2.7-dev.13 (the spring of 2018) and the following patch : ===================================== commit ef0cad22d8df5e940e0efafdcb56a59af43b0285 Author: Patrice LUCAS <patrice.lucas@cea.fr> Date:   Fri Apr 6 14:57:43 2018 +0200     FSAL_PROXY : multi-export     This patch allows several Proxy exports for one     ganesha server.     Move backend nfs server conf from module to export.     One RPC connection is set by export.     Change-Id: I8ccd723d93d5521864061e759d0a1cabcc7d1914     Signed-off-by: Patrice LUCAS <patrice.lucas@cea.fr> ===================================== Best regards, -- Patrice LUCAS Ingenieur-Chercheur, CEA-DAM/DSSI/SISR/LA2S tel : +33 (0)1 69 26 47 86 e-mail : patrice.lucas@cea.fr

...

-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@lists.nfs-ganesha.org To unsubscribe send an email to support-leave@lists.nfs-ganesha.org

---

Support mailing list -- support@lists.nfs-ganesha.org To unsubscribe send an email to support-leave@lists.nfs-ganesha.org