From: Tom Haynes <tdh-8AdZ+HgO7noAvxtiuMwx3w@public.gmane.org>
To: Steve Dickson <SteveD@redhat.com>
Cc: Linux NFS Mailing list <linux-nfs@vger.kernel.org>
Subject: Re: [PATCH 0/2] Support for Numeric Representations of UIDs and GIDs.
Date: Tue, 17 Aug 2010 15:30:35 -0500 [thread overview]
Message-ID: <4C6AF16B.2010807@excfb.com> (raw)
In-Reply-To: <4C6AEB43.5080508-AfCzQyP5zfLQT0dZR+AlfA@public.gmane.org>
Steve Dickson wrote:
> On 08/17/2010 03:51 PM, Tom Haynes wrote:
>
>> Steve Dickson wrote:
>>
>>> In recent NFS v2/v3 to v4 transitions, one of the sticking points have been that fact v4 uses strings in the format
>>> of "user@domain" instead of 32bit integers for uids and gids.
>>>
>>> When the string can not be mapped, its mapped to the 'nobody'
>>> user which is not optimal for things like backup servers and
>>> such where the ids will not be know by both sides.
>>>
>>> So this patch series enables the server to send out numeric string of uids and gids that do not have the '@domain' part.
>>> The series also adds functionality to the client that parse these
>>> type of strings and will use the numeric representation
>>> of the ids iff the id exists on the client, which is sightly different that Solaris. Solaris dose not have that
>>> "id must exist" restriction.
>>>
>>>
>> No, Solaris does have that restriction.
>>
> I thought so too.... but when I had an Open Solaris client
> access an directory, on a Linux server, that was owned by a
> user that was non-existent on either the server or client,
> I got the numeric representation as the owner....
> Basically:
>
> osol# mount Linux-server:/home /mnt/home
> osol# ls -ld /mnt/home/noid
> drwxr-xr-x+ 2 111 111 4096 Aug 17 11:37 /mnt/home/noid/
> osol# grep 111 /etc/passwd
> osol#
>
> steved.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
That is what I get for reading code instead of running it. :->
Actually, it might be that the server acts that way and not the client.
next prev parent reply other threads:[~2010-08-17 20:31 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-08-17 19:38 [PATCH 0/2] Support for Numeric Representations of UIDs and GIDs Steve Dickson
2010-08-17 19:38 ` [PATCH 1/2] Teach clients to map numeric strings into valid uids and gids Steve Dickson
2010-08-17 20:27 ` Trond Myklebust
2010-08-17 21:35 ` Steve Dickson
2010-08-17 21:47 ` Trond Myklebust
2010-08-17 22:07 ` Steve Dickson
2010-08-17 22:13 ` Trond Myklebust
2010-08-17 22:25 ` Steve Dickson
2010-08-17 19:38 ` [PATCH 2/2] Add server support to use of numeric strings for uid " Steve Dickson
2010-08-17 20:28 ` Trond Myklebust
2010-08-17 19:51 ` [PATCH 0/2] Support for Numeric Representations of UIDs and GIDs Tom Haynes
2010-08-17 20:04 ` Steve Dickson
[not found] ` <4C6AEB43.5080508-AfCzQyP5zfLQT0dZR+AlfA@public.gmane.org>
2010-08-17 20:30 ` Tom Haynes [this message]
2010-08-18 18:20 ` J. Bruce Fields
2010-08-18 19:09 ` Steve Dickson
2010-08-18 19:17 ` J. Bruce Fields
2010-08-18 19:23 ` Trond Myklebust
[not found] ` <1282159391.8540.90.camel-rJ7iovZKK19ZJLDQqaL3InhyD016LWXt@public.gmane.org>
2010-08-18 19:33 ` Steve Dickson
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=4C6AF16B.2010807@excfb.com \
--to=tdh-8adz+hgo7noavxtiumwx3w@public.gmane.org \
--cc=SteveD@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 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.