Hi Everyone.

I've run into a bit of a quandry.

We've got an older Solaris 5.9 host (datasvr4) that is acting as an NFS marshaling point for other hosts. We use auto_direct maps to folders exported from other servers that lead to one location on datasvr4 which is then exported to other hosts.

Here's the relevant snippet from auto_direct:

/acme/dev/qsut \
/bowler40 -rw bowler40:/qsut \
/bowler464q -rw bowler464q:/opt/qsut \
/bowler5064 -rw bowler5064:/opt/qsut \
/solarry7 -rw solarry7:/opt/acme/builds \
/solarry8 -rw solarry8:/opt/acme/builds/qsut \
/aches5l -rw aches5l:/qsut \
/pucks11 -rw pucks11:/qsut \
/pucks1164 -rw pucks1164:/qsut \
/lynk22 -rw lynk22:/qsut \
/tru6451 -rw tru6451:/tmp_mnt/tru64qsut \
/aches52 -rw aches52:/qsut \
/sol9q -rw sol9q:/opt/qsut \
/aches53q -rw aches53q:/qsut \
/sol10q -rw sol10q:/opt/qsut \
/dg11risc -rw dg11risc:/qsut \
/bowler4u3 -rw bowler4u3:/opt/qsut \
/risc11o -rw risc11o:/opt/qsut \
/dg11ps -rw dg11ps:/opt/qsut \
/dg11iv3 -rw dg11iv3:/opt/qsut \
/dg11iv3it -rw dg11iv3it:/qsut \
/aches61 -rw aches61:/qsut \
/pucks11o -rw pucks11o:/opt/qsut

On datasvr4 this work fine and we can see to the mapped levels:

root@datasvr4:~/source# ls /acme/dev/qsut/aches52/
SH ctq lost+found qsut translink
aches_cc.tar equantum plsql softlink
codebase geocoder qp toolkit

However on clients using the exported /acme mount point we can't see the files below the machine level (aches52):

bash-3.00# ls /acme/dev/qsut
aches43 dg11iv3 lynk22 bowler5064 suse10
aches52 dg11iv3it lynk24 risc11o tru6450
aches53q dg11ps bowler30 sol10q tru6451
aches5l dg11risc bowler40 sol9q
aches61 pucks11 bowler464q solarry26
dynix44 pucks1164 bowler4u3 solarry7
dg11itanium pucks11o bowler50.tmp solarry8
bash-3.00# ls /acme/dev/qsut/aches52
bash-3.00#


I've tried stopping and restarting the autofs and nfs.server daemons on datasvr4 but still no joy.

Anyone with any suggestions?

Thanks in Advance!

Michael E

As documented (man share_nfs), only local filesystems can be shared.

Just to put a neat bow on this one I wanted to add the conclusion.

After more digging with the developers, I learned that this nested mounting was not intended as a pass-through from NFS to NFS. Rather, it was a means to nesting the NFS shares of other servers into the directory structure that was in turn shared out via CIFS (Samba).

The devs would run old VBS scripts that would check out files from VSS and then load them onto the target build machines which was where the nested NFS shares were originated from.

This method is very similar to NFS Gateway Services that Windows 2003 Services for Unix provides but that solution has been de-supported by M$ on Windows 2008.

I ended up rebuilding the services on a Linux box to re-create the lost functionality from the original Solaris server that is scheduled for decommissioning.

- Me