From: "Patrick M." <patrick-muench@posteo.de>
To: Chuck Lever III <chuck.lever@oracle.com>
Cc: Linux NFS Mailing List <linux-nfs@vger.kernel.org>
Subject: Re: nfs xprtsec conflicting with squashing
Date: Wed, 23 Oct 2024 09:11:51 +0000 [thread overview]
Message-ID: <20241023111146.3659e2e3@jen> (raw)
In-Reply-To: <20241022163621.29890b64@jen>
Nevermind this - did further testing today and it boiled down to a inconsistency between updating exports, adapting fstab and exportfs -ra and restarting nfs services.
Apparently i somehow made things consistent and inconsistent when switching squashin on/off.
Now i can use mtls in all used combinations of squashing/mapping.
Sorry for the confusion and thanks again
Patrick
On Tue, 22 Oct 2024 16:36:21 +0200
"Patrick M." <s7mon@web.de> wrote:
> Hello,
>
> will give it a try on 6.11 server side and raise a bug if it does not - will most likely not happen before tomorrow.
> Thanks for the fast reply
>
>
> On Tue, 22 Oct 2024 14:17:18 +0000
> Chuck Lever III <chuck.lever@oracle.com> wrote:
>
> > > On Oct 22, 2024, at 9:50 AM, Patrick M. <s7mon@web.de> wrote:
> > >
> > >
> > > Hi there,
> > >
> > > tried switching to nfs with kernel TLS (mTLS to be specific).
> > > Without xprtsec i was able to use the following options on exports
> > >
> > > "rw,async,all_squash,no_subtree_check,anonuid=1000,anongid=100,fsid=6,sec=sys"
> > >
> > > but both the squashing/mapping-ids seems to conflict with TLS and i wanted to understand if this is by intention or a bug.
> >
> > I don't expect breakage like this, so at least some further
> > triage is needed. Can you open a bug on bugzilla.kernel.org
> > under the Filesystem/NFSD component?
> >
> > You can also verify that this behavior recurs with a 6.11 (or
> > later) kernel on your NFS server.
> >
> >
> > > And if it is by intention of course why - because in my understanding auth and encryption of the mount itself would not contradict with the mapping functionality.
> > >
> > > I now use "rw,async,no_subtree_check,fsid=6,sec=sys,xprtsec=mtls" and it is working. Using no_root_squash also seems to conflict.
> > >
> > > Keeping ID-Mapping i get this on client side
> > >
> > > mount.nfs: Operation not permitted for server:/mnt/target on /mnt/target
> > >
> > > And nothing i could relate as cause on server side (happy to provide specific logs if needed, even with nfsd or rpc flags with rpcdump i could not see a cause).
> > > Tlshd showed also succes in both scenarios (handshake successfull) and i can use all options as well if i remove the xprtsec on server side.
> > >
> > > Client:
> > > Linux 6.11.
> > > nfs-utils-2.7.1
> > >
> > > Server:
> > > Linux 6.5.52
> > > nfs-utils-2.7.1
> > >
> > > Sorry if i missed this in documentation, if so i'd appreciate the hint where i should look in detail
> > > and thanks for this feature!
> > >
> > >
> > > --
> > > best regards
> > > Patrick M.
> > >
> >
> > --
> > Chuck Lever
> >
> >
>
>
>
--
Patrick Münch <patrick-muench@gmx.net>
prev parent reply other threads:[~2024-10-23 9:12 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-22 13:50 nfs xprtsec conflicting with squashing Patrick M.
2024-10-22 14:17 ` Chuck Lever III
2024-10-22 14:36 ` Patrick M.
2024-10-23 9:11 ` Patrick M. [this message]
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=20241023111146.3659e2e3@jen \
--to=patrick-muench@posteo.de \
--cc=chuck.lever@oracle.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.