Bug 1460255 - OpenVMS will not mount exports from nfs-utils-1:2.1.1-5.rc3.fc25.x86_64
OpenVMS will not mount exports from nfs-utils-1:2.1.1-5.rc3.fc25.x86_64
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: nfs-utils (Show other bugs)
25
x86_64 Other
unspecified Severity low
: ---
: ---
Assigned To: Steve Dickson
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2017-06-09 09:45 EDT by John E. Malmberg
Modified: 2017-06-14 02:25 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-06-10 12:20:41 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description John E. Malmberg 2017-06-09 09:45:12 EDT
Description of problem:

OpenVMS will not mount NFS served volumes from nfs-utils on system upgraded to Fedora/25.

OpenVMS and TCPIP services (former name UCX) from 7.3 to 8.4 will mount NFS served volumes from Fedora/22 to Fedora/24.  Some versions of TCPIP services require NFS V2 to be enabled.

A downgrade nfs-utils to nfs-utils-1:1.3.4-1.rc2.fc25.x86_64 restores OpenVMS being able to mount the volume.

Version-Release number of selected component (if applicable):

nfs-utils-1:2.1.1-5.rc3.fc25.x86_64

HP Itanium I64VMS V8.4
HP Itanium I64VMS TCPIP V5.7-13ECO5

DEC VAX/VMS 7.3
Compaq TCP/IP V5.3-ECO4

How reproducible:

100%


Steps to Reproduce:
1. Enable NFS V2 in /etc/sysconfig/nfs, probably not needed for VMS 8.4/TCPIP V5.7

RPCNFSDARGS="-V 2"

2. Set up an NFS export on Fedora system.
3. Try to mount the export on a VMS system.

Actual results:

(VMS 8.4)
LION>  tcpip mount dnfs: jazz jazz_root /host=jazz-san.xile.realm/path="/home"/system/transport=UDP/structure=5/acp_params=(buffer_l
imit=819200)/timeout=00:00:05
%TCPIP$DNFSMOUNT-E-MOUNTFAIL, error mounting _DNFS12:[000000]
-SYSTEM-F-NOSUCHOBJ, network object is unknown at remote node

From /var/log/messages
Jun  8 23:13:34 jazz rpc.mountd[1082]: authenticated mount request from 192.168.1.111:601 for /home (/home)
Jun  8 23:13:34 jazz rpc.mountd[1082]: authenticated unmount request from 192.168.1.111:601 for /home (/home)

(VMS 7.3)
$   tcpip mount dnfs: jazz jazz_root -
    /host=jazz-san.xile.realm/path="/home"-
    /system/acp_params=(buffer_limit=819200)/timeout=00:00:05
%TCPIP$DNFSMOUNT-E-MOUNTFAIL, error mounting _DNFS10:[000000]
-SYSTEM-F-NOSUCHOBJ, network object is unknown at remote node



Expected results:

LION>  tcpip mount dnfs: jazz jazz_root /host=jazz-san.xile.realm/path="/home"/system/transport=UDP/structure=5/acp_params=(buffer_l
imit=819200)/timeout=00:00:05
%TCPIP$DNFSMOUNT-S-MOUNTED, /home mounted on _DNFS13:[000000]



Additional info:

I verified that with nfs-utils-1:2.1.1-5.rc3.fc25.x86_64, I was able to mount the same NFS exports using nfs v2 and v3 from another Linux system.

I will be passing this bug information to HPE Office of OpenVMS Programs and VMS Software Inc.
Comment 1 Steve Dickson 2017-06-09 14:14:02 EDT
Would it be possible to get a network trace? Something similar to:

dnf install wireshark
tshark -i <iface> -w /tmp/data.pcap host <VMSclient>
bzip /tmp/data.pcap
Comment 2 John E. Malmberg 2017-06-09 21:56:33 EDT
It was pointed out to me by Paul Eggert that my failed mount attempt was using UDP, and he suggested that UDP was now disabled by default for the NFS server.

A test was made with VMS 8.4 and nfs-utils-1:2.1.1-5.rc3.fc25.x86_64 using the TCP transport and the volume was mounted.

I then modified /etc/sysconfig/nfs as below and restarted the nfs-server service.

RPCNFSDARGS="--udp -V 2"

After this change, I was able to NFS mount the volumes on all my VMS systems again.

I am assuming that the network traces are no longer needed and this bug can be resolved.
Comment 3 Steve Dickson 2017-06-10 12:20:41 EDT
(In reply to John E. Malmberg from comment #2)
> It was pointed out to me by Paul Eggert that my failed mount attempt was
> using UDP, and he suggested that UDP was now disabled by default for the NFS
> server.
> 
> A test was made with VMS 8.4 and nfs-utils-1:2.1.1-5.rc3.fc25.x86_64 using
> the TCP transport and the volume was mounted.
> 
> I then modified /etc/sysconfig/nfs as below and restarted the nfs-server
> service.
> 
> RPCNFSDARGS="--udp -V 2"
> 
> After this change, I was able to NFS mount the volumes on all my VMS systems
> again.
> 
> I am assuming that the network traces are no longer needed and this bug can
> be resolved.

That is correct... I mistakenly added in a patch that disables 
the NFS server from creating a UDP socket by default. My apologies
if that mistake has cause you pain but to be honest TCP is a much
better protocol than UDP... 

Does the VMS client support TCP connections? If so you should be using TCP over UDP.
Comment 4 John E. Malmberg 2017-06-10 15:13:34 EDT
VMS HP provided TCP/IP 5.7-13 supports TCP for NFS mounts.

Older VMS DEC/Compaq/HP provided TCP/IP only supports UDP for NFS mounts.

It turns out that while I was able to mount the NFS volumes, on VMS 8.4 + TCP/IP 5.7-13ECO5 they are effectively read-only.

VSI, the new providers of VMS have a fix for it in VSI-*VMS-TCPIP_NFS_PAT-V0507-ECO5C-4 Which is only available for their distributions.

My access to VMS is through their free hobbyist program which does not yet include the VSI distributions.

So my next step is to try Multinet 5.5 instead of HP TCP/IP 5.7.
Comment 5 John E. Malmberg 2017-06-12 08:33:50 EDT
One last update for the next VMS person that stumbles on this.

The other work around for not having VSI-*VMS-TCPIP-NFS_PAT_V0507 is to simply add "/noadf" to the VMS TCPIP mount command.

This inhibits VMS TCPIP from creating the special resource file that contains the file attributes.

This resource file is not needed for STREAM or FIXED record format files, which are the formats for text files and binary files used for code development.
Comment 6 Steve Dickson 2017-06-12 09:52:23 EDT
Boy I thought VMS was dead, but I guess not...

Thanks for the update!
Comment 7 J.Jansen 2017-06-14 02:25:25 EDT
And John is not the only one who stumbled on this problem this week...
me too.

Note You need to log in before you can comment on or make changes to this bug.