NFS mount stopped working

[Bengt Nilsson_2]

Hi!

I have two VMS systems (one old VAX, V5.5-2H4, and one Alpha, V8.2) that are NFS clients to a tru64 5.1B system. This has now suddenly stopped working, after a reboot of the old VAX/VMS system I get:
UCX> mount dnfs0: /sys /host="mc2-p007.mc2.chalmers.se" /PATH="/usr/users"
%UCX$DNFSMOUNT-E-MOUNTFAIL, error mounting _DNFS15:[000000]
-SYSTEM-F-INVLOGIN, login information invalid at remote node

I get the same response form the Alpha system.

The tru64 5.1B system also exports to to some other tru64 systems, and this is still working. No improvement of the VMS mounts after reboot of the nfs server.

I have no Idea what has happened, and I don't know where to start looking. As far as I know, I have not made any changes. I noticed this today after a reboot in connection with a standalone backup operation.

I have olnly superficial knowledge of VMS and tru64 system management, I have so far gotten along with help from my friends, no longer available.

Any advice is appreciated.

BN

[Hoff]

The UID/GID mapping with the server is probably messed up. Check the NFS server logs over on mc2-p007 as a start.

There is a related thread here:

http://forums11.itrc.hp.com/service/forums/questionanswer.do?threadId=886741

The full sequence for setting up the NFS client is described here, and the sequence would be worth re-tracing just to verify the settings are as expected within this configuration:

http://h71000.www7.hp.com/doc/83final/6526/6526pro_052.html

The cause of these errors is usually a proxy-mapping error of some sort. Why that might have suddenly occurred here is another question.

[Bengt Nilsson_2]

I looked at the proxies:

VMS 8.2
NFS$NOBODY ON -2 -2 mc2-p007.mc2.chalmers.se
SYSTEM ON 4 1 mc2-p007.mc2.chalmers.se

VMS 5.5-2H
NFS$NOBODY OND -2 -2 mc2-p007.mc2.chalmers.se
SYSTEM ON 4 1 mc2-p007.mc2.chalmers.se

and they seems to be the same as in the thread example you gave, for the working solution. But I don't understand the uid/gid of SYSTEM, which seems to be taken from the VMS side [1,4]. Should it not be mapped to root, if any?But it worked before, so I assume there is a reason. However not covered in the manual page you included.

Now, two separate VMS systems seems to have the same problem to the same NFS server, problem occurring at the same time. I think it is more likely that the problem is on the server side.
The failing clients are mc2-p001 and mc2-p002. mc2-p004 is clustered to mc2-p002 and is using the same proxy data base.
Here is the /etc/exports:
/usr/users -rw=mc2-p001:mc2-p002:mc2-p004:mc2-p006:mc2-p016

It looks right to me. What log files should I look at?

BN

[Bengt Nilsson_2]

I tried to change the SYSTEM proxy to root:

SYSTEM OND 0 1 mc2-p007.mc2.chalmers.se

and now it works, on both VMS systems.
Very strange, since this is NOT the way it was before.

Is this the correct thing to do, or have I introduced a security problem?

BN

[Hoff]

You have NFS$NOBODY and the manual has TCPIP$NOBODY.

Whether SYSTEM is mapped correctly depends on which user(s) on the Unix box are assigned 4,1

nobody is usually -2,-2.

Without a look at the /etc/passwd on the server (or whatever data store the server uses to assign this, or to proxy UID and GID values) which user is assigned 0,1 is an open question.

I would not consider NFS to be particularly secure (given it is an entirely cleartext and proxy-based protocol), but then attacks seldom target what is expected. Inferring much from the very brief description of the configuration here (and quite possibly inferring incorrectly), I'd tend expect there are "lower-hanging fruit" for any attackers to target; NFS proxies would not be my first concern. Old VAX boxes and down-revision software can have exposures. That's why I do security reviews...

[Hoff]

The "nobody" user is -2,-2
The "root" user? that's often 0,0
which Unix user is 0,1 or 4,1 is not (here) known.

[Bengt Nilsson_2]

On my unix system root has 0,1.

About NFS security, yes, I am aware. All our VMS and unix systems that needs the NFS connections are sitting on a firewalled separate physical network.