Doug, Thanks for the info. My client is NFSv3. I tested w/ a NFSv4 client and it works as I wanted/expected.
Cheers, Scott LeFevre On Mon, 2012-02-27 at 11:39 -0500, Doug Hughes wrote: > On 2/27/2012 11:32 AM, James Carlson wrote: > > Scott LeFevre wrote: > >> I have a pools setup named tank1 with multiple datasets/filesystems > >> defined. At the top, I have tank1/media followed by tank1/media/Video > >> and tank1/media/Music. I've setup tank1/media as a nfs share > >> (e.g. /export/media) and can mount it from other systems. When I try to > >> access media/Video from the nfs client, it shows an empty directory. > >> (From the oi 151a2 host, everything shows up locally.) I can mount > >> tank1/media/Video directly from the nfs client and everything shows up > >> as it should. > >> > >> Is there a way to make this work where I expose just tank1/media as an > >> nfs export and can access the underlying datasets/filesystems (e.g. > >> Video and Music)? > > This isn't really a special issue with ZFS. > > > > NFS has always done exports by file system. If you have /foo and > > /foo/bar, and /foo/bar is a mount point for some other file system, then > > exporting /foo does not give clients access to the contents of /foo/bar, > > because there's no way to cross the file system boundary. Instead, > > clients looking at /foo/bar will see there whatever is actually in the > > /foo file system -- probably just an underlying empty directory used as > > the mount point. > > > > What you can do is set "sharenfs=on" (or some list of NFS options > > instead of just "on") using the zfs command on tank/media, and all of > > the filesystems under that point will inherit this setting. That means > > that clients will see separate NFS exports for each of the underlying > > datasets -- one for Video and one for Music in this case. > > > > Automount, of course, is your friend. ;-} > > > You can do this (hierarchical implicit shared subfs) with NFSv4, but not > with NFSv3. There's a lot more setup for V4 though and it would likely > not be as robust. > > _______________________________________________ > OpenIndiana-discuss mailing list > [email protected] > http://openindiana.org/mailman/listinfo/openindiana-discuss _______________________________________________ OpenIndiana-discuss mailing list [email protected] http://openindiana.org/mailman/listinfo/openindiana-discuss
