Kerberos-secured NFSv4: nss_getpwnam: name '8' does not map into domain
Hi again,
I've another annoying issue with my new Kerberos-secured NFSv4 setup.
Sometimes when Exim4 writes to the mounted NFS share, it fails to set
owner and permissions on the written file. Exim4 runs as local user
Debian-exim:Debian-exim but tries to set owner of created files on
the NFS share to 'mail:mail'. Both the local user Debian-exim and
the local user mail are authenticated against the Kerberos server and
principals 'Debian-exim@DOMAIN.ORG' as well as 'mail@DOMAIN.ORG' do
exist.
Obviously, not time Exim4 creates a file and sets owner on the NFS
share, the error is produced. Most of the time, this just works and
new files are owned by 'mail:mail'. But sometimes, it fails. In
these cases, Exim4 gives the following error:
2015-07-08 12:56:43 ... defer (22): Invalid argument: while setting
perms on maildir tmp/1742360537.H643669P4542.clt.domain.org
At the same time, the NFS/Kerberos-Server logs the following:
Jul 8 12:59:30 nfs1 rpc.idmapd[4353]: nss_getpwnam: name '8' does not
map into domain 'domain.org'
Even more weird, after the described error happens, owner changes
don't work at all anymore for some time. Something like five minutes
later, everything works as expected again.
After searching the web, my first guess is that this is due to Exim4
trying to set owner of the created file to '8:8' instead of using
'mail:mail'. It seems like using UIDs isn't supported on
Kerberos-secured NFSv4 shares. Idmapd on the NFS/Kerberos server
is unable to map the user name '8' to a Kerberos principal.
But more testing reveiled that even a chown to '8:8' works on the
NFS share. So using UID instead of username doesn't seem to be the
problem here.
Do you have suggestions about what's the problem here or how to go
on with debugging?
Cheers,
jonas
Reply to: