How to map user IDs on an NFS share?

I have succesfully mounted an NFS share from my remote machine to my local. However, the files I want to edit on the remote machine are all owned by root.

How can I mount my NFS drive so that my local user can edit these files?

I tried the idmap.conf file, but I couldn't quite get if I should edit that on the local or remote machine and which services I should restart (again, local or remote) to have any affect.

From the past, I remember the uid=X,gid=X options to do something like this, but I now get this error on those:

mount.nfs: an incorrect mount option was specified

I am using Fedora 34 as local and CentOS 7.6 remote.

2 Answers

With all file-based network filesystems, file permissions are enforced by the server. What ls -l says you can do with a file doesn't necessarily have to match what you can actually do with that file. For example, if you use SSHFS and authenticate as "bart", you can make the SSHFS client report anything, but even if you are root locally, you will only have the privileges of the user "bart" on the server – the local uid= option wouldn't have any effect on what your SSHFS account is allowed to do.

But unlike SSHFS (which uses one connection and one set of credentials), NFS was originally designed to be a "system-wide" feature where the same mount could be used by various different users, each with its own privileges – and it was designed to work in homogenous environments together with NIS/YP, a system that ensured that the same accounts had the same UIDs on every machine. Most NFS client features (or lack thereof) still reflect that.

So with this in mind, UIDs have two completely different and independent usages in NFS: ownership data reported by server, and authentication credentials reported by client.

• Ownership information reported by server (such as data in ls -l) is handled as part of NFS itself.

  (This is where options like uid= would be relevant, but the Linux NFS client doesn't have them, although a few other filesystems do.)

  In NFSv4, ownership information can be translated using "idmap": the server converts the UID into a username@domain, the client converts that username back to its local UID. You need to make sure both sides use the same idmap domain (as reported by nfsidmap -d) – if it differs, set it in idmap.conf. However, this doesn't really let you do anything with that file – it's mostly just visual.

  In NFSv3 only a numeric UID can be reported, and there is no facility for mapping it – the client always sees the UID that's stored on the server.

• However, actual effective privileges rely on information reported by client as they are enforced server-side, not only client-side. This is handled at SunRPC level, so there's no relationship with NFS versions.

  Due to the NFS client being designed to be multi-user, its default authentication mechanism is to simply report the accessing user's UID to the server. So if you export and mount the NFS share with sec=sys (the default), then the client always reports your real UID to the server, and the server trusts it without any verification.

  Unfortunately, while in theory UIDs could be mapped here before reporting them to the server, there is no such feature in the Linux NFS client at all, and it always reports your real UID.

  To solve this, you would need to either synchronize your account's UID across all systems, or use Kerberos authentication via sec=krb5. This requires having a Kerberos KDC server set up.

So in short,

0. Make sure you're using NFS v4.

1. Run nfsidmap -d and verify that both systems use the same idmap domain. This is by default guessed from the system's FQDN (hostname -f) but it can also be set in /etc/idmapd.conf. This value doesn't need to be a real DNS domain, just an arbitrary string. This should fix the owner shown by ls.

2. Strongly consider setting up Kerberos, running a KDC on your server (it could be the same server or a different one), and switching NFS to sec=krb5. (Especially if you are using NFS over the Internet!) You do not need related components like LDAP or Active Directory or IPA.

   (The same Kerberos can also be used for SSH authentication via "GSSAPIAuthentication", not just for NFS.)

3. If that's not an option, then you will need to change your account's UID on one system to match the other. It's usually just a matter of logging in as root and doing usermod -u (which also chowns the entire home directory).

which user are you on your local machine? If you are root as well you should be able to edit these files. If your are root but you can not edit, have a look at your servers /etc/exports file as your root user might be squashed.

root_squash Map requests from uid/gid 0 to the anonymous uid/gid. Note that this does not apply to any other uids or gids that might be equally sensitive, such as user bin or group staff.

 no_root_squash Turn off root squashing. This option is mainly useful for diskless clients. all_squash Map all uids and gids to the anonymous user. Useful for NFS-exported public FTP directories, news spool directories, etc. The opposite option is no_all_squash, which is the default setting. anonuid and anongid These options explicitly set the uid and gid of the anonymous account. This option is primarily useful for PC/NFS clients, where you might want all requests appear to be from one user. As an example, consider the export entry for /home/joe in the example section below, which maps all requests to uid 150 (which is supposedly that of user joe).

Besides of this you should have same user IDs on remote and local machine. But there are no easy maintainable solutions for home use available.

In case you are NOT root there should be no way to archieve your goal as no one should be allowed to edit root's files on a remote machine!