Hide Forgot
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 #1) With the last comment, this is not a bug, but it will be helpful, if the mount returns the wrong argument.
(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
Perhaps we need a "requires upstream fix" reason for closure, since "not a bug" is manifestly incorrect?
(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 ;-)