I have a Server (Debian) that is serving some folders trough NFS and a Client (Debian) that connects to the NFS Server (With NFSv4) and mounts that exported folder. So far everything is fine, I can connect and modify the content of the folders. But the users are completely messed up. From what I understand this is due to NFS using the UIDs to set the permissions, and as the UIDs of the users from the Client and the Server differ, then this happens, which is still expected. But from what I understood, by enabling NFSv4, IDMAPD should kick in and use the username instead of the UIDs. The users do exist on the Server and Client side, they just have different UIDs. But for whatever reason IDMAPD doesn't work or doesn't seem to do anything.

So here is what I've done so far:

On Server Side:

  • installed nfs-kernel-server
  • populated the /etc/exports with the proper export settings --> /rfolder ip/24(rw,sync,no_subtree_check,no_root_squash)
  • and changed /etc/default/nfs-common to have NEED_IDMAPD=yes

On the Client Side

  • installed nfs-common
  • and changed /etc/default/nfs-common to have NEED_IDMAPD=yes
  • and mount the folder with "mount -t nfs4 ip:/rfolder /media/lfolder"

Rebooted and restarted both several times, but still nothing. When I create from the Server a folder with user A, on the Client I see that the folder owner is some user X. When I create a file from the Client with user A, on the Server side it says its from some user Y.

I checked with HTOP that the rpc.idmap process is running on the Server and it is indeed. Although on the Client it doesn't appears to be running. By trying to manually start the service on the Client I just got an error message stating that IDMAP requires the nfs-kernel-server dependency to run. So I installed it on the Client side, and now I have the rpc.idmap process running on both Client and Server. Restarted both, and the issue still persists.

Any idea what is wrong here? Or how to configure this properly?


2 Answers 2


There are a couple of things to note when using NFSv4 id mapping on mounts which use the default AUTH_SYS authentication (sec=sys mount option) instead of Kerberos.

NOTE: With AUTH_SYS idmapping only translates the user/group names. Permissions are still checked against local UID/GID values. Only way to get permissions working with usernames is with Kerberos.

On recent kernels, only the server uses rpc.idmapd (documented in man rpc.idmapd). When using idmap, the user names are transmitted in user@domain format. Unless a domain name is configured in /etc/idmapd.conf, idmapd uses the system's DNS domain name. For idmap to map the users correctly, the domain name needs to be same on the client and on the server.

Secondly, kernel disables id mapping for NFSv4 sec=sys mounts by default. Setting nfs4_disable_idmapping parameter to false enables id mapping for sec=sys mounts.

On server:

echo "N" > /sys/module/nfsd/parameters/nfs4_disable_idmapping

and on client(s):

echo "N" > /sys/module/nfs/parameters/nfs4_disable_idmapping

You need to clear idmap cache with nfsidmap -c on clients for the changes to be visible on mounted NFSv4 file systems.

To make these changes permanent, create configuration files in /etc/modprobe.d/,

on server (modprobe.d/nfsd.conf):

options nfsd nfs4_disable_idmapping=N

on client(s) (modprobe.d/nfs.conf):

options nfs nfs4_disable_idmapping=N
  • The path of the runtime config file for client is missing its prefix (tried to edit but was denied); the correct path reads: /sys/module/nfs/parameters/nfs4_disable_idmapping
    – sxc731
    Commented Jul 23, 2019 at 14:23
  • 9
    Just to add an important point, after all of the above setup with sec=sys, ID mapping works only while reading files. Writing/modifying is governed by simple UNIX DAC because RPC mechanism knows nothing about mapping. ID mapping works fully only with Kerberos. serverfault.com/a/812829/452872 Commented Dec 2, 2019 at 8:33
  • 1
    @IrfanLatif, wow, I wasted so much time until I saw your comment. Thank you for clarifying!
    – Nate
    Commented Dec 11, 2019 at 8:49
  • 2
    @Nate I think my statement is still misleading. In fact ID mapping doesn't work with sec=sys at all. The apparent ownership is just shown by the client kernel, the server kernel won't let you even read a file if UID/GID of calling user doesn't actually match with file's UID/GID and also the file is not readable by world (o+r). I had figured that out while trying to make NFS work on Android. Commented Dec 11, 2019 at 9:53
  • 3
    @IrfanLatif thank you for the clarification, I added the point to the answer. Turns out when I tried this all the systems already had matching UIDs/GIDs, so everything worked by luck :\
    – sebasth
    Commented Dec 11, 2019 at 10:48

It is fairly known and documented behaviour. If you have different users in the server side, and client side who share the same uid, the files will appear to have different owners.

Besides shared files, it is advisable to take care to map the users with the same id in all machines sharing the same filesystems.

You can do it manually, some minimum automation/scripting system, or better yet, or setting up centralized authentication, for instance, with LDAP. see Centralized authentication using OpenLDAP

  • 2
    I'm aware that this is a known way of how NFSv3 and older work. But this is supposedly solved in NFSv4 which comes with IDMAP which should map the usernames independently of the UID of each system. So I'd like to go the official way rather than hacking around and manually synchonizing the UIDs (Who knows if something else is not using the UID on that system?) or working around with LDAP. LDAP is not an option anyway because the systems are connected trough a VPN, so a permanent connection is never guaranteed. Commented Apr 21, 2018 at 10:40

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .