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.
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 byls
orstat
, 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.