what you are looking for is the so called "mirror mounts" which is a pure NFS client feature to cross server side file system boundaries and which is available for the OpenSolaris NFS client by default, see:
http://www.opensolaris.org/os/project/nfs-namespace/ http://opensolaris.org/os/project/nfs-namespace/files/mm-PRS-open.html http://www.opensolaris.org/os/project/nfs-namespace/announcements/#2007-07-27_Mirror-mount_and_referrals_demo_available this is what the Linux NFS client is doing in your case as well. On Fri, 31 Jul 2009 16:35:27 +0200, roland <devzero at web.de> wrote: > thanks for your replies. > > i`m confused a little bit now. > > what is simply want is that an nfs share behaves just as another ordinary > filesystem share. > > if i share a directory via samba, it doesn`t matter how the mount strcuture > looks like, i.e. it simply exports a directory structure. it`s irrelevant if > it`s a single tree or a tree which is built from 2314 different filesystems , > i.e. which has 2314 mountpoints inside. the user can just see (and reach) > dirs and files. > > same with ftp. > same with http. > same with rsync. > same with webdav. > same with (insert your preffered net-filesystem here) > > i`d like to just have "showmount -e" show some export: > /myExport (myesxserver) > > so, myExport simply should be to upper level to be exported, no matter what > filesystem is mounted some dirs below that. they just should be accessible > via this single share. I don`t want any additional share like > "/myExport/anothermountbelowmyExport (myesxserver)". > > this is my linux cd-rom server: > cdromix:/iso-images # cat /etc/exports > /cd-roms *(ro,root_squash,subtree_check,crossmnt) > > below cd-roms there is a large collection of loopback-mounted iso-images. > this is exported via nfs and i can mount it on the client with ONE single nfs > mount commmand and access _all_ cdroms below that. > > so the question again, where`s the problem to have that on solaris and > where`s the real culprit here. maybe nfs is just too different and too (let`s > call it) "filesystem agnostic" ? -- frankB It is always possible to agglutinate multiple separate problems into a single complex interdependent solution. In most cases this is a bad idea.
