wamapi@cs.mcgill.ca (Wanda PIERCE) (02/16/91)
I am posting to see if anyone out there has either experienced
the trouble we are having, or has a set-up similar to ours and
is *NOT* experiencing the trouble.
I've been in touch with Andrew Simms at NeXT Tech Support who
has been very helpful but has so far not been able to track
down the source of the problem or find a solution.
Another member of our team suggested the trouble may have its
roots in `nfs'.
Thanks in advance for any help you might be able to offer
(Even mickeys at this point would be welcome.)
The Configuration:
==================
* 44 NeXTstations, each with
105Mb internal disk
internal floppy drive
* one master configuration server
* one clone configuration server
* all 43 clients nfs mount both their
root
private
file systems from a Solbourne computer (the configura-
tion server boots from its 105mb internal hard disk)
The Problem:
============
* BuildDOS initializes a disk, and then claims it is
unreadable. This happens ON THE CLIENTS ONLY; on the
configuration server (the only NeXT booting from its
internal hard disk) it works fine.
Plot Thickener
==============
* I can mount disks on the configuration server that
have been formatted (and considered unreadable) on
the client. I can `cd', `cp', `ls', etc, on /DOS
without a problem.
* I cannot mount disks on a client that have been
formatted successfully on the configuration server.
Diary and Notes:
================
* this is irrespective of the floppy brand, density.
* there is no problem initializing and mounting a UNIX
file system on the same floppies
* all devices are there, with permissions, owner,
group, device major and minor numbers matching
NeXT's specs. I have also tried remaking the
devices to see if it might make a difference (it
didn't).
* the two entries from /etc/exports on the Solbourne
server (honcho is the configuration server, muttley
is a client):
/NeXT/root -root=honcho
/NeXT/private/muttley -root=honcho:muttley,
access=honcho.CS.McGill.CA:
muttley.CS.McGill.CA,
rw=honcho,muttley
There is a problem with listing more than 10 machine
names as arguments to an option in /etc/exports - at
least on the Solbourne servers. Since we have all
of the NeXTs mounting the / partition, the solution
was to not list the client names explicitly for the
root partition, but to rely on the defaults (export
rw to all, no clients have root access).
Specifying the client on the line exporting the root
partition makes no difference. I.e.,
/NeXT/root -root=honcho:muttley
* permissions on the client root directory (/) were
set to
drwxrwxrwt
also with no change in the behaviour
=================================== Wanda Pierce
(wamapi@cs.mcgill.ca)
School of Computer Science
McGill University
Montreal, Quebec
CANADA ===================