From: Steve Dickson <SteveD@redhat.com>
To: Trond Myklebust <Trond.Myklebust@netapp.com>
Cc: "J. Bruce Fields" <bfields@fieldses.org>,
Spelic <spelic@shiftmail.org>,
linux-nfs@vger.kernel.org
Subject: Re: NFSv4 behaviour on unknown users
Date: Tue, 30 Nov 2010 10:36:18 -0500 [thread overview]
Message-ID: <4CF519F2.8080900@RedHat.com> (raw)
In-Reply-To: <1291057747.12784.38.camel@heimdal.trondhjem.org>
On 11/29/2010 02:09 PM, Trond Myklebust wrote:
> On Mon, 2010-11-29 at 14:01 -0500, J. Bruce Fields wrote:
>> On Mon, Nov 29, 2010 at 07:38:30PM +0100, Spelic wrote:
>>> On 11/29/2010 07:22 PM, Trond Myklebust wrote:
>>>> On Mon, 2010-11-29 at 19:12 +0100, Spelic wrote:
>>>> No. That is not allowed by the spec.
>>>>
>>>> Trond
>>>
>>> Too bad!! :-((
>>> Was that spec decision really wise? :-/
>>>
>>>
>>> BTW:
>>> I've just noticed two discussions dated a few months ago in this ML
>>> regarding this.
>>> the thread named 'numeric UIDs'
>>
>> There's also a reference to the spec language there--we'd be violating a
>> "SHOULD", but I think it would be acceptable if it smooths the v3->v4
>> upgrade path for users in your situation.
>>
>> I think steved's changes still need to be ported to libnfsidmap?
>
> I don't see how steved's changes will fix this problem. If the client
> has a mapping, it will (MUST) send the mapped uid/gid and the server
> still has to make sense of that. Ditto if the server has a mapping, and
> the client does not.
I actually thought it did...
Now that the libnfsidmap maintainership has been handed over to me
and I'm about to enable the new nfsidmapper when I commit the
"libnfsidmap: Add numerical string translation" patch... Its
probably time I take a second look at those patches to see
if we can ease some of this pain...
steved.
next prev parent reply other threads:[~2010-11-30 15:36 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-29 18:12 NFSv4 behaviour on unknown users Spelic
2010-11-29 18:22 ` Trond Myklebust
2010-11-29 18:38 ` Spelic
2010-11-29 19:01 ` J. Bruce Fields
2010-11-29 19:09 ` Trond Myklebust
2010-11-30 15:36 ` Steve Dickson [this message]
2010-11-30 22:19 ` Trond Myklebust
2010-11-30 22:26 ` J. Bruce Fields
2010-11-30 22:33 ` Trond Myklebust
2010-11-30 22:36 ` J. Bruce Fields
2010-11-30 22:47 ` Trond Myklebust
2010-12-01 2:57 ` Neil Brown
2010-12-01 3:10 ` Trond Myklebust
2010-12-01 3:23 ` Neil Brown
2010-12-01 16:29 ` J. Bruce Fields
2010-12-02 23:10 ` Thomas Haynes
2010-12-02 23:18 ` Trond Myklebust
2010-12-02 23:28 ` Spencer Shepler
2010-12-08 0:15 ` 'J. Bruce Fields'
2010-12-10 19:00 ` Thomas Haynes
2010-12-10 19:17 ` J. Bruce Fields
2010-11-29 22:09 ` Daniel.Muntz
2010-11-29 22:57 ` Spencer Shepler
2010-11-29 23:16 ` Trond Myklebust
2010-11-29 23:25 ` Spencer Shepler
2010-11-29 23:26 ` Trond Myklebust
2010-11-29 23:30 ` Spencer Shepler
2010-11-29 23:40 ` Trond Myklebust
2010-11-30 0:02 ` Spencer Shepler
2010-11-30 11:44 ` Spelic
2010-11-30 13:04 ` Trond Myklebust
2010-11-30 15:48 ` Boaz Harrosh
2010-11-29 23:34 ` Daniel.Muntz
2010-11-29 23:36 ` Spencer Shepler
-- strict thread matches above, loose matches on Subject: below --
2010-11-29 17:32 Spelic
2010-11-29 19:50 ` Simon Kirby
2010-11-29 22:47 ` Spelic
2010-11-30 15:20 ` Chuck Lever
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=4CF519F2.8080900@RedHat.com \
--to=steved@redhat.com \
--cc=Trond.Myklebust@netapp.com \
--cc=bfields@fieldses.org \
--cc=linux-nfs@vger.kernel.org \
--cc=spelic@shiftmail.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.