No one had a solution. It turns out that this is actually a problem in
tcpip 5.1 eco 1 on the VMS side. Previous versions allowed duplicate
proxies. The way I understand it is one proxy would allow root to mount
the device and access it and the other was for non root users. Now,
only root can get to the device. This has been elevated to engineering.
The way to go it was give one proxy uid=0, gid=1 and other uid=-2 and
gid=-2, the proxy pointing to nobody has been changed also. The
interesting thing is the new OpenVms ip stack is supposedly the one from
Tru64 Unix 5.1
Original question:
I mounted a couple of nfs shares a few days ago and tested them by doing
a df command and copying a file to them and then looking to see if I see
it. I turned it over to a user and he can not access the shares. This
is a new system I have setup running tcpip version 5.1 with eco1.
(OpenVms 7.2-1). My unix box, which mounts the shares from the VMS box
has serveral other shares to older systems that work fine. I set them
up also and I never had any problem like this. Either they worked for
everybody or not at all.
Here are the error messages I am getting, nodename removed for this
list. Unix is 4.0d.
NFS3 RFS3_FSSTAT failed for server tomato : RPC: Authentication error
NFS3 RFS3_FSSTAT failed for server 100.xxx.xx.x : RPC: Authentication
error
I have turned on reply for network traffic on the vms side and I do not
even see an error message or anything when the user does the df.
When I do df from root, I see the mount just fine. I mounted it the
same as I do all the others. The other VMS systems where I mount drives
to my Unix box are running UCX 4.2 eco [3,4] not the tcpip stack.
Received on Sat May 19 2001 - 16:35:14 NZST