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/sunmanagersReceived 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