How are you disseminating the user/group info that's contained in /etc/passwd
and /etc/group? You typically need to use NIS, LDAP, or rsync the /etc/passwd
/etc/group
files to all the machines that are automounting these mounts. Otherwise the clients know nothing of the permissions on the filesystem.
You might want to peruse the NIS Howto.
nfs.nfs4_disable_idmapping=
[NFSv4] When set to the default of '1', this option ensures that both the RPC level authentication scheme and the NFS level operations agree to use numeric uids/gids if the mount is using the 'sec=sys' security flavour. In effect it is disabling idmapping, which can make migration from legacy NFSv2/v3 systems to NFSv4 easier. Servers that do not support this mode of operation will be autodetected by the client, and it will fall back to using the idmapper. To turn off this behaviour, set the value to '0'.
nfsd.nfs4_disable_idmapping=
[NFSv4] When set to the default of '1', the NFSv4 server will return only numeric uids and gids to clients using auth_sys, and will accept numeric uids and gids from such clients. This is intended to ease migration from NFSv2/v3.
nfs.nfs4_disable_idmapping=1
and nfsd.nfs4_disable_idmapping=1
Disabling the id mapper nfsd.nfs4_disable_idmapping=1
and nfs.nfs4_disable_idmapping=1
on the SERVER and CLIENT resulted in systemd starting up to the user login prompt, with only 1 error:
- Failed to start Remount Root and Kernel File System, which was however resolved by adding
modconf
to the mkinitcpio
hooks; together with block keyboard
in an attempt to deal with the other apparent problem:
- the laptop keyboard does not work...
The rpc.idmapd -fvvv
did not output any messages.
I am able to login as root using an external USB keyboard, read and create files. I have not done any extensive testing so there could still be problems with this solution.
nfs.nfs4_disable_idmapping=0
and nfsd.nfs4_disable_idmapping=0
It seems that echo "options nfs nfs4_disable_idmapping=0" >> /etc/modprobe.d/nfs.conf
(or cat /sys/module/nfsd/parameters/nfs4_disable_idmapping -> N
) on the CLIENT did not have any effect.
The CLIENT id mapper was disabled until I explicitly passed the parameter nfs.nfs4_disable_idmapping=0
to the kernel during boot (GRUB).
The rpc.idmapd -fvvv
did not output any complaints. On the other hand, it did not print out anything else after establishing the first rpc.idmapd: Server : (user) id "0" -> name "root@localdomain"
...
The Wireshark log however no longer records a NFS4ERR_BADOWNER
.
Nonetheless, all the systemd startup failures persist...
- Failed to mount POSIX Message Queue File System.
- Failed to start Remount Root and Kernel File System.
- Failed to mount Huge Pages File System.
- Failed to mount Kernel Debug File System.
- Failed to mount Kernel Configuration File System.
- Then ends with Not tainted 4.13.12-1-ARCH #1...
Conclusion
nfs.nfs4_disable_idmapping=0
and nfsd.nfs4_disable_idmapping=0
Save for setting up Kerberos and troubleshooting, I am not sure what to try next. The rpc.idmapd
still seems to be unable to map correct permissions, but rpc.idmapd -fvvv
no longer outputs any errors...? What to do? The boot errors could perhaps be caused by something else... I dunno...
nfs.nfs4_disable_idmapping=1
and nfsd.nfs4_disable_idmapping=1
Although it works, the approach seems wrong; I am not migrating, and I should be able to set up the system using rpc.idmapd
. For now it will have to do; it will probably come back and bite me in the future...
Best Answer
Have a look at the map_static option in /etc/exports.
Or synchronize userids using NIS, LDAP, etc.