Hello all
we recently moved to nfsv4 from v3.
I'm currently using idmapd and not kerberos.
I noticed that now, with idmapd (and with idmapd is the only way I know
for configuring nfsv4 for now), users that are not known at server side
are squashed to nobody / nogroup (65534 / 65534).
And a chown by root from the client fails if the user is not known at
server side.
That's a problem... now we need ldap everywhere...
We were often using NFS for exporting some diskspace to machines on an
as-needed basis,
so this new behaviour complicates the things greatly for us :-/
It's almost easier to setup iSCSI targets now :-((
Is there a way to have nfsv4 with the behaviour of users of nfsv3, that
is, using numeric IDs instead of the names, like: "nfsserver, don't care
if you don't know the user, just give me the numeric ID for the file..."
Thank you
On Mon, 2010-11-29 at 19:12 +0100, Spelic wrote:
> Hello all
> we recently moved to nfsv4 from v3.
>
> I'm currently using idmapd and not kerberos.
>
> I noticed that now, with idmapd (and with idmapd is the only way I know
> for configuring nfsv4 for now), users that are not known at server side
> are squashed to nobody / nogroup (65534 / 65534).
> And a chown by root from the client fails if the user is not known at
> server side.
>
> That's a problem... now we need ldap everywhere...
>
> We were often using NFS for exporting some diskspace to machines on an
> as-needed basis,
> so this new behaviour complicates the things greatly for us :-/
> It's almost easier to setup iSCSI targets now :-((
>
> Is there a way to have nfsv4 with the behaviour of users of nfsv3, that
> is, using numeric IDs instead of the names, like: "nfsserver, don't care
> if you don't know the user, just give me the numeric ID for the file..."
No. That is not allowed by the spec.
Trond
--
Trond Myklebust
Linux NFS client maintainer
NetApp
[email protected]
http://www.netapp.com