Unable to access NFS mounted device with /ADF=Create

[Bill Ostrander]

NFS Client = OpenVMs Alpha 7.3-2 / TCPIP V5.4
NFS Server = Windows 2000 5.0 SP4 / MS Services for Unix 3.5

With “/NoADF” the following TCPIP Mount command allows read-only access to the shared directory. However, without “/NoADF” DNFS1: mounts, but any attempt to access it results in a device timeout, even “TCPIP Show Mount” times out.

$ tcpip mount dnfs1: vlabel disk$fs/host=”whow2k”/path=”/nfs_test”

We have tried various combinations of /User, /UID, /GID, /Server, and /SuperUser switches (among others).

We do have TCPIP proxies setup for the TCPIP$NoBody and System accounts along with what seems like appropriate Unix accounts mapped to Windows accounts on the server side. On the server side we’ve tried to open access to the shared directory as fully as possible.

What do I need to do to allow ADF files to be created on the server side to allow full read-write access?

Thanks,
--Bill

[Stanley F Quayle]

The ADF files contain the VMS file attributes. When you create a file on the NFS share, you're actually creating 2 files.

If you disabled ADF creation, all files will appear as Stream-LF (I think).

[Bill Ostrander]

Agreed.

And that appears to be the behavior with /NoADF set. I can read but cannot create or modify files, even Steram_LF files, on the NFS device. If a Stream_LF file is copied to the NFS device it fails with a "device currently write locked" message.

A quote from the manual:

"This mode (/NoADF) is only appropriate for read-only file systems because the client cannot adequately handle application-created files when /NOADF is operational."

The problem is, with the default of /ADF=Create, we can't access the NFS device at all. DIRs fail. TCPIP SHOW MOUNT fails. The failure is a device timeout.

Anyone have any success with our above combination of NFS client & server? Are there known problems with this combination?

Thanks,
--Bill

[Bill Ostrander]

I will reply to my own question. Too bad I can't assign myself any points.

I strongly susspect the VMS TCPIP NFS Client and MS SFU 3.5 are not compatable.

I downloaded an evaluation copy of Hummingbird's NFS server and got it to work in fairly short order. I even used the password and group files left over from SFU.

To whom it may concern,
--Bill