Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
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.
Description of problem:
Mount failing with "mount.nfs: an incorrect mount option was specified" -
does not say exactly what option is incorrect, no there is little guidance on
what to change to fix it.
Version-Release number of selected component (if applicable):
mount.nfs: (linux nfs-utils 1.3.0)
How reproducible:
100%
Steps to Reproduce:
1. Attempt to set up nfs mount in fstab, with "default" as option field
2. Trigger mount, see error
Actual results:
[root@rhel7 ~]# mount -t nfs -v dom0:/home/jgh /dom0
mount.nfs: timeout set for Fri Nov 11 12:05:00 2016
mount.nfs: trying text-based options 'vers=4,addr=192.168.100.1,clientaddr=192.168.100.249'
mount.nfs: mount(2): Invalid argument
mount.nfs: an incorrect mount option was specified
Expected results:
More clue as to what's wrong
(In reply to Jeremy Harris from comment #0)
Hi, Harris:
[root@nfs ~]# mount -t nfs -v 10.73.4.163:/ /mnt/nfs_in/ -o addr=10.73.4.141,clientaddr=10.73.4.141
mount.nfs: timeout set for Sat Nov 12 00:27:16 2016
mount.nfs: trying text-based options 'clientaddr=10.73.4.141,vers=4,addr=10.73.4.163'
[root@nfs ~]# mount -t nfs -v 10.73.4.163:/ /mnt/nfs_in/ -o addr=10.73.4.141,clientaddr=10.73.4.141,rr
^^^^^^^^^^^^ When I use a wrong option `rr`
mount.nfs: timeout set for Sat Nov 12 00:27:53 2016
mount.nfs: trying text-based options 'clientaddr=10.73.4.141,rr,vers=4,addr=10.73.4.163'
mount.nfs: mount(2): Invalid argument
^^^^^^^^^^^ It returns `Invalid argument` due to the `rr`
mount.nfs: an incorrect mount option was specified
(In reply to ChunYu Wang from comment #2)
> (In reply to ChunYu Wang from comment #1)
>
> With the last comment, this is not a bug, but it will be helpful, if the
> mount returns the wrong argument.
If a patch appears upstream to take care of this problem that would be good and we can open this back up... but for now I'm going to close this as not a bug
(In reply to Jeremy Harris from comment #5)
> Perhaps we need a "requires upstream fix" reason for closure, since "not a
> bug"
> is manifestly incorrect?
Yes, it would make sense to use that type of reason, if it existed ;-)