Bug 620601 - mount.nfs tries vers=4 but does not autonegotiate down with ReadyNAS NV+ NAS fileservers
mount.nfs tries vers=4 but does not autonegotiate down with ReadyNAS NV+ NAS ...
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: nfs-utils (Show other bugs)
13
All Linux
low Severity low
: ---
: ---
Assigned To: Steve Dickson
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-08-02 19:49 EDT by Wendell Baker
Modified: 2010-08-03 15:18 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-08-03 15:11:26 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Wendell Baker 2010-08-02 19:49:01 EDT
Description of problem:

For certain dedicated NAS NFS servers, mount.nfs does not autonegotiate down from vers=4 to vers=3.  It fails for the Infrant ReadyNAS NV+

Of course it works fine with
a) Fedora 13 mounting server Fedora Core 4
b) Fedora 13 mounting server Western Digital ShareSpace in NFS mode

The issue is that 'Connection Refused' is returned by the ReadyNAS.
Instead "Protocol not supported" was expected as the trigger for autonegotiation

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

Model:  	Infrant ReadyNAS NV+
Serial:  	000da2014ebe
Firmware:  	RAIDiator™ v3.01c1-p6 [1.00a034]
Memory:  	256 MB [2.5-3-3-7]


How reproducible:
very

there is a workaround: specify vers=3 in the nfs and autofs options

Steps to Reproduce:
1. sudo mount  -v -t nfs server:/ours /tmp/t 
2.
3.
  
Actual results:

[on Fedora 13]
$ sudo mount  -v -t nfs server:/ours /tmp/t 
mount.nfs: timeout set for Mon Aug  2 16:35:48 2010
mount.nfs: trying text-based options 'vers=4,addr=192.168.0.79,clientaddr=192.168.0.48'
mount.nfs: mount(2): Connection refused
mount.nfs: trying text-based options 'vers=4,addr=192.168.0.79,clientaddr=192.168.0.48'
mount.nfs: mount(2): Connection refused
mount.nfs: trying text-based options 'vers=4,addr=192.168.0.79,clientaddr=192.168.0.48'
mount.nfs: mount(2): Connection refused
mount.nfs: trying text-based options 'vers=4,addr=192.168.0.79,clientaddr=192.168.0.48'

This goes on until timeout occurs.  Which can be very long.
If you do not have -v turned on then you see "it hangs and then fails" sort of behavior which may lead one astray in debugging since Fedora 10 "used to work"

Expected results:

I would expect it to autonegotiate down to vers=3 which the ReadyNAS can deal with.  I would expect it to look something like what fedoracore4 delivers as an experience ... "it just works"


$ sudo mount  -v -t nfs fedoracore4:/srv/tftp /tmp/t 
[sudo] password for wbaker: 
mount.nfs: timeout set for Mon Aug  2 16:42:10 2010
mount.nfs: trying text-based options 'vers=4,addr=192.168.0.62,clientaddr=192.168.0.48'
mount.nfs: mount(2): Operation not permitted
mount.nfs: trying text-based options 'addr=192.168.0.62'
mount.nfs: prog 100003, trying vers=3, prot=6
mount.nfs: trying 192.168.0.62 prog 100003 vers 3 prot TCP port 2049
mount.nfs: prog 100005, trying vers=3, prot=17
mount.nfs: trying 192.168.0.62 prog 100005 vers 3 prot UDP port 938
fedoracore4:/srv/tftp on /tmp/t type nfs (rw)



Additional info:

I can't tell you want is going on on the ReadyNAS because they don't give you ssh access into it (Apparently it is Linux 2.2.? somehow)

$ rpm -q -f /sbin/mount.nfs
nfs-utils-1.2.2-2.fc13.i686

the workaround is to specify vers=3 in the mount command as follow

$ sudo mount  -v -t nfs -o vers=3 server:/ours /tmp/t 
mount.nfs: timeout set for Mon Aug  2 15:45:52 2010
mount.nfs: trying text-based options 'vers=3,addr=192.168.0.79'
mount.nfs: prog 100003, trying vers=3, prot=6
mount.nfs: portmap query retrying: RPC: Program not registered
mount.nfs: prog 100003, trying vers=3, prot=17
mount.nfs: trying 192.168.0.79 prog 100003 vers 3 prot UDP port 2049
mount.nfs: prog 100005, trying vers=3, prot=17
mount.nfs: trying 192.168.0.79 prog 100005 vers 3 prot UDP port 757
server:/ours on /tmp/t type nfs (rw,vers=3)


In Fedora 10, this scenario used to "just work" with the ReadyNAS NV+ because vers=4 nor vers=3 were specified.  Since vers=3 was assumed it all worked.

[on Fedora 10]
$ sudo mount -v -t nfs fedora10:/ours /tmp/t
mount.nfs: timeout set for Mon Aug  2 16:49:09 2010
mount.nfs: text-based options: 'addr=192.168.0.79'
mount.nfs: mount(2): Operation not supported
mount.nfs: trying 192.168.0.79 prog 100003 vers 3 prot UDP port 2049
mount.nfs: trying 192.168.0.79 prog 100005 vers 3 prot UDP port 757
mount.nfs: text-based options (retry): 'addr=192.168.0.79,nfsvers=3,proto=udp,mountproto=udp,mountport=757'
fedora10:/ours on /tmp/t type nfs (rw)


It would be great if autonegotiation worked again in Fedora 14
Comment 1 Steve Dickson 2010-08-03 15:11:26 EDT
The problem is your server is sending back a "Connection refused" error
instead of an error that would cause autonegotiation. The mount command 
in interprets "Connection refused" errors as the server is down and
will continue to retry in the likely hood the server is on its way
back up... 

If you notice in your other examples errors like "RPC: Program not registered"
and "Operation not supported" were returned not "Connection refused". Those
types of error cause the autonegotiation to occur.  If the server did 
return "Connection refused" in those examples the same retries would occur...  

So your server obviously does not support v4 and does not know how
to (correctly) error out when v4 bits are thrown at it... 

My suggestion would be added the following lines to
/etc/nfsmount.conf

[ Server "server" ]
Defaultvers=3

which means start the autonegotiation at v3 with that particular "server"

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