Mike Burns
Mike Burns

Reputation: 96

NFS user mapping for root

I want to be able to share some files on an NFSv4.2 share to root on a client machine -- the specific use case shouldn't be important, but I'm trying to provision network storage for Docker volumes on the client.

The Problem

A simple echo foo > /mnt/share/example as root on the client machine results in a file owned by nobody:nogroup:

$ ls -l /mnt/share
-rw-r--r-- 1 nobody        nogroup           7 Dec 20 23:46 example

Mapping works fine for normal users (e.g. if I kinit as user on the client, UID mapping works correctly and permissions work as expected even when UIDs are different on the client and server).

The problem persists whether or not I use no_root_squash on the server side in /etc/exports.

My impression from reading man krb5.conf was that setting auth_to_local for the relevant realm should be adequate, but I have the following (obviously overpermissive) clause in krb5.conf on the NFS server:

[realms]
  REALM.EXAMPLE.COM = {
    admin_server = auth.example.com
    auth_to_local = RULE:[1:f](^.*$)s/^.*$/nfs-container/
    auth_to_local = RULE:[2:f](^.*$)s/^.*$/nfs-container/
    auth_to_local = RULE:[3:f](^.*$)s/^.*$/nfs-container/
    auth_to_local = RULE:[4:f](^.*$)s/^.*$/nfs-container/
    auth_to_local = RULE:[5:f](^.*$)s/^.*$/nfs-container/
    auth_to_local = RULE:[6:f](^.*$)s/^.*$/nfs-container/
    auth_to_local = DEFAULT
    kdc = auth.example.com
  }

My expectation is that this should map all users to nfs-container, but this isn't working for the host principal (which should be used for root) on the client, resulting in nobody:nobody or for normal users (which are mapped by name to their target user on the client).

What I've Tried

I started with more specific settings and slowly relaxed them until the absurd configuration shown above.

The directory is exported as follows in /etc/exports:

/pool/share *(rw,sec=krb5p,no_root_squash)

and imported on the client via fstab:

nfs.example.com:/pool/share /mnt/share nfs vers=4.2,sec=krb5p 0 0

Neither idmapd -c, nor reinitializing my ccaches, nor reboots have cleared anything up, so it seems like a configuration issue.

root on the client is still being squashed to nobody:nogroup (with simple commands like touch /mnt/share/file as root). I'm unsure how to continue so much as debugging this.

Upvotes: 1

Views: 84

Answers (0)

Related Questions