  Help with Multinet NFS? 
 The Question is:
 
The situation:
We have three systems running VMS 5.5-2.
 
We have sucessfully mounted (using multinet nfsmount)
a unix fileserver.  The permissions are wide open on the unix side (777)
The permission are also wide open on the VMS side (SOGW = RWED)
 
From two of the systems there is no problem reading, writing, editing,
deleteing, changing file protection
 
On the third system, we can read, delete, change file permissions but cannot
write or copy files
to the nfsmounted system.
 
We are suspecting it is a problem on the misbehaving system (a soon to be
retired mVAXII)
but have not been able to find the parameter to fix it.
(We're trying to copy files, directories and subdirectories to the unix
server)
 
We've tried reseting permissions, remounting, restarting Multinet, rbooting
the vms system......
 
Have run out of ideas and would appreciate some more!
 
Thanks
 
bb
 
Here is what we are seeing:
 
On the UNIX side:
 
nike.blb[52]: cd ..
/net/cheapfs/arc1/legacy
nike.blb[53]: dir
total 14
drwxrwxrwx   2 root     other        512 May  6 14:28 devo/
 
 
On the VMS side:
 
Directory NFS2:[000000]
 
000000.DIR;1                               1   6-MAY-1999 14:28:11.25
[GPS,DEFAULT]         (RWED,RWED,RWED,RWED)
CARPSCALES.;1                           2443   6-MAY-1999 14:26:04.74
[GPS,DEFAULT]         (RWED,RWD,R,R)
CDEVTEST.TXT;1                             1   6-MAY-1999 12:44:38.54
[GPS,DEFAULT]         (RWED,RWED,RE,RE)
DEVO$7APROBS.TXT;1                        12   5-MAY-1999 15:36:58.43
[GPS,DEFAULT]         (RWED,RWED,RWED,RWED)
GOTCOOKIES.;1                              2   6-MAY-1999 14:24:22.11
[GPS,DEFAULT]         (RWED,RWD,R,R)
TESTDOC.TXT;1                              1   5-MAY-1999 12:24:08.93
[GPS,DEFAULT]         (RWED,RWED,RWED,RWED)
 
Total of 6 files, 2460 blocks.
000000&gt; create wizard.doc
%CREATE-E-OPENOUT, error opening NFS2:[000000]WIZARD.DOC; as output
-RMS-E-PRV, insufficient privilege or file protection violation
000000&gt; sho dev nfs2 /full
 
Disk NFS2:, device type (type not yet identified), is online, mounted, file-
 
    oriented device, shareable, served to cluster via MSCP Server.
 
    Error count                    0    Operations completed
170
    Owner process                 ""    Owner UIC
[SYSTEM2]
    Owner process ID        00000000    Dev Prot
S:RWED,O:RWED,G:RWED,W:RWED
    Reference count                1    Default buffer size
512
    Total blocks            44542874    Sectors per track
 
    Total cylinders                0    Tracks per cylinder
 
 
    Volume label      "arc1/legacy/"    Relative volume number
 
    Cluster size                   1    Transaction count
 
    Free blocks              1882782    Maximum files allowed
 
    Extend quantity                0    Mount count
 
    Mount status              System    ACP process name
""
    Extent cache size              0    Maximum blocks in extent cache
 
    File ID cache size             0    Blocks currently in extent cache
 
    Quota cache size               0    Maximum buffers in FCP cache
 
 
  Volume status:  do not unload on dismount, file high-water marking,
write-back
      caching enabled.
 
000000&gt;
 
 
 The Answer is:
 
  Please contact the Multinet support folks for assistance with the
  Multinet NFS server package.
 
  OpenVMS security auditing may be able to determine just what is failing,
  if the access is being blocked by OpenVMS.  (Access can also be blocked
  by the NFS server, as part of the mapping of security models between
  UNIX and OpenVMS necessarily implemented within the NFS server, or as
  a result of a bug.)
 
  The OpenVMS Wizard would initially assume this could be part of the user
  proxy mapping or the remote node identification (the name for the UNIX
  system as accessable from the OpenVMS system) within the Multinet package,
  but the OpenVMS Wizard is quite unfamiliar with the Multinet product.
 
