Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have an NFS tree exported from a file server that is secured using Kerberos and uses LDAP for authentication and uid/gid management. Everything works swimmingly for each client machine and each individual user, but I'm not sure how to grant access to parts of the share to daemons.

The daemons typically run with a setuid to a local system account, so there aren't any specific credentials for them on the server. If I can get in and muck around with the source I can usually get them to call kinit with a keytab file for a user that exists in kerberos when they start, but this is not always possible.

Our environment prohibits me from cracking things wide open by making them world readable, or from removing Kerberos from the NFS entirely.

I fiddled with adding a subtree to /etc/exports with all_squash, anonuid=... and anongid=... set, but that just made it world-readable to every client machine. It needs to be accessible only to a certain machine.

I've tried using samba but we have some daemons that have an "NFS or bust" approach to working with shares (anything involving mercurial, for example).

Most of our servers run Ubuntu 10.04 LTS, though the problem also affects a 12.04 LTS client we have.

Is there a way I can grant an entire system a system-wide ticket for a particular Kerberos user so any user on that system can always access the share? Or is there some other method of achieving this kind of access that I can investigate?

share|improve this question
up vote 3 down vote accepted

A "proper" way to do this would involve rewriting init scripts to make use of k5start in daemon-mode and per-daemon keytabs. This will ensure that the running daemon has access to a valid credential cache while it is running.

You'll likely want daemon/hostname.domain.tld style principles. They're easier to track and easier to manage the keytabs for. Adding a key to a keytab automatically increments the key version number(KVNO) and randomizes the "password" for that principal.

share|improve this answer
Oh thank you! This looks like exactly what I've been looking for. I will give it a try and report back. – Shabbyrobe Aug 15 '12 at 11:07
As far as the ticket refreshing goes, will the TGT last for the whole time the daemon is running or will there be a time when the daemon simply can't renew any more? – Shabbyrobe Aug 15 '12 at 11:09
k5start should be able to acquire a valid ticket so long as the keytab is valid and the principal can be issued tickets. – 84104 Aug 15 '12 at 14:27

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.