This is nfs-mount-problems in view mode; [Up]
Date: Sun 11-Oct-1989 14:12:13 From: Unknown Subject: nfs mount problems Folks, I have received the following error more than once. Could someone with source (at NeXT, Avie?) please give me a clue as to what the problem is. The unusual thing here is, that we run almost 30 machines diskless with the same programming and this only happens on 1 machine! First the error: remote private filesystem on schuyler:/clients/montour@/private nfs_getremotevfs: remote mount error=13 nfs_mountroot:can't get root file handle panic (cpu0) root mount, cannot mount root panic And then the machine freezes up and must be rebooted. Now, schuyler is the server (a 660 MB disk machine), the client runs diskless (as do six other clients). They find their directory trees on schuyler (made by newclient script) and do all their disk mounts via nfs (hence the source of the error message). The important files are /etc/exports, /etc/bootptab (niloaded into "/", /etc/bootparams (niloaded into "/"). They are below: / -root=tompkins:upson:cayuga:seneca /clients/montour -access=montour,root=montour /clients/reading -access=reading,root=reading /clients/bradford -access=bradford,root=bradford (there are three other lines for the three other diskless clients off the server) host htype haddr iaddr bootfile montour 1 00:00:0f:00:0a:3b 128.84.207.41 mach reading 1 00:00:0f:00:08:b6 128.84.207.46 mach (more lines for the other clients) montour root=schuyler:/ \ private=schuyler:/clients/montour@/private reading root=schuyler:/ \ private=schuyler:/clients/reading@/private (more lines for other clients) More info: niutil -read / /machines/montour reports: ip_address: 128.84.207.41 en_address: 0:0:f:0:a:3b The same thing reports for all the other diskless clients off schuyler. The weird thing is, the entire facility is run diskless (30 clients off 6 servers) and we only get this problem with one machine, well, actually we get this problem a lot, but since we re-made the lab over we haven't had the problem again until now (remade means skragg all the server drives and re-install. There was a severe bug involved with bootparams and netinfo forcing the configurer to go into NetManager, open the host entry, make any small change, and re-save the entry). Well, just in case I tried this anyway...no luck. So, if anyone has source and could point me in the right direction, I'd be greatful. Moreover, how does one obtain source for MACH or the TCP-IP portions or NFS services, etc. I had heard 1.0 sources were being shipped with the distribution but I can't find them. Thanks in advance for any help. Roger Jagoda System Analyst Cornell University Snail Mail: 220 Cornell Comp. Cent. Cornell University, Ithaca, NY 14853 AT&T: (607) 255-8960 >From: paul@phoenix.Princeton.EDU (Paul Lansky)
Date: Sun 14-Oct-1989 20:44:54 From: Unknown Subject: Re: nfs mount problems >I have received the following error more than once. Could someone >with source (at NeXT, Avie?) please give me a clue as to what the >problem is. > Avie has once again come through, thanks. Actually, the error seems to coincide with standard unix errors in sys/errno.h which I didn't know (sourced from Avie again!). Error 13 is EACCES or permission denied. This meant that the server was not allowing root access to the client. Avie suspected the exports file and he was right. The error: >nfs_getremotevfs: remote mount error=13 >nfs_mountroot:can't get root file handle >panic (cpu0) root mount, cannot mount root /etc/exports: >/ -root=tompkins:upson:cayuga:seneca >/clients/montour -access= montour,root=montour >/clients/reading -access=reading,root=reading >/clients/bradford -access=bradford,root=bradford > That space after "access= " was enough to do it. Examination of /etc/xtab showed the following: / -root=seneca:cayuga:upson:tompkins: /clients/montour -access= access=odessa, root=montour ....<other client lines> So you see the problem. The server was exporting the file- system fine, but not with the proper accesses. Correcting /etc/exports, then re-exporting (exportfs -va) solved the problem. Perhaps this is reason (small mistakes in flat files causing BIG trouble over networks) to incorporate the exports file into NetInfo somehow (Peter, Avie, any ideas?). Before everyone starts lining up to flame or support please don't. We've hashed this one fairly thoroughly. Those who've used NetInfo either like it or not and I certainly agree with everyone's reasons for both. But let me say this, for NON-unix gurus (I'm a converted NetWare SysOp myself), the flat files are just a pain. NetInfo, for all its problems will be a panacea for those NOT having a year of UNIX administration behind them. All the bootpara info, and mounting info is already in netinfo, it seems like exports should also be (something like niload -v exports . </etc/exports.local...we already do this for fstab.local and fstab.network). Thanks to all who responded for helping, I hope the resolution is equally useful. >Roger Jagoda >System Analyst >Cornell University >Internet: FQOJ@CORNELLA.CIT.CORNELL.EDU >Bitnet: FQOJ@CORNELLA.BITNET >Snail Mail: 220 Cornell Comp. Cent. Cornell University, Ithaca, NY 14853 >AT&T: (607) 255-8960 >From: knapp@cs.utexas.edu (Edgar Knapp)
These are the contents of the former NiCE NeXT User Group NeXTSTEP/OpenStep software archive, currently hosted by Marcel Waldvogel and Netfuture.ch.