UID mapping

[Steve Hill]

I'm having a problem with NFSv4 UID mapping. rpc.idmapd is running on
both the server (debian) and the client (fedora). The server appears to
be doing UID -> name conversions and the client is doing name -> UID
conversions, so reading from the server shows the correct file ownerships.
However, the client doesn't seem to be doing UID -> name conversions, so
writes to the server end up owned by the client's UID rather than being
mapped back to what the server expects.

Google is turning up a few people reporting similar problems, but no
answers - can someone give me some pointers as to what I'm doing wrong?

Thanks.

--

- Steve
xmpp:steve at nexusuk.org sip:steve at nexusuk.org http://www.nexusuk.org/

Servatis a periculum, servatis a maleficum - Whisper, Evanescence

[J. Bruce Fields]

Post by Steve Hill
I'm having a problem with NFSv4 UID mapping. rpc.idmapd is running on
both the server (debian) and the client (fedora). The server appears to
be doing UID -> name conversions and the client is doing name -> UID
conversions, so reading from the server shows the correct file
ownerships. However, the client doesn't seem to be doing UID -> name
conversions, so writes to the server end up owned by the client's UID
rather than being mapped back to what the server expects.
Google is turning up a few people reporting similar problems, but no
answers - can someone give me some pointers as to what I'm doing wrong?

The idmapper isn't actually responsible for the problem you're
having--NFSv4 names are only used in the body of NFSv4 packets (hence in
getattr/readdir responses, or setattr (e.g. for chmod, setacl requests);
the identity of a user performing a given operation is always determined
by the credential in the rpc header. So the answer to your problem
depends on whether you're using krb5 or auth_sys.

--b.

[Steve Hill]

Post by J. Bruce Fields
The idmapper isn't actually responsible for the problem you're
having--NFSv4 names are only used in the body of NFSv4 packets (hence in
getattr/readdir responses, or setattr (e.g. for chmod, setacl requests);
the identity of a user performing a given operation is always determined
by the credential in the rpc header. So the answer to your problem
depends on whether you're using krb5 or auth_sys.

At the moment I'm just using auth_sys (it is a relatively secure network),
although I will probably switch to krb5 at some point in the future. Is
there a way of performing UID mapping through auth_sys? Presumably
it should Just Work if I switch to krb5, since it will be sending krb5
tokens rather than UIDs over the wire?

Thanks.

[J. Bruce Fields]

Post by Steve Hill

Post by J. Bruce Fields
The idmapper isn't actually responsible for the problem you're
having--NFSv4 names are only used in the body of NFSv4 packets (hence in
getattr/readdir responses, or setattr (e.g. for chmod, setacl requests);
the identity of a user performing a given operation is always determined
by the credential in the rpc header. So the answer to your problem
depends on whether you're using krb5 or auth_sys.

At the moment I'm just using auth_sys

In that case, you should just need to make sure the uid's agree on
client and server, and check 'exportfs -v' and make sure none of the
id-squashing options are turned on on your exports.

Post by Steve Hill
(it is a relatively secure
network), although I will probably switch to krb5 at some point in the
future. Is there a way of performing UID mapping through auth_sys?

Not really.

Post by Steve Hill
Presumably it should Just Work if I switch to krb5, since it will be
sending krb5 tokens rather than UIDs over the wire?

Right, as long as a) the names of the krb5 principals agree with names
the server knows about (so johndoe at REALM.COM can map to a server-side
user johndoe), and b) depending on the version, you may need the Domain=
in idmapd.conf to match the kerberos realm.

--b.

[William A. (Andy) Adamson]

Post by J. Bruce Fields

Post by Steve Hill

Post by J. Bruce Fields
The idmapper isn't actually responsible for the problem you're
having--NFSv4 names are only used in the body of NFSv4 packets (hence in
getattr/readdir responses, or setattr (e.g. for chmod, setacl requests);
the identity of a user performing a given operation is always determined
by the credential in the rpc header. ?So the answer to your problem
depends on whether you're using krb5 or auth_sys.

At the moment I'm just using auth_sys

In that case, you should just need to make sure the uid's agree on
client and server, and check 'exportfs -v' and make sure none of the
id-squashing options are turned on on your exports.

Post by Steve Hill
(it is a relatively secure
network), although I will probably switch to krb5 at some point in the
future. ?Is there a way of performing UID mapping through auth_sys?

Not really.

Post by Steve Hill
Presumably it should Just Work if I switch to krb5, since it will be
sending krb5 tokens rather than UIDs over the wire?

Right, as long as a) the names of the krb5 principals agree with names
the server knows about (so johndoe at REALM.COM can map to a server-side
user johndoe), and b) depending on the version, you may need the Domain=
in idmapd.conf to match the kerberos realm.

