Bug 1226387

Summary: mount denied since fedora 22 was installed
Product: [Fedora] Fedora Reporter: Philippe Dax <dax>
Component: nfs-utilsAssignee: Steve Dickson <steved>
Status: CLOSED CURRENTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 22CC: bcodding, bfields, dax, iand, jlayton, steved
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-06-10 11:54:28 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Attachments:
Description Flags
file tmp.pcap none

Description Philippe Dax 2015-05-29 15:40:27 UTC
Description of problem:
I am using a fedora 22 since it was released few days ago
All mounts work exept only one on a solaris10 server called here infres1

Version-Release number of selected component (if applicable):
Linux lame4.enst.fr 4.0.4-301.fc22.x86_64 #1 SMP Thu May 21 13:10:33 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

How reproducible:
always

Steps to Reproduce:
1. mount -t nfs infres1:/home/www /mnt


Actual results:
mount.nfs: access denied by server while mounting infres1:/home/www

Expected results:


Additional info:
This mount operation works with previous distribution fedora 21/kernel 3.19.7

Have you any ideas about this strange problem ?

Thanks in advance

Philippe Dax

Comment 1 J. Bruce Fields 2015-06-01 14:55:29 UTC
Any chance we could get a network trace showing the failed mount?

So, run something like:

  tcpdump -s0 -iem0 -wtmp.pcap

(replace em0 by the appropriate interface)

then do the mount, then kill the tcpdump and attach tmp.pcap, and/or take a look at it yourself with "wireshark tmp.pcap"--you're looking for nfs traffic and especially any nfs operations that return errors.

Comment 2 Philippe Dax 2015-06-01 16:35:35 UTC
Created attachment 1033420 [details]
file tmp.pcap

See the attached file tmp.pcap

Comment 3 J. Bruce Fields 2015-06-01 17:16:18 UTC
Taking a look in wireshark....  In frame 8 there's an EXCHANGE_ID call.  The reply in frame 10 is GARBAGE_ARGS ("procedure can't decode params").

The EXCHANGE_ID call is perfectly correct as far as I can tell.  The only thing possibly unusual about it is that it's an NFSv4.2 call (see the minorversion 2 field).  That looks like a server bug.

Does a mount with -overs=4.0 succeed?  (What about -overs=4.1?)

If I'm right, then that's a server bug: it should be returning NFS4ERR_MINOR_VERS_MISMATCH, at which point the client would automatically retry with a supported version and the mount would succeed as before.

Comment 4 J. Bruce Fields 2015-06-01 17:20:34 UTC
Yes, in fact, confirmed that this is a known Solaris bug.  If you have a support contract with them (or know somebody that does), could you please report it to them?

We may also need to patch the client to do some sort of workaround--I haven't looked into how hard that would be--but the server here really needs to be fixed.

For now you should be able to work around the problem by specifying the NFS version.

Comment 5 Philippe Dax 2015-06-02 09:03:50 UTC
(In reply to J. Bruce Fields from comment #3)

> Does a mount with -overs=4.0 succeed?  (What about -overs=4.1?)

Yes it works with -overs=4.0, but doesn't work with -overs=4.1, thanks a lot.

How to automatize without impact the others mounts which work fine on the others machines ?
Should I explicitly modify the value Nfsvers=4 to Nfsvers=4.1 in /etc/nfsmount.conf ?

A subsidiary question : why the mount works under fc21 and doesn't work under fc22 ? Is it depending on kernel 3.19.7 vs 4.0.4 ?

Comment 6 Philippe Dax 2015-06-02 10:12:36 UTC
(In reply to Philippe Dax from comment #5)

> Should I explicitly modify the value Nfsvers=4 to Nfsvers=4.0 ?

It woorks with 4.0

Comment 7 J. Bruce Fields 2015-06-02 14:14:41 UTC
(In reply to Philippe Dax from comment #5)
> A subsidiary question : why the mount works under fc21 and doesn't work
> under fc22 ?

The nfs client changed so that it first asks for NFSv4.2 instead of for NFSv4.0.  That shouldn't have caused any change, because the client should have fallen back on a lower version when 4.2 failed--but the Solaris server bug prevented that version negotiation from working correctly.

> Is it depending on kernel 3.19.7 vs 4.0.4 ?

I'm actually not sure exactly where the default is, but it's probably somewhere in nfs-utils, not in the kernel.

Comment 8 Philippe Dax 2015-06-02 14:36:33 UTC
(In reply to Philippe Dax from comment #6)
> (In reply to Philippe Dax from comment #5)
> 
> > Should I explicitly modify the value Nfsvers=4 to Nfsvers=4.0 ?
> 
> It woorks with 4.0

Only for this mount !
Not for the others, Nfsvers=4.0 impacts, then I prefer to leave intact the nfsmount.conf as he was by default.

Comment 9 J. Bruce Fields 2015-06-02 15:06:27 UTC
Note, I'm not sure exactly what you're trying to do, but you may want to take a look at the nfsmount.conf man page.  For example, it explains how to set default mount options on a per-server basis.

Comment 10 Philippe Dax 2015-06-02 16:29:03 UTC
(In reply to J. Bruce Fields from comment #9)

Yes you are true, I make a mistake by changing Nfsvers to 4.0 in the global section of nfsmount.conf.
Now it's in the special [ MountPoint "/infres/www" ] section.
it seems work!
Thanks

Comment 11 J. Bruce Fields 2015-10-06 14:53:54 UTC
*** Bug 1269042 has been marked as a duplicate of this bug. ***