NFSv4 permissions on AIX

Question

I am attempting to use an NFSv4 mount across two systems that do not share UID/GIDs. This is for a system migration where the old environment used whatever UID/GIDs were available, and they now conflict on the new environment. I've given all the users new non-conflicting IDs on the new environment.

My issue is the NFS mount. I am trying to use NFSv4 due to it passing IDs as strings, not as numbers (which should help for mapping). I can get a filesystem mounted on the old environment, and when I do an ls -l, I see the correct names on both sides (so the mapping is working).

When I try to touch a file as a user (a user that exists on both systems with different UIDs), I get permission denied. The user is a member of the proper group on both systems (the group has different GIDs on both environment, but the user is a proper member on both sides).

There are other options for fixing my issue (using NFSv3 and re-mapping UID/GIDs), but I don't want to do that if I can avoid it.

---

Here's my configuration and some testing to show you what I see...

Server config:

# chnfsdom
Current local domain: red.act.ed
# cat /etc/exports
/usr/sap/trans -vers=4,sec=sys,rw,root=172.29.4.56:172.29.4.55:172.29.4.65
# ls -ld /usr/sap/trans/data
drwxrwxr-x    2 d01adm   sapsys       118784 Apr 23 08:25 /usr/sap/trans/data
# ls -nld /usr/sap/trans/data
drwxrwxr-x    2 300      300          118784 Apr 23 08:25 /usr/sap/trans/data

Client config:

# chnfsdom
Current local domain: red.act.ed
# mount | grep trans
devbox   /usr/sap/trans   /usr/sap/trans   nfs4   Apr 23 09:01 vers=4
qabox:/ # ls -ld /usr/sap/trans/data
drwxrwxr-x    2 d01adm   sapsys       118784 Apr 23 09:25 /usr/sap/trans/data
qabox:/ # ls -nld /usr/sap/trans/data
drwxrwxr-x    2 8        14           118784 Apr 23 09:25 /usr/sap/trans/data

---

Based on that info, it looks like UID/GID translation is working properly. Here's the rub (on the client box)...

qabox:q01adm> pwd
/usr/sap/trans
qabox:q01adm> ls -ld .
drwxrwxr-x   14 d01adm   sapsys         4096 Apr 23 09:56 .
qabox:q01adm> id
uid=12(q01adm) gid=14(sapsys) groups=0(system),7(security),4294967294(nobody),15(oper),16(dba)
qabox:q01adm> touch file
touch: 0652-046 Cannot create file.

Here's what I can do with root on that same client box:

qabox:/usr/sap/trans # pwd
/usr/sap/trans
qabox:/usr/sap/trans # id
uid=0(root) gid=0(system) groups=2(bin),3(sys),7(security),8(cron),10(audit),11(lp),14(sapsys)
qabox:/usr/sap/trans # touch file
qabox:/usr/sap/trans # chown q01adm:sapsys file
qabox:/usr/sap/trans # ls -l file
-rw-r--r--    1 q01adm   sapsys            0 Apr 23 09:59 file
qabox:/usr/sap/trans # ls -nl file
-rw-r--r--    1 12       14                0 Apr 23 09:59 file

And on the server box, I see this:

# ls -l /usr/sap/trans/file
-rw-r--r--    1 q01adm   sapsys            0 Apr 23 08:59 /usr/sap/trans/file
# ls -nl /usr/sap/trans/file
-rw-r--r--    1 302      300               0 Apr 23 08:59 /usr/sap/trans/file

So, from everything I can see...the UID/GID translation is working properly, I just can't write files as a non-root user on the client.

Answer 1

According to my limited knowledge, the NFSv4 ID mapping only applies to stat() results and other information sent over NFS itself – that is, to file owners sent by chown, returned by ls or stat, etc.

However, authentication is handled by a lower level – SunRPC – which still uses your numeric UID in the default AUTH_UNIX protocol. So if you're user #12 locally, that's what the server will receive as well.

To avoid this, you'd need an authentication mechanism that supports usernames; Kerberos (AUTH_GSS) might be the only choice here.