username/cron principals and cron

Rainer Krienke krienke at
Wed May 6 10:04:55 EDT 2015


I think I found the answer to this problem:

   Start a cronjob using a username/cron at REALM principle for a user who
   has his home on NFS4/kerberos directory who wants to access his home
   directory from within the cron job.

The solution has been discussed earlier here, I found the helpful hints
here in the archive:

After all the cron-principal is just handled like NFS4 root access. In
this case the client sends nfs/machine.domain at REALM as principal to the
NFS server which can be rewritten to root in /etc/idmapd.conf by adding
a line like

nfs/machine.domain at REALM = root   # allow NFS root access

in the static section. For the cron-principal things are very similar.
The principal visible at the NFS server for idmapping is simply
username/cron at REALM and can be rewritten to eg username so that a
cronjob authenticated with the help of this cron principal can also
write to NFS4 filesystems as unix user "username". So in this case you
add a line to /etc/idmapd.conf's static section like:

username/cron at REALM = username

I think you only have to do this on the NFS4 server. At the moment I
have this mapping on both NFS server and client but I guess configuring
it on the server should be sufficient.


Am 06.05.2015 um 10:10 schrieb Rainer Krienke:
> Hello to everyone,
> thank you Rank and thank you Robert for your answers. I tried to find
> out more. Beeing root on a NFS4 client I ran the following commands with
> different results. Before I tried this I commented out my auth_to_local
> rules from /etc/krb5.conf:
> # su username -c "/usr/bin/kinit username/cron at MYREALM; touch
> /home/username/xx"
> Password for username/cron at MYREALM: ******
> touch: cannot touch `/home/username/xx': Permission denied
> and after a reboot of the NFS client and after kdestroying all the
> /tmp/krb5_* caches I ran this:
> # su username -c "/usr/bin/kinit username at MYREALM; touch /home/username/xx"
> Password for username at MYREALM: ******
> # <success: no error message>
> So using principal username/cron at MYREALM does not permit the unix user
> username to write to NFS while principal username at MYREALM does.
> Behind the scene there is an ldap server that NFS client and server are
> configured to use in order to find out eg the uid of user "username" for
> id mapping. Running a getent passwd username returns on both sides the
> same entry with the same unix uid and gid.
> So the question for me is, should a principal "username/cron" be
> automaticall be mapped to a local unix user "username" so that
> "username" is then allowd to access a NFS4 mounted directory that
> belongs to "username". This is what does not work for me at the moment.
> Does anyone have such a setup thats working? Is perhaps some kind of
> flag needed for the kerberos cron-principal to make it work?
> If I try to play around with auth_to_local rules, that to my
> understading are thought for this purpose, where do I have to defined
> them? On the NFS client, the NFS Server or the Kerberos Server or on all
> of them?
> Thanks a lot
> Rainer
> Am 05.05.2015 um 16:43 schrieb Frank Cusack:
>> I'm surprised you need a mapping at all.  The default mapping should
>> simply strip any instance component.  What happens if you kinit
>> "manually" with username/cron using a password?
>> On Tue, May 5, 2015 at 4:24 AM, Rainer Krienke <krienke at
>> <mailto:krienke at>> wrote:
>>     Hello,
>>     I am setting up a kerberos/NFS4 environment. Basically everything seems
>>     to work. Every user has of course a princiapl username at MYREALM, where
>>     username is the unix user name. The users homes are on a kerberos/NFS4
>>     mounted directory.
> ________________________________________________
> Kerberos mailing list           Kerberos at

Rainer Krienke, Uni Koblenz, Rechenzentrum, A22, Universitaetsstrasse  1
56070 Koblenz,, Tel: +49261287 1312
PGP:,Fax: +49261287

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5065 bytes
Desc: S/MIME Cryptographic Signature
Url :

More information about the Kerberos mailing list