linux-nfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Felix Rubio <felix@kngnt.org>
To: Benjamin Coddington <bcodding@redhat.com>
Cc: linux-nfs@vger.kernel.org
Subject: Re: kerberized NFSv4 client reporting operation not permitted when mounting with sec=sys
Date: Thu, 23 Jan 2020 10:03:36 +0100	[thread overview]
Message-ID: <6d998611c9205d6a0a8bf3806c297011@kngnt.org> (raw)
In-Reply-To: <724CB91C-76AC-425B-BAE3-04887ED5DE73@redhat.com>

Hi Ben,

     Thank your for trying to help. Indeed, I can get as much information 
as you might need (I am the administrator of those machines). After 
enabling rpcdebug -m nfs -s mount on the client this is what I get:

     [  461.238568] NFS: nfs mount 
opts='hard,sec=sys,vers=4.1,addr=10.0.2.9,clientaddr=10.1.0.12'
     [  461.243621] NFS:   parsing nfs mount option 'hard'
     [  461.246573] NFS:   parsing nfs mount option 'sec=sys'
     [  461.249809] NFS: parsing sec=sys option
     [  461.252364] NFS:   parsing nfs mount option 'vers=4.1'
     [  461.255472] NFS:   parsing nfs mount option 'addr=10.0.2.9'
     [  461.258864] NFS:   parsing nfs mount option 
'clientaddr=10.1.0.12'
     [  461.262610] NFS: MNTPATH: '/home'
     [  461.264757] --> nfs4_try_mount()
     [  461.273063] <-- nfs4_try_mount() = -1 [error]

when running tcpdump on the nfs server (tcpdump -i eth0 host 10.1.0.12 
and port nfs -n -s 0 -vvv), and mounting on the client, this is what I 
get:

     tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture 
size 262144 bytes
     09:55:01.603947 IP (tos 0x0, ttl 64, id 15242, offset 0, flags [DF], 
proto TCP (6), length 188)
         10.1.0.12.epp > 10.0.2.9.nfs: Flags [P.], cksum 0x1fdf 
(correct), seq 1347340908:1347341056, ack 1722815553, win 1919, length 
148: NFS request xid 3760933574 144 getattr fh 0,1/53
     09:55:01.604325 IP (tos 0x0, ttl 64, id 38336, offset 0, flags [DF], 
proto TCP (6), length 132)
         10.0.2.9.nfs > 10.1.0.12.epp: Flags [P.], cksum 0x168c 
(incorrect -> 0x08f4), seq 1:93, ack 148, win 1432, length 92: NFS reply 
xid 3760933574 reply ok 88 getattr ERROR: unk 10016
     09:55:01.604717 IP (tos 0x0, ttl 64, id 15243, offset 0, flags [DF], 
proto TCP (6), length 40)
         10.1.0.12.epp > 10.0.2.9.nfs: Flags [.], cksum 0xf0e6 (correct), 
seq 148, ack 93, win 1919, length 0
     09:55:01.612334 IP (tos 0x0, ttl 64, id 15244, offset 0, flags [DF], 
proto TCP (6), length 252)
         10.1.0.12.epp > 10.0.2.9.nfs: Flags [P.], cksum 0xe9ed 
(correct), seq 148:360, ack 93, win 1919, length 212: NFS request xid 
3777710790 208 getattr fh 0,1/53
     09:55:01.612495 IP (tos 0x0, ttl 64, id 38337, offset 0, flags [DF], 
proto TCP (6), length 240)
         10.0.2.9.nfs > 10.1.0.12.epp: Flags [P.], cksum 0x16f8 
(incorrect -> 0x417f), seq 93:293, ack 360, win 1432, length 200: NFS 
reply xid 3777710790 reply ok 196 getattr NON 4 ids 0/47982174 sz 
-1769090185
     09:55:01.652270 IP (tos 0x0, ttl 64, id 15245, offset 0, flags [DF], 
proto TCP (6), length 40)
         10.1.0.12.epp > 10.0.2.9.nfs: Flags [.], cksum 0xef34 (correct), 
seq 360, ack 293, win 1941, length 0

I have noticed there is this error 10016, that in nfs4.h translates to 
NFS4ERR_WRONGSEC, suggesting that the server does not allow 'sys', but I 
have checked again my /etc/exports file and contains

     /home 10.0.0.0/8(rw,no_subtree_check,sec=sys:krb5:krb5i:krb5p)

and also is reported by the operating system:

     # cat /proc/fs/nfsd/exports
     /export/home    
10.0.0.0/8(rw,root_squash,sync,wdelay,no_subtree_check,uuid=0743ce63:00c1185a:00000000:00000000,sec=1:390003:390004:390005)

Any ideas?

Thank you!
Felix


---
Felix Rubio
"Don't believe what you're told. Double check."

On 2020-01-22 19:30, Benjamin Coddington wrote:
> On 22 Jan 2020, at 4:22, Felix Rubio wrote:
> 
>> Hi everybody,
>> 
>> I have a kerberized NFSv4 server that is exporting a mountpoint:
>> 
>>     /home 10.0.0.0/8(rw,no_subtree_check,sec=krb5:krb5i:krb5p)
>> 
>> if I mount that export with this command on the client, it works as 
>> expected:
>> 
>>     /sbin/mount.nfs4 NFS.domain:/home /network/home -o 
>> _netdev,noatime,hard,sec=krb5
>> 
>> However, if I modify the export to be
>> 
>>     /home 10.0.0.0/8(rw,no_subtree_check,sec=sys:krb5:krb5i:krb5p)
>> 
>> and I mount that export with sec=sys, as
>> 
>>     /sbin/mount.nfs4 NFS.domain:/home /network/home -o 
>> _netdev,noatime,hard,sec=sys
>> 
>> I get the following error:
>> 
>>     mount.nfs4: timeout set for Fri Jan 17 14:11:32 2020
>>     mount.nfs4: trying text-based options 
>> 'hard,sec=sys,vers=4.1,addr=10.2.2.9,clientaddr=10.2.0.12'
>>     mount.nfs4: mount(2): Operation not permitted
>>     mount.nfs4: Operation not permitted
>> 
>> What might be the reason for this behavior?
> 
> Hi Felix,
> 
> I don't know.  Can you get more information?  Try again after `rpcdebug 
> -m
> nfs -s mount`.  That will turn up debugging for messages labeled for 
> mount,
> and the output will be in the kernel log.  There are other facilities 
> there,
> see rpcdebug(8).
> 
> Another good option is getting a network capture of the mount attempt 
> and
> trying to figure out if the server is returning an error, or the client 
> is
> generating the error.
> 
> There are also a lot of "nfs", "nfs4", and "rpc" tracepoints you can 
> enable
> to get more information.
> 
> Ben

  reply	other threads:[~2020-01-23  9:03 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-22  9:22 kerberized NFSv4 client reporting operation not permitted when mounting with sec=sys Felix Rubio
2020-01-22 18:30 ` Benjamin Coddington
2020-01-23  9:03   ` Felix Rubio [this message]
2020-01-24 14:45     ` Benjamin Coddington
2020-01-24 16:49       ` Felix Rubio
2020-02-04 19:14         ` Benjamin Coddington
2020-02-05 11:09           ` Felix Rubio
     [not found]       ` <b0bcd3e608d6fbc05c0751380f6a0e7b@kngnt.org>
     [not found]         ` <7B337925-F225-4DD7-A8CF-ECBBE1AC7082@redhat.com>
2020-07-02 13:41           ` Felix Rubio
2020-07-02 16:52             ` Dai Ngo
2020-07-02 17:52               ` Felix Rubio
2020-07-06 17:18                 ` J. Bruce Fields
2020-07-06 19:57                   ` Patrick Goetz
2020-07-06 20:27                     ` J. Bruce Fields
2020-07-07 15:10                       ` Patrick Goetz
2020-07-07 15:51                         ` J. Bruce Fields

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=6d998611c9205d6a0a8bf3806c297011@kngnt.org \
    --to=felix@kngnt.org \
    --cc=bcodding@redhat.com \
    --cc=linux-nfs@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).