Well, it all depends on what you mean by 'Just Work.'

You always need to have UID/GID mapping on the client be the same as
on the server if you want ls -l on the client to Just Work. Run LDAP (
recommended because it is secure - use TLS), NIS (not recommended
because is insecure), or copy /etc/password files (ugg).

Turning on Kerberos means that the server somehow maps
johndoe at REALM.COM to a UID a principle GID and a list of GIDs - and
Bruce described one way that happens. So unlike AUTH_SYS where the
server uses client supplied info from the RPC credential, the server
will use a server UID and associated principle GID and GID list.

But the client will always need to map johndoe at dns_domain to a UID via
rpc.idmapd. The default method is nsswitch (see /etc/idmapd.conf)
which strips the @dns_domain and maps johndoe to client UID. So, if
johndoe client UID != johndoe server UID ls -l will show incorrect
information on the client and confuse the heck out of users!

-->Andy

Post by J. Bruce Fields
--b.
_______________________________________________
NFSv4 mailing list
NFSv4 at linux-nfs.org
http://linux-nfs.org/cgi-bin/mailman/listinfo/nfsv4

[Valentijn Sessink]

William A. (Andy) Adamson schreef:
[...]

Post by William A. (Andy) Adamson
But the client will always need to map johndoe at dns_domain to a UID via
rpc.idmapd. The default method is nsswitch (see /etc/idmapd.conf)
johndoe client UID != johndoe server UID ls -l will show incorrect
information on the client and confuse the heck out of users!

Are you sure? I remember having tried different UID's on client and
server for a test, and they seemed to be working correctly, ls -l and
all. But I might be wrong - I didn't check really thoroughly as we
normally use LDAP (or, in older networks, NIS).

V.

[J. Bruce Fields]

Post by Valentijn Sessink
[...]

Post by William A. (Andy) Adamson
But the client will always need to map johndoe at dns_domain to a UID via
rpc.idmapd. The default method is nsswitch (see /etc/idmapd.conf)
johndoe client UID != johndoe server UID ls -l will show incorrect
information on the client and confuse the heck out of users!

Are you sure?

Yep.
ls -l results in NFSv4 GETATTR(s) with owner and owner_group
attributes which are of the form name at domain.

Right, though ls -l for example could still work even if the "johndoe"
has different numeric UID's on the client and server, as long as the
name exists on both sides. (But then of course you'd break auth_sys.)

--b.

[William A. (Andy) Adamson]

Post by J. Bruce Fields

Post by Valentijn Sessink
[...]

Post by William A. (Andy) Adamson
But the client will always need to map johndoe at dns_domain to a UID via
rpc.idmapd. The default method is nsswitch (see /etc/idmapd.conf)
johndoe client UID != johndoe server UID ls -l will show incorrect
information on the client and confuse the heck out of users!

Are you sure?

Yep.
ls -l results in NFSv4 GETATTR(s) with owner and owner_group
attributes which are of the form name at domain.

Right, though ls -l for example could still work even if the "johndoe"
has different numeric UID's on the client and server, as long as the
name exists on both sides.

*and* the user 'johndoe' on the client is actually the same user as
'johndoe' on the server!
otherwise, ls -l on the client would work but be incorrect...

-->Andy

Post by J. Bruce Fields
(But then of course you'd break auth_sys.)
--b.

[J. Bruce Fields]

Post by William A. (Andy) Adamson

Post by J. Bruce Fields

Post by Valentijn Sessink
[...]

Post by William A. (Andy) Adamson
But the client will always need to map johndoe at dns_domain to a UID via
rpc.idmapd. The default method is nsswitch (see /etc/idmapd.conf)
johndoe client UID != johndoe server UID ls -l will show incorrect
information on the client and confuse the heck out of users!

Are you sure?

Yep.
ls -l results in NFSv4 GETATTR(s) with owner and owner_group
attributes which are of the form name at domain.

Right, though ls -l for example could still work even if the "johndoe"
has different numeric UID's on the client and server, as long as the
name exists on both sides.

*and* the user 'johndoe' on the client is actually the same user as
'johndoe' on the server!

Here we veer into some area of philosphy outside my expertise.

--b.

Post by William A. (Andy) Adamson
otherwise, ls -l on the client would work but be incorrect...
-->Andy

Post by J. Bruce Fields
(But then of course you'd break auth_sys.)
--b.

[William A. (Andy) Adamson]

Post by Valentijn Sessink
[...]

Post by William A. (Andy) Adamson
But the client will always need to map johndoe at dns_domain to a UID via
rpc.idmapd. The default method is nsswitch (see /etc/idmapd.conf)
johndoe client UID != johndoe server UID ls -l will show incorrect
information on the client and confuse the heck out of users!

Are you sure?

Yep.
ls -l results in NFSv4 GETATTR(s) with owner and owner_group
attributes which are of the form name at domain.

-->Andy

Post by Valentijn Sessink
I remember having tried different UID's on client and
server for a test, and they seemed to be working correctly, ls -l and
all. But I might be wrong - I didn't check really thoroughly as we
normally use LDAP (or, in older networks, NIS).
V.

[Valentijn Sessink]

Post by William A. (Andy) Adamson
You always need to have UID/GID mapping on the client be the same as
on the server if you want ls -l on the client to Just Work. Run LDAP (

As far as I can see, you don't. Here's my test:

On the server, there's users "valentyn" with uid 1000, and testuser1, 2
and 3 with uids 1001, 1002 and 1003, and a user that we will sync on
client and server, called "correctid":
root at server:/home# for a in valentyn testuser{1,2,3} correctid; do id
$a; done
uid=1000(valentyn) gid=1000(valentyn) groepen=1000(valentyn)
uid=1001(testuser1) gid=1001(testuser1) groepen=1001(testuser1)
uid=1002(testuser2) gid=1002(testuser2) groepen=1002(testuser2)
uid=1003(testuser3) gid=1003(testuser3) groepen=1003(testuser3)
uid=1004(correctid) gid=1004(correctid) groepen=1004(correctid)
root at server:/home# ls -l
totaal 20
drwxr-xr-x 2 correctid correctid 4096 2010-03-03 11:33 correctid
drwxr-xr-x 23 testuser1 testuser1 4096 2010-03-03 11:31 testuser1
drwxr-xr-x 2 testuser2 testuser2 4096 2010-03-03 11:26 testuser2
drwxr-xr-x 2 testuser3 testuser3 4096 2010-03-03 09:56 testuser3
drwx------ 24 valentyn valentyn 4096 2010-02-24 13:41 valentyn

To make sure everything is as we expect it to be:
root at server:/home# ls -ln
totaal 20
drwxr-xr-x 2 1004 1004 4096 2010-03-03 11:33 correctid
drwxr-xr-x 23 1001 1001 4096 2010-03-03 11:31 testuser1
drwxr-xr-x 2 1002 1002 4096 2010-03-03 11:26 testuser2
drwxr-xr-x 2 1003 1003 4096 2010-03-03 09:56 testuser3
drwx------ 24 1000 1000 4096 2010-02-24 13:41 valentyn


On the client, I'm using the same usernames, but different uids; I used
"valentijn" instead of "valentyn" and I added the correctid user:

root at client:~# for a in valentyn valentijn testuser{1,2,3} correctid; do
id $a; done
id: valentyn: No such user
uid=1002(valentijn) gid=1002(valentijn) groups=1002(valentijn)
uid=1000(testuser1) gid=1000(testuser1) groups=1000(testuser1)
uid=1003(testuser2) gid=1003(testuser2) groups=1003(testuser2)
uid=1001(testuser3) gid=1001(testuser3) groups=1001(testuser3)
uid=1004(correctid) gid=1004(correctid) groups=1004(correctid)
root at client:~# mount|grep home
server:/home on /home type nfs4
(rw,sec=krb5,clientaddr=192.168.203.98,addr=192.168.203.10)

testuser2 at client:~$ ls -l /home/
totaal 20
drwxr-xr-x 2 correctid correctid 4096 2010-03-03 11:33 correctid
drwxr-xr-x 23 testuser1 testuser1 4096 2010-03-03 11:45 testuser1
drwxr-xr-x 2 testuser2 testuser2 4096 2010-03-03 11:26 testuser2
drwxr-xr-x 2 testuser3 testuser3 4096 2010-03-03 09:56 testuser3
drwx------ 24 nobody nogroup 4096 2010-02-24 13:41 valentyn
testuser2 at client:~$ ls -ln /home/
totaal 20
drwxr-xr-x 2 1004 1004 4096 2010-03-03 11:33 correctid
drwxr-xr-x 23 1000 1000 4096 2010-03-03 11:45 testuser1
drwxr-xr-x 2 1003 1003 4096 2010-03-03 11:26 testuser2
drwxr-xr-x 2 1001 1001 4096 2010-03-03 09:56 testuser3
drwx------ 24 65534 65534 4096 2010-02-24 13:41 valentyn

Please note, that there is stupid tricks to confuse the heck out of
anyone (if the above is not enough already ;)

For example, if you happen to know someone else's password, you can use
"kinit someoneelse" on the client. This will tell the server that your
uid-number coming from this client is essentially equal to someoneelse
on the server. Due to credentials caching you can't seem to correct
this. Here we show testuser3 getting the "valentyn" principal and
changing al my files, then being unable to change his own files:
su - testuser3 # and please note, testuser3 does not have a ticket yet,
# so he can't read his home directory:
No directory, logging in with HOME=/
testuser3 at host98:/$ kinit valentyn
valentyn at KANTOOR.OFFICE.BUREAU's Password:
testuser3 at host98:/$ cd /home/valentyn/
testuser3 at host98:/home/valentyn$ touch I-am-you
testuser3 at host98:/home/valentyn$ whoami
testuser3
All right. Now testuser3 regrets and tries to get his own identity back
- but he can't!
$ kinit testuser3
testuser3 at KANTOOR.OFFICE.BUREAU's Password:
testuser3 at host98:/home/valentyn$ klist
Credentials cache: FILE:/tmp/krb5cc_1001
Principal: testuser3 at KANTOOR.OFFICE.BUREAU

Issued Expires Principal
Mar 3 11:59:17 Mar 3 21:59:17
krbtgt/KANTOOR.OFFICE.BUREAU at KANTOOR.OFFICE.BUREAU
testuser3 at host98:/home/valentyn$ touch I-am-still-you
testuser3 at host98:/home/valentyn$ cd /home/testuser3/
testuser3 at host98:/home/testuser3$ touch I-am-not-I
touch: cannot touch `I-am-not-I': Permission denied
testuser3 at host98:/home/testuser3$ ls -al
total 20
drwxr-xr-x 2 testuser3 testuser3 4096 Mar 3 09:56 .

As you can see, uid 1001 is mapped to uid 1000 on the server, no matter
what we do. (Does this have a timeout? Does anyone know?)

Anyway, that doesn't have anything to do with idmapd.

I'd be glad to send more information about the configuration used; if
anyone has comments, please say so. As I have seen that an error is
easily made during testing (at first, I did not even have the NFS dir
mounted and I was almost crying victory, when I noted my stupid
mistake), so please send comments/questions.

Best regards,

Valentijn

[J. Bruce Fields]

Post by Valentijn Sessink
For example, if you happen to know someone else's password, you can use
"kinit someoneelse" on the client. This will tell the server that your
uid-number coming from this client is essentially equal to someoneelse
on the server. Due to credentials caching you can't seem to correct
this. Here we show testuser3 getting the "valentyn" principal and
su - testuser3 # and please note, testuser3 does not have a ticket yet,
No directory, logging in with HOME=/
testuser3 at host98:/$ kinit valentyn
testuser3 at host98:/$ cd /home/valentyn/
testuser3 at host98:/home/valentyn$ touch I-am-you
testuser3 at host98:/home/valentyn$ whoami
testuser3
All right. Now testuser3 regrets and tries to get his own identity back
- but he can't!
$ kinit testuser3
testuser3 at host98:/home/valentyn$ klist
Credentials cache: FILE:/tmp/krb5cc_1001
Principal: testuser3 at KANTOOR.OFFICE.BUREAU
Issued Expires Principal
Mar 3 11:59:17 Mar 3 21:59:17
krbtgt/KANTOOR.OFFICE.BUREAU at KANTOOR.OFFICE.BUREAU
testuser3 at host98:/home/valentyn$ touch I-am-still-you
testuser3 at host98:/home/valentyn$ cd /home/testuser3/
testuser3 at host98:/home/testuser3$ touch I-am-not-I
touch: cannot touch `I-am-not-I': Permission denied
testuser3 at host98:/home/testuser3$ ls -al
total 20
drwxr-xr-x 2 testuser3 testuser3 4096 Mar 3 09:56 .
As you can see, uid 1001 is mapped to uid 1000 on the server, no matter
what we do. (Does this have a timeout? Does anyone know?)

Once the kernel gets a valid kerberos context, it will keep using it
probably until it times out (I can't remember how long that is, but
could be until the ticket times out). So it won't notice if you've done
a kinit as someone else.

(And, yes, that should be fixed some day.)

--b.

[William A. (Andy) Adamson]

Post by Valentijn Sessink

Post by William A. (Andy) Adamson
You always need to have UID/GID mapping on the client be the same as
on the server if you want ls -l on the client to Just Work. Run LDAP (

On the server, there's users "valentyn" with uid 1000, and testuser1, 2
and 3 with uids 1001, 1002 and 1003, and a user that we will sync on
root at server:/home# for a in valentyn testuser{1,2,3} correctid; do id
$a; done
uid=1000(valentyn) gid=1000(valentyn) groepen=1000(valentyn)
uid=1001(testuser1) gid=1001(testuser1) groepen=1001(testuser1)
uid=1002(testuser2) gid=1002(testuser2) groepen=1002(testuser2)
uid=1003(testuser3) gid=1003(testuser3) groepen=1003(testuser3)
uid=1004(correctid) gid=1004(correctid) groepen=1004(correctid)
root at server:/home# ls -l
totaal 20
drwxr-xr-x ?2 correctid correctid 4096 2010-03-03 11:33 correctid
drwxr-xr-x 23 testuser1 testuser1 4096 2010-03-03 11:31 testuser1
drwxr-xr-x ?2 testuser2 testuser2 4096 2010-03-03 11:26 testuser2
drwxr-xr-x ?2 testuser3 testuser3 4096 2010-03-03 09:56 testuser3
drwx------ 24 valentyn ?valentyn ?4096 2010-02-24 13:41 valentyn
root at server:/home# ls -ln
totaal 20
drwxr-xr-x ?2 1004 1004 4096 2010-03-03 11:33 correctid
drwxr-xr-x 23 1001 1001 4096 2010-03-03 11:31 testuser1
drwxr-xr-x ?2 1002 1002 4096 2010-03-03 11:26 testuser2
drwxr-xr-x ?2 1003 1003 4096 2010-03-03 09:56 testuser3
drwx------ 24 1000 1000 4096 2010-02-24 13:41 valentyn
On the client, I'm using the same usernames, but different uids; I used
root at client:~# for a in valentyn valentijn testuser{1,2,3} correctid; do
id $a; done
id: valentyn: No such user
uid=1002(valentijn) gid=1002(valentijn) groups=1002(valentijn)
uid=1000(testuser1) gid=1000(testuser1) groups=1000(testuser1)
uid=1003(testuser2) gid=1003(testuser2) groups=1003(testuser2)
uid=1001(testuser3) gid=1001(testuser3) groups=1001(testuser3)
uid=1004(correctid) gid=1004(correctid) groups=1004(correctid)
root at client:~# mount|grep home
server:/home on /home type nfs4
(rw,sec=krb5,clientaddr=192.168.203.98,addr=192.168.203.10)
testuser2 at client:~$ ls -l /home/
totaal 20
drwxr-xr-x ?2 correctid correctid 4096 2010-03-03 11:33 correctid
drwxr-xr-x 23 testuser1 testuser1 4096 2010-03-03 11:45 testuser1
drwxr-xr-x ?2 testuser2 testuser2 4096 2010-03-03 11:26 testuser2
drwxr-xr-x ?2 testuser3 testuser3 4096 2010-03-03 09:56 testuser3
drwx------ 24 nobody ? ?nogroup ? 4096 2010-02-24 13:41 valentyn
testuser2 at client:~$ ls -ln /home/
totaal 20
drwxr-xr-x ?2 ?1004 ?1004 4096 2010-03-03 11:33 correctid
drwxr-xr-x 23 ?1000 ?1000 4096 2010-03-03 11:45 testuser1
drwxr-xr-x ?2 ?1003 ?1003 4096 2010-03-03 11:26 testuser2
drwxr-xr-x ?2 ?1001 ?1001 4096 2010-03-03 09:56 testuser3
drwx------ 24 65534 65534 4096 2010-02-24 13:41 valentyn
Please note, that there is stupid tricks to confuse the heck out of
anyone (if the above is not enough already ;)

client~$ ls -l => GETATTR => server which asks server:idmapd to map
UIDs into name at domian.

The client receives testuser1 at domain, testuser2 at domain,
testuser3 at domain,correctid at domain, and valentyn at domain which are
passed from the kernel NFSv4 client to the client::idmapd and
corresponding UIDs are returned to the kernel NFSv4 client:

testuser1 at domain => 1000
testuser2 at domain => 1003
testuser3 at domain => 1001
correctid at domain => 1004
valentyn at domain => 65534 (no mapping, so UID for user nobody is returned)

The kernel then passes the UID list back to user land to 'ls' which
maps the UIDs to users.

So, when using the NFSv4 layer which translates all UID/GID and ACL
who's into name at domain, having different UID/GID on client than on the
server using AUTH_SYS seems to Just Work.

BUT! If you login on the client as a user that exists on the server
where the UIDs are different, say testuser2, then 'who you are' on the
client (testuser2 UID=1003) is different than 'who you are' on the
server (UID of 1003 => testuser3)

Login as testuser2 on the client (UID=1003) and then create a file
"/home/test/foo" on the server using AUTH_SYS. The server would get an
RPC credential with the user=1003 which would map to
"testuser3" on the server.

server~$ ls -l /home/test
drwx------ 24 testuser3 testuser3 4096 2010-02-24 13:41 foo
server~$ ls -ln /home/test
drwx------ 24 1003 1003 4096 2010-02-24 13:41 foo

client~$ ls -l /home/test
drwx------ 24 testuser2 testuser2 4096 2010-02-24 13:41 foo
client~$ ls -ln /home/test
drwx------ 24 1003 1003 4096 2010-02-24 13:41 foo

So, this where it most defiantly *does not* Just Work.


-->Andy

Post by Valentijn Sessink
For example, if you happen to know someone else's password, you can use
"kinit someoneelse" on the client. This will tell the server that your
uid-number coming from this client is essentially equal to someoneelse
on the server. Due to credentials caching you can't seem to correct
this. Here we show testuser3 getting the "valentyn" principal and
su - testuser3 # and please note, testuser3 does not have a ticket yet,
No directory, logging in with HOME=/
testuser3 at host98:/$ kinit valentyn
testuser3 at host98:/$ cd /home/valentyn/
testuser3 at host98:/home/valentyn$ touch I-am-you
testuser3 at host98:/home/valentyn$ whoami
testuser3
All right. Now testuser3 regrets and tries to get his own identity back
- but he can't!
$ kinit testuser3
testuser3 at host98:/home/valentyn$ klist
Credentials cache: FILE:/tmp/krb5cc_1001
? ? ? ?Principal: testuser3 at KANTOOR.OFFICE.BUREAU
?Issued ? ? ? ? ? Expires ? ? ? ? ?Principal
Mar ?3 11:59:17 ?Mar ?3 21:59:17
krbtgt/KANTOOR.OFFICE.BUREAU at KANTOOR.OFFICE.BUREAU
testuser3 at host98:/home/valentyn$ touch I-am-still-you
testuser3 at host98:/home/valentyn$ cd /home/testuser3/
testuser3 at host98:/home/testuser3$ touch I-am-not-I
touch: cannot touch `I-am-not-I': Permission denied
testuser3 at host98:/home/testuser3$ ls -al
total 20
drwxr-xr-x 2 testuser3 testuser3 4096 Mar ?3 09:56 .
As you can see, uid 1001 is mapped to uid 1000 on the server, no matter
what we do. (Does this have a timeout? Does anyone know?)
Anyway, that doesn't have anything to do with idmapd.
I'd be glad to send more information about the configuration used; if
anyone has comments, please say so. As I have seen that an error is
easily made during testing (at first, I did not even have the NFS dir
mounted and I was almost crying victory, when I noted my stupid
mistake), so please send comments/questions.
Best regards,
Valentijn

[Valentijn Sessink]

Post by William A. (Andy) Adamson
BUT! If you login on the client as a user that exists on the server
where the UIDs are different, say testuser2, then 'who you are' on the
client (testuser2 UID=1003) is different than 'who you are' on the
server (UID of 1003 => testuser3)

That's only if you use sec=sys.

Post by William A. (Andy) Adamson
Login as testuser2 on the client (UID=1003) and then create a file
"/home/test/foo" on the server using AUTH_SYS.

My example is about using sec=krb5. That will work.

Doing stuff without kerberos (i.e. sec=sys) will break things, I'm sure
of that.

Post by William A. (Andy) Adamson
So, this where it most defiantly *does not* Just Work.

I thought the "just work" was about Kerberos/NFS4. Using sec=sys with
different UID's will most definately break things.

V.

[William A. (Andy) Adamson]

Post by Valentijn Sessink

Post by William A. (Andy) Adamson
BUT! If you login on the client as a user that exists on the server
where the UIDs are different, say testuser2, then 'who you are' on the
client (testuser2 UID=1003) is different than 'who you are' on the
server (UID of 1003 => testuser3)

That's only if you use sec=sys.

Post by William A. (Andy) Adamson
Login as testuser2 on the client (UID=1003) and then create a file
"/home/test/foo" on the server using AUTH_SYS.

My example is about using sec=krb5. That will work.
Doing stuff without kerberos (i.e. sec=sys) will break things, I'm sure
of that.

Post by William A. (Andy) Adamson
So, this where it most defiantly *does not* Just Work.

I thought the "just work" was about Kerberos/NFS4. Using sec=sys with
different UID's will most definately break things.

Sorry, I didn't understand your example was using kerberos/nfs4. That
will indeed work - but becomes hard to manage if you want to do things
like migration, or if you have users that use different client
machines where the view of an exported file system will be different
WRT which users get mapped to "nobody".

-->Andy

Post by Valentijn Sessink
V.