License for OpenVMS NFS client

[Larry Bleau]

I asked the sysadmin of the remote system to check things out for me. He restarted the remote NFS server just in case. he was able to mount the file system I'm trying to access from his desktop system. So that confirms the file system is exported properly and the server works.

I then retried the mount command on the client (VMS) end, and it failed in the same manner:

%TCPIP$DNFSMOUNT-E-MOUNTFAIL, error mounting _DNFS1:[000000]
-SYSTEM-F-NOSUCHOBJ, network object is unknown at remote node

[Larry Bleau]

One more datum: I have access to another OpenVMS system at the site, and it is licensed with NET-APP-SUP-200. (Note: It also runs an earlier version of VMS and TCPIP.)

I entered the exact same TCPIP MOUNT command, and it failed in exactly the same way!

This may not be a license problem after all. Can someone think of a non-license reason for this error?

[Jon Pinkley]

Or as Jess mentioned, perhaps a firewall is blocking the NFS traffic. Perhaps the nfs server has to explicitly allow your system access.

Are their any other boxes on your network segment that can nfs mount from the system?

Are you sure that the network connection isn't dropping packets that are large. Can you ping with a large packet?

$ ping -s 10000 shrgproc3.engin.umich.edu

A laptop with an nfs client could be a useful debugging tool, since you could determine where it works and possibly where it doesn't.

Good luck,

Jon

[Larry Bleau]

I asked about a firewall; no response to that email yet.

The desktop system that was able to nfs mount the file system isn't on the same network segment, but it is in the same building.

The system from which I'm working is remote to both, so I can't troubleshoot anything using my home system.

I am able to ping the server system from the client system. I used /packet_size=10000 as was suggested, and that worked without any problems.

[Larry Bleau]

Thanks, everyone. It turns out the problem was the server configuration. I can't say I understand what it was, exactly, but the sysadmin noticed something not quite right, changed it, and now the TCPIP MOUNT command works.

The procedure TCPIP$NFS_CLIENT_START.COM still fails (licensing problem), but that doesn't seem to make a difference. I'll just not execute it on system startup.