Frank Filz [ffilz...@mindspring.com] wrote: > So by having the export of child1 permitted to gclient2 only, this config > is indicating that ONLY gclient2 can have access to child1, and Ganesha is > able to (mostly) enforce this for NFS v4 (the mostly comes in that if the > client "guessed" a handle for a file or directory inside child2, but > mangled the handle to have the exportid for the fs1 or child2 exports, the > client would be able to access the files in the child1 namespace).
Let us say I have just one file system, and export "/fs" to client1 only and export "/fs/nfs2" to client2 only. Does this config not permit client1 see /fs/nfs2 subtree? Regards, Malahal. > > > > In NFS v3, junctions are not supported by the protocol, and thus Ganesha > does not block the client from seeing the child1 sub-directory of the fs1 > export. > > > > If child1 and child2 were separate filesystems, gclient1 would NOT be able > to access child1. > > > > Note you should ALSO be seeing that with NFS v4, gclient2 should not > actually be able to get to child1, because it isn't allowed access to the > fs1 export which it needs to traverse to get to child1. > > > > With NFS v4, having nested exports like this should not result in any > consistency issues since the a normal client would get all handles by > LOOKUP and thus never get a handle for anything in the child namespaces > under the fs1 export. > > > > With NFS v3 that would not be the case since the client could mount fs1 to > /mnt and child1 to /mnt1 (rather than /mnt/child1) and get handles for > /svr/fs1/child1/foo via both exports, in which case the client might > believe them to be different files (though if you don't provide a > filesystem_id in the export, they would have the same fsid and inode > number which would make the client conclude the two handles actually do > refer to the same file). Ganesha also maintains a single > cache_inode/mdcache entry for the file despite the two different handles > (the part of the handle Ganesha cares about for the inode cache is the > same, just the export_id is different). > > > > Frank > > > > From: Madhu P Punjabi [mailto:madhu.punj...@in.ibm.com] > Sent: Monday, July 11, 2016 11:29 PM > To: nfs-ganesha-devel <nfs-ganesha-devel@lists.sourceforge.net> > Subject: [Nfs-ganesha-devel] NFSv4 client unable to see sub-directory > which is exported for another client > > > > Hi, > > I am new to ganesha NFS. > > We have a customer using ganesha and having NFSv4 exports. > The customer directory structure looks like this: > fs1 > / \ > / \ > child1 child2 > > 1) /svr/fs1 with export having > CLIENT { > Clients=gclient1; > Access_Type=RW; > Squash=NoIdSquash; > Protocols=4; > } > 2) /svr/fs1/child1 with export having > CLIENT { > Clients=gclient2; > Access_Type=RW; > Squash=NoIdSquash; > Protocols=4; > } > 3) /svr/fs1/child2 with export having > CLIENT { > Clients=*; > Access_Type=RW; > Squash=NoIdSquash; > Protocols=4; > } > On client 'gclient1' customer does the following mount: > # mount -t nfs4 gserver:/svr/fs1 /home/gserver_fs1 > # ls /home/gserver_fs1 > child2 > With 'ls' the subdirectory "child1" is not seen. The customer complains > that when he creates the same exports with NFSv3, then on 'gclient1' he > can see all sub-directories, but the same is not the case when he has > exports with NFSv4. > > I see that having an export for the 'gclient1' for 'child1' helps, but is > that recommended. Will it not lead to any consistency issues as gclient1 > has access to its parent directory? I read somewhere that having exports > for the same client for a parent and child directory can lead to data > consistency problems. > > Please suggest. > > Thank you. > Madhu. > > -------------------------------------------------------------------------- > > This email has been checked for viruses by Avast antivirus > [1]Avast logo software. > [2]www.avast.com > > References > > Visible links > 1. > https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient > 2. > https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient > ------------------------------------------------------------------------------ > What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic > patterns at an interface-level. Reveals which users, apps, and protocols are > consuming the most bandwidth. Provides multi-vendor support for NetFlow, > J-Flow, sFlow and other flows. Make informed decisions using capacity planning > reports.http://sdm.link/zohodev2dev > _______________________________________________ > Nfs-ganesha-devel mailing list > Nfs-ganesha-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel ------------------------------------------------------------------------------ What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports.http://sdm.link/zohodev2dev _______________________________________________ Nfs-ganesha-devel mailing list Nfs-ganesha-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
