0

On Ubuntu (xenial aka 16.04) all clients show dir and file owners in all NFS4 mounted directories as nobody:nobody.

User and group database comes via sssd from ldap, both client and server use the same ldap sources/trees and getent passwd $user, shows the correct entry ($user is a non-local, i.e. ldap user entry, so ldap seems to work).

Users are able to write to the dirs owned by them (even if the OS shows nobody:nobody) and new files also end up with the correct ownership on the server, i.e. proper UID:GID as defined in the ldap tree. However, it is pretty weird, that Ubuntu users can't see, who owns which files. Also ssh seems to do some checks, and thus one cannot login using its authorized key method (i.e. w/o password) nor does it use any settings from ~/.ssh/* unless explicitly specified on CLI. This is a nightmare. Solaris clients have no trouble at all, so the problem must be Ubuntu/Linux related.

  • /etc/idmapd.conf has the proper domain set.
  • /etc/nsswitch.conf has files [SUCCESS=return] sss for passwd, group, shadow, services, netgroup, automount and hosts set.
  • /etc/default/nfs-common has NEED_GSSD, NEED_STATD set to no, STATDOPTS to ''.

Anything else I'm missing?

Thomas
  • 4,225
  • 5
  • 23
  • 28
OhaMett
  • 1
  • 1
  • 2

2 Answers2

1

This it due to NFSv4 idmap miss configuration. According to nfs spec, client and server use string-based principals as identifiers for owner and groups. The local idmapd configuration is responsible to convert those principals to local uid and gids. Usually this involves LDAP or NIS.

You can enforce client and server to use numeric id by:

$ echo Y > /sys/module/nfs/parameters/nfs4_disable_idmapping
$ nfsidmap -c

on client, and 

# echo Y > /sys/module/nfsd/parameters/nfs4_disable_idmapping

on server. And/or, to make changes permanent, use corresponding module configurtion:

$ echo "options nfs nfs4_disable_idmapping=1" > /etc/modprobe.d/nfs.conf

and

$ echo "options nfsd nfs4_disable_idmapping=1" > /etc/modprobe.d/nfsd.conf
kofemann
  • 4,626
  • 1
  • 25
  • 30
  • Thanx for this info. Unfortunately I cannot disable idmapping on the server, because it has no option for it and may even break other clients. It tried to disable it on the client only, but as expected, no change in behavior. Anyway, when you say "idmap miss configuration" I wonder, how to configure it correctly. As said, the required information are there and actually used by the OS - somehow - ... – OhaMett Oct 11 '17 at 18:26
  • Well, you need a) user names on client and server to be in sync; b) nfs domain in /etc/idmapd.conf on the client and server to be same; c) enforce principal based id mapping (put every where **N** there in the answer I was telling you to put **Y**); ensure that client and server use same uid and gid. The best way to get ids and names in sung is with LDAP (or NIS) – kofemann Oct 12 '17 at 16:48
  • Strange, as said all this has been already done: a) is in sync, because both server and client use the same server - verified via getent passwd ... on both sides; b) has the domain set, c) pushed N to /sys/module/nfsd/parameters/nfs4_disable_idmapping , removed /etc/modprobe.d/nfs* ; reboot just in case - still nobody:nobody :( – OhaMett Oct 16 '17 at 12:18
  • BTW: Found somewhere, that one should add 'create id_resolver * * /usr/sbin/nfsidmap -t 600 %k %d' to /etc/request-key.conf , but if I do so, autofs doesn't work at all. So wondering, whether this is old/incompat. or simply bogus stuff? – OhaMett Oct 16 '17 at 12:21
  • can you update your question with output of **tshark -i any -f "port 2049" -O nfs'** where GETATTR request is available – kofemann Oct 16 '17 at 14:20
0

After digging a little bit deeper into it, it appears, that the Linux NFS4 client is not zone/cgroup/LXC aware. I.e. it blindly uses the the request-key configuration from the global zone (/etc/request-key.d/id_resolver.conf), which results into calling /usr/sbin/nfsidmap. Since the global zone (GZ) is of cause a minimal zone, it doesn't know anything about the identities used in non-global zones (NGZ) alias containers. And BTW: mapping the GZs own identities to NGZs 1:1 could be seen as a security problem/bug, anyway.

If request-key would provide an information to be able to deduce, from which zone or cgroup the request was initiated, one could certainly write a simple wrapper for GZ's /usr/sbin/nfsidmap, which calls the appropriate /usr/sbin/nfsidmap in the related zone. Unfortunately there seems to be no way, to "recover" this missing piece of information.

So for now the answer is: can't work properly because of design flaw.

OhaMett
  • 1
  • 1
  • 2