Comment 33 for bug 1124250

I am not entirely sure if this is 100%ly related to this bug, but let me tell you my story here (contains another workaround):

I was also experiencing the problem of frequently having my files owned by 4294967294.
Setup is Ubuntu 14.04 with automounted nfs4/kerberos homes, the NFS server is running Debian Wheezy.

The problem was not existing with the previously used Ubuntu 13.10, so I began investigating and tried almost everything I found (which is mostly documented here), ranging from setting sysctl values to installing the kernel patch posted here.

However, nothing did help, so I decided to debug via /proc/keys:

While I still had the problem, /proc/keys (as seen by root) showed keys like this:

0094f999 I--Q--- 1 15s 3b010000 0 0 id_legacy uid:user@fqdn: 5

Note worthing is the remaining time of 15 seconds, shortly thereafter the problem occured for me and /proc/keys looked like
this:

0094f999 I--Q--- 1 expd 3b010000 0 0 id_legacy uid:user@fqdn: 5

The key was "expired" and there was no new one in the list.
So I issued "nfsidmap -v -c" (which did repair the situation everytime I have tried) and voilà:

5482b3a I--Q--- 1 9m 3b010000 0 0 id_legacy uid:user@fqdn: 5

I had a fresh key with a lifetime of ~ 10 minutes. But listen up, now comes the final workaround which has "fixed" the problem for about 3 or 4 days now:

 # apt-get install keyutils
 # restart idmapd
 # nfsidmap -v -c

And now the keys do no longer expire:

2014218e I--Q--- 1 perm 3b010000 0 0 id_resolv uid:user@fqdn: 5

As already mentioned, this is working since several days now without any issues, my stress-test to check this is by the way:

 somedir$ for i in $(seq 100000); do touch $i;sleep 0.2;done
 somedir$ while (true); do ls -lR | grep 4294967294;done

I still do not know exactly why installing keyutils has solved the issue or why this package was not previously installed as a dependency, but hey, it is a workaround at least for me and maybe others.