SUMMARY: "Public" NFS Share not Mounted @ Boot, But Mounts OK "Manually"

From: Tim Chipman <chipman_at_ecopiabio.com>
Date: Tue Dec 10 2002 - 15:13:22 EST
Sorry for the delay in summarizing this. Many! Thanks to (in no specific
order):

topher
Robert Harris
John Riddoch
Omar Siddique
Ed Rolison
Don Schultz
Jem Richards


Basic Concensus:
================

-> why aren't I using automounter ? This should fix the issue.

-> consider adding a high-numbered rc3 script (or similar) to manually
kludge the mount late in boot cycle, as there appears to be a dependency
right now that isn't happy.

Unfortunately, despite the fact that others have apparently had this
problem, there were no explicit comments indicating that the solution
had ever been debugged (ie, rather than using work-arounds, "X then Y is
the cause, resolved THUS".)  Not that I'm unhappy to have good
workarounds - it just is interesting there wasn't an exact known cause.

Anyhoo. I'm delighted to have a solution - so - thanks again, all!


-Tim Chipman



ORIGINAL QUESTION:
==================
> Hi All,
> 
> A weird problem here with "Public NFS" share mounts which is very
> consistent, rather frustrating, and AFAIK not "good", thus I'm curious
> if anyone has ever seen this / knows of any fixes.
> 
> I've got a small central NFS server box that shares various directory
> trees out via NFS to a number of client systems on the same subnet.
> 
> For internal security reasons, we're starting to run firewalls on all
> machines internally, so we have a solid network of "trusted hosts".  To
> facilitate this, client NFS mounts are using the "public" option, which
> encourages NFS to (a) use TCP, (b) not use RPC but instead use only a
> single, fixed port for traffic (hence it is easy to make firewall rules
> that permit this traffic).
> 
> The NFS mounts appear to work fine ; cooperate with the single-port
> firewall rule, and that is "just dandy".
> 
> The WEIRD thing that drives me "crazy": When the NFS client boxes are
> rebooted (ie, for scheduled maintenance) -- they fail to mount the NFS
> shares that are specified in the /etc/vfstab at boot time [see below for
> client, server NFS config lines].  In the past (prior to adding the
> "public" flag as a mount option) this wasn't a problem.
> 
> The "odd" thing about all this: after the machine is booted, as root, I
> can simply issue the command,
> 
> mount /import/nfssrvr/share_name
> 
> .. and the share is mounts perfectly, no questions asked.  Thus, I'm
> quite confident there is no problem with my entry in the vfstab, and it
> definitely does work smoothly - when called manually by root, after
> bootup.  However, this is an extra step I'd rather not have to remember
> to do on all these NFS clients, since forgetting to do so means the
> shares are unavailable until ... a user can't access the nfs mount ;
> they bug me, and I do the mount manually as root.
> 
> If anyone has any ideas on this, I'll certainly be VERY happy to hear
> about it.
> 
> Thanks very much!
_______________________________________________
sunmanagers mailing list
sunmanagers@sunmanagers.org
http://www.sunmanagers.org/mailman/listinfo/sunmanagers
Received on Tue Dec 10 15:16:30 2002

This archive was generated by hypermail 2.1.8 : Thu Mar 03 2016 - 06:43:00 EST