Connect from VMS-based NFS-client to windows-based NFS-server

[Michael Kloth]

Has anyone already tried to connect from a NFS-client running on VMS V7.3-2 with TCP/IP V5.4 to a NFS-server on Windows Server 2003 R2 (SP2) ?
After several trial-and-errors I have been able to mount the NFS-share from the VMS-side (TCPIP mount dnfs2:/host=...) but when trying to access the files I get :
$ dir dnfs2:[000000]
%DIRECT-E-OPENIN, error opening DNFS2:[000000]*.*;* as input
-RMS-E-DNF, directory not found
-SYSTEM-F-TIMEOUT, device timeout
The problem might be in the configuration on the Windows Server-side. The setup and the documentation is just Unix-orientated and seems to me not fit to OpenVMS.
Any hints ?

[Carl Bennett]

I pulled this off with Multinet once, but I had to create a linux box just to steal the passwd file from it.

I was using MS Services for Unix and had to use the passwd file to map a Windows username to a Unix UID/GID that I turned around and mapped to a VMS username on the other end.

[Shardha]

hi,

Try to give full access to the directory from the windows side and they try.
Shardha

[mpoe]

Hi Michael,

did you solved this problem? We are also facing a the "device timeout" messages and I wanted to ask if you post your solution for the problem.

Thanks in advance.

[Daniel Fernandez Illan]

Hi Michael

Wath is the reponse to

$tcpip sho service mount

Check if state is disabled.

In this case intend to restart the service using

$tcpip enable service mount

[Milton Baar]

I am also having the same problem on OpenVMS 8.2 with TCP/IP 5.5 ECO 1, although I can access the same NFS mount from three different Linux varieties and Solaris. So, I am comfortable that the NFS server is working OK.

When I try $tcpip sho servi mount, I get
%TCPIP-W-NORECORD, information not found
-RMS-E-RNF, record not found

This is odd as I can issue the $tcpip mount and dismount commands without problem.

[Milton Baar]

More info on my problem....

Upgraded to TCP/IP 5.6 ECO1, still have the same problem....but now have some interesting new commands in $tcpip, such as nfsstat, which after mounting successfully and then getting a timeout when trying to do the $dir, shows....

tcpip nfsstat -s

Server rpc:
tcp: calls badcalls nullrecv badlen xdrcall creates
0 0 0 0 0 0
udp: calls badcalls nullrecv badlen xdrcall
0 0 0 0 0

Server nfs:
calls badcalls badprog badproc badvers badargs
0 0 0 0 0 0
unprivport weakauth
0 0

Server nfs V2: (0 out of 0 calls)
null getattr setattr root lookup readlink read
0 0% 0 0% 0 0% 0 0% 0 0% 0 0% 0 0%
wrcache write create remove rename link symlink
0 0% 0 0% 0 0% 0 0% 0 0% 0 0% 0 0%
mkdir rmdir readdir statfs
0 0% 0 0% 0 0% 0 0%

Server nfs V3: (0 out of 0 calls)
null getattr setattr lookup access readlink read
0 0% 0 0% 0 0% 0 0% 0 0% 0 0% 0 0%
write create mkdir symlink mknod remove rmdir
0 0% 0 0% 0 0% 0 0% 0 0% 0 0% 0 0%
rename link readdir readdir+ fsstat fsinfo pathconf
0 0% 0 0% 0 0% 0 0% 0 0% 0 0% 0 0%
commit
0 0%

In other words, it appears that no traffic is "leaving" (or at least there is nothing recorded in tcp/udp via rpc)

And yes, I can access the other running services such as telnet, ftp and the webserver....only NFS refuses to play the game and *only* on OpenVMS, the other OS happily map and use the share.

And I have tried using proxy records with host=*, uid=0, gid=0 (which is what is on the NFS export), as well as uid=-2, gid=-2 (anonymous, which is also allowed on the NFS export and how the Linux/Solaris boxen connect)