RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1547506 - Incorrect NFS version string reported for NFSv4.2 mounts
Summary: Incorrect NFS version string reported for NFSv4.2 mounts
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: nfs-utils
Version: 7.4
Hardware: Unspecified
OS: Unspecified
high
unspecified
Target Milestone: rc
: ---
Assignee: Steve Dickson
QA Contact: Zhi Li
URL:
Whiteboard:
: 1573124 (view as bug list)
Depends On:
Blocks: 1551927
TreeView+ depends on / blocked
 
Reported: 2018-02-21 13:03 UTC by Marko Myllynen
Modified: 2018-05-02 02:30 UTC (History)
10 users (show)

Fixed In Version: nfs-utils-1.3.0-0.54.el7
Doc Type: If docs needed, set a value
Doc Text:
Previously, the mount.nfs utility ignored other NFS version options, such as "-o vers=4.2", when the "-t nfs4" option was specified. As a consequence, the mount.nfs utility set NFS version to 4.1, the default one for NFSv4, even if other options required a different minor version. With this update, NFS version handling has been improved, and the described problem no longer occurs.
Clone Of:
: 1551927 (view as bug list)
Environment:
Last Closed: 2018-04-10 18:22:58 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2018:0981 0 None None None 2018-04-10 18:23:07 UTC

Description Marko Myllynen 2018-02-21 13:03:36 UTC 
Description of problem:
With RHEL 7.4 NFS server/client mounting NFSv4.2 mount using something like this in /etc/fstab:

192.168.122.1:/srv /srv nfs4 nfsvers=4.2 0 0

We see:

# mount -t nfs4
192.168.122.1:/srv on /srv type nfs4 (...,vers=4.1,...)

Justin Mitchell noticed:

"
It looks like the last working version was nfs-utils-1.3.0-43 between there and -46 the version string gets modified. Supplying nfsvers=4.2 on the command line gives a reported string of:
-43  vers=4.2
-44  vers=4
-46  vers=4.1

It also looks like this does not happen upstream, it is confined to the RHEL specific patches, probably where we tried to change the default version it tries.
"

Version-Release number of selected component (if applicable):
nfs-utils-1.3.0-0.48.el7_4.1.x86_64
Comment 2 Steve Dickson 2018-02-21 14:03:21 UTC 
It appears this patch is needed

commit 1e3ca7fe199531a372bb8e1c1033d8973097be50
Author: NeilBrown <neilb>
Date:   Wed Jul 26 13:47:42 2017 -0400

    mount: move handling of "-t nfs4" into nfs_nfs_version()
Comment 6 Steve Whitehouse 2018-02-21 19:27:45 UTC 
I would note that this is something that should ahve been caught by testing, so we need to improve our QE tests in this area to include checking the nfs version is as requested I think.
Comment 7 Yongcheng Yang 2018-02-22 03:41:04 UTC 
(In reply to Steve Whitehouse from comment #6)
> I would note that this is something that should ahve been caught by testing,
> so we need to improve our QE tests in this area to include checking the nfs
> version is as requested I think.

Thanks for the heads up! We'll improve our testcase.

-------------------------------
[root@~]# tail -n 2 /etc/fstab 
127.0.0.1:/export_test /mnt/1 nfs vers=4.2 0 0
127.0.0.1:/export_test /mnt/2 nfs4 vers=4.2 0 0
[root@~]# mount -a
[root@~]# nfsstat -m
/mnt/1 from 127.0.0.1:/export_test
 Flags: rw,relatime,vers=4.2, ...

/mnt/2 from 127.0.0.1:/export_test
 Flags: rw,relatime,vers=4.1, ...

[root@~]# 
-------------------------------
It turns out the keyword "nfs4" in /etc/keytab can perform
differently. Previously we only test the former configure.
Comment 8 Yongcheng Yang 2018-02-22 03:52:24 UTC 
(In reply to Yongcheng Yang from comment #7)
[...]
> It turns out the keyword "nfs4" in /etc/keytab can perform
> differently. 

"s/keytab/fstab" sorry for the typo.
Comment 9 Marko Myllynen 2018-02-22 07:43:42 UTC 
(In reply to Yongcheng Yang from comment #7)
> It turns out the keyword "nfs4" in /etc/fstab can perform
> differently. Previously we only test the former configure.

FWIW, using nfs4 is needed when creating minimal NFSv4-only setup; see

https://access.redhat.com/solutions/3320581

Thanks.
Comment 11 Marko Myllynen 2018-02-23 08:04:06 UTC 
Thanks, I'm happy to confirm nfs-utils-1.3.0-0.54.el7 fixes the issue!
Comment 13 Zhi Li 2018-02-24 01:24:03 UTC 
Moving to VERIFIED according to comment #12.
Comment 17 Marek Suchánek 2018-03-27 13:59:59 UTC 
Steve,

For the purpose of the erratum, is the following description correct?

> Previously, the mount.nfs utility reported version 4.1 when an NFS share was 
> mounted using NFS version 4.2. With this update, the version handling has been 
> fixed, and mount.nfs now reports version 4.2 correctly.

Thanks!
Comment 18 Yongcheng Yang 2018-03-28 01:53:14 UTC 
JFYI. The previous problem is that specifying "-t nfs4" causes other
mount options ("vers=" and "nfsvers=" especially) to be ignored.  As a
result, when handling "-t nfs4 -o vers=4.2", the default NFSv4 version
will be negotiated (that would be 4.1) but not the given version 4.2.

However, let's wait SteveD for better summary.

Please find the following upstream commit description.
(In reply to Steve Dickson from comment #2)
> It appears this patch is needed
> 
> commit 1e3ca7fe199531a372bb8e1c1033d8973097be50
> Author: NeilBrown <neilb>
> Date:   Wed Jul 26 13:47:42 2017 -0400
> 
>     mount: move handling of "-t nfs4" into nfs_nfs_version()
    
    Current "-t nfs4" causes other mount options to be ignored
    and an NFSv4 version to be negotiated.
    This is even true when "-o vers=4.1" is given.
    
    To address this, we need to move the handled of "-t nfs4"
    into nfs_nfs_version, which means passing in the filesystem type.
Comment 19 Marek Suchánek 2018-03-29 13:15:32 UTC 
Yongcheng, thanks for the clarification.

I'm changing the description to:

> Previously, the mount.nfs utility ignored other NFS version options, such 
> as "-o vers=4.2", when the "-t nfs4" option was specified. As a consequence, 
> the mount.nfs utility set NFS version to 4.1, which is the default NFSv4 
> version, even if other options required a different minor version. With this 
> update, NFS version handling has been improved, and the described problem no 
> longer occurs.
Comment 21 errata-xmlrpc 2018-04-10 18:22:58 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2018:0981
Comment 22 Yongcheng Yang 2018-05-02 02:30:25 UTC 
*** Bug 1573124 has been marked as a duplicate of this bug. ***
Note You need to log in before you can comment on or make changes to this bug.