16

This question seems to have been asked many times already, but the other answers somehow did not apply to me.

Basically I just set up a new NFSv4 server and I am facing the classic problem where UIDs and GIDs do not match between server and client. However, syncronizing /etc/passwd and /etc/group is not feasible in my scenario. Note that I do have the same users on both machines (as opposed to this question).

Therefore I was looking into idmap: according to some sources, it seems that NFSv4 sends usernames (as opposed to the behaviour of NFSv3 to send UID/GID) and the role of idmap would be to translate these usernames to the server UID/GIDs.

However, this seems not to work in my case (setup details below), which I consider very standard (pretty much only installed NFS from repo).

Am I missing something? Is there a way to make this work without setting up LDAP or Kerberos?


Server setup

The server is has Ubuntu 16.04 installed and two users.

user1@server:~$ id user1
uid=1000(user1) gid=1000(user1) groups=1000(user1),27(sudo)
user1@server:~$ id user2
uid=1001(user2) gid=1001(user2) groups=1001(user2)

NFS was installed from repo and configured to export a test folder.

user1@server:~$ sudo apt-get install nfs-kernel-server

user1@server:~$ sudo cat /proc/fs/nfsd/versions 
+2 +3 +4 +4.1 +4.2

user1@server:~$ ls -ld /srv/nfs/test/
drwxrwxrwx 2 nobody nogroup 4096 nov  2 17:34 /srv/nfs/test/

user1@server:~$ cat /etc/exports 
"/srv/nfs/test" 192.168.x.x(rw,sync,no_subtree_check)

Since the server and the client have different hostnames, I changed the "Domain" value in the config file of idmapd. Otherwise the file is identical to the one installed by the package manager. Please notice that the content of this file is identical on both server and client.

user1@server:~$ cat /etc/idmapd.conf
[General]

Verbosity = 0
Pipefs-Directory = /run/rpc_pipefs
# set your own domain here, if id differs from FQDN minus hostname
Domain = mydomain

[Mapping]

Nobody-User = nobody
Nobody-Group = nogroup

Client setup

The client also has Ubuntu 16.04 and two users, which however have same usernames but different UID/GIDs.

user1@client:~$ id user1
uid=1001(user1) gid=1002(user1) groups=1002(user1),27(sudo)
user1@client:~$ id user2
uid=1000(user2) gid=1000(user2) groups=1000(user2),27(sudo)

NFS was installed from repo and the test share was mounted.

user1@client:~$ sudo apt-get install nfs-common

user1@client:~$ mkdir ./test
user1@client:~$ sudo mount -t nfs4 192.168.x.x:/srv/nfs/test ./test

Testing

First I create a file on the client, and this seems fine:

user1@client:~$ touch test/testfile
user1@client:~$ ls -l ./test
total 0
-rw-rw-r-- 1 user1 user1 0 nov  2 17:24 testfile

But when I view the file from the server, I notice that the owner is the wrong one, while the group does not exist.

user1@server:~$ ls -l /srv/nfs/test
total 0
-rw-rw-r-- 1 user2 1002 0 nov  2 17:24 testfile

Experiments

According to this answer to a similar question, id-mapping should be activated as follows, on the server (notice the errors):

user1@server:~$ sudo tee /sys/module/nfsd/parameters/nfs4_disable_idmapping <<< "N"
user1@server:~$ sudo nfsidmap -c
nfsidmap: 'id_resolver' keyring was not found.
user1@server:~$ sudo service rpcidmapd restart
Failed to restart rpcidmapd.service: Unit rpcidmapd.service not found.
user1@server:~$ sudo service nfs-kernel-server restart

While on the client (notice the absence of errors):

user1@client:~$ sudo tee /sys/module/nfs/parameters/nfs4_disable_idmapping <<< "N"
user1@client:~$ sudo nfsidmap -c

But the results are strange:

user1@client:~$ touch test/testfile
user1@client:~$ ls -l test
total 0
-rw-rw-r-- 1 user2 4294967294 0 nov  2 19:16 testfile
user1@server:~$ ls -l /srv/nfs/project/
total 0
-rw-rw-r-- 1 user2 1002 0 nov  2 19:16 prova

Another answer suggests amending the idmapd config as follows (content is the same on both machines):

user1@server:~$ cat /etc/idmapd.conf 
[General]

Verbosity = 0
Pipefs-Directory = /run/rpc_pipefs
# set your own domain here, if id differs from FQDN minus hostname
Domain = mydomain

[Translation]
   Method=static
[Static]
   user1@mydomain = user1

[Mapping]

Nobody-User = nobody
Nobody-Group = nogroup

But that does not appear to make any difference.

matpen
  • 387
  • 2
  • 4
  • 10

1 Answers1

11

NFSv4 will not translate the UIDs and GIDs as you might think when not using Kerberos and security flavor. But it does exactly act as you described. The reason is that NFSv4 will use AUTH_SYS security. A more detailed description can be found here.

Thomas
  • 4,155
  • 5
  • 21
  • 28
  • 2
    Thank you for your answer and the link, very informative. But still cannot fit it into the context... so what is the purpose of idmapping? Why is it called "rpcidmapd" if it doesnt work with rpc? And what is the effect of [these](http://serverfault.com/a/632315/178226) commands? – matpen Nov 04 '16 at 14:00
  • FWIW, it seems possible to enable NFSv4 id mapping even when using `AUTH_SYS` per this question: https://unix.stackexchange.com/q/438939/111905 – sxc731 Jul 23 '19 at 13:48
  • @sxc731: from my experience, and I did a test today, using `idmap` with `AUTH_SYS` does translate the UIDs and GIDs correctly. But the effective rights are not translated and even if `ls` does show you own directories or files you won't be able to make changes because numeric IDs do not match and with `AUTH_SYS` numeric IDs are used for access rights. – Thomas Jul 23 '19 at 21:01
  • 2
    @Thomas correct. When ID mapping is truned ON with `sec=sys`, files appear as per ID mappig but writing works as if there is no ID mapping happening at all. Another [reference](https://www.freebsd.org/cgi/man.cgi?query=nfsv4&manpath=FreeBSD+11.2-RELEASE+and+Ports): *"Although uid/gid numbers are no longer used in the NFSv4 protocol except optionally in the above strings, they will still be in the RPC authentication fields when using AUTH_SYS (sec=sys), which is the default. As such, in this case both the **user/group name and number spaces must be consistent between the client and server.**"* – Irfan Latif Dec 02 '19 at 08:08