How to map user IDs on an NFS share?

Question

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.

Answer 1

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 were using SMB or SSHFS and authenticated to the server as "bart", you would only have the privileges of the user "bart" on the server – it doesn't matter what ls -l reports, it doesn't matter if you are root on the local system; the local uid= option wouldn't have any effect on what your SSHFS account is allowed to do server-side.

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 their 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 design.

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. Make sure both sides use the same idmap domain (as reported by nfsidmap -d) – if it differs, set it manually via /etc/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 NFSv4. Run mount or findmnt -u to see what version is being selected.

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 any complex additional components like LDAP or Active Directory or IPA – just the fairly small "krb5kdc" daemon.

   (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).

Answer 2

The best way to solve this is by using kerberos as mentioned before.

As an alternative to kerberos, on how you can achieve the same goal while using NFS4, considering you wanna do this for a few machines in your home.

Lets have in mind you are sharing the directory /mnt/public

1. exported it like:

/mnt/public 192.168.1.0/24(rw)

The question mentions a way to map users, my understanding is the goal is have a way to cross-connect users access with a simple NFS shares. So I'm mapping groups instead of stand-alone users. The same logic can be used for users by using SUID instead of SGID

2. We need a specific GID to be in all our devices

groupadd homeshare -g 27000

The clients will also need the same GID, that means manually create a group with ID 27000 in all the clients.

3. Create the public directory with GSID permissions:

mkdir -p /mnt/public
chmod g+s /mnt/public
chown :homeshare /mnt/public

the public share must use group suid and be owned by the group you've just created

As a plus define a password for the group in the clients. Use newgrp to login on it. With that, you don't need to add all the users to the group, only the ones who you shared the group password will have access.

Example:

gpasswd homeshare # define the password to the group

newgrp homeshare #login in the group using the password

Answer 3

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!