HP OpenVMS Systemsask the wizard |
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> create wizard.doc
%CREATE-E-OPENOUT, error opening NFS2:[000000]WIZARD.DOC; as output
-RMS-E-PRV, insufficient privilege or file protection violation
000000> 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>
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.
|