|Summary:||mount denied since fedora 22 was installed|
|Product:||[Fedora] Fedora||Reporter:||Philippe Dax <dax>|
|Component:||nfs-utils||Assignee:||Steve Dickson <steved>|
|Status:||CLOSED CURRENTRELEASE||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||22||CC:||bcodding, bfields, dax, iand, jlayton, steved|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2015-06-10 11:54:28 UTC||Type:||Bug|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
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