4

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?

3

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.

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" > 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
0

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

  • 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. – Robert Koszewski Apr 21 '18 at 10:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.