[I moderated through the first copy to krb5-bugs, but not the second copy, and I didn't moderate through to krbdev. I prefer if messages go to just one project list, so that the follow-up conversation doesn't get fragmented.] The cause of this bug is obscured by an error handling flaw in kinit -t KDB:. When kinit calls kinit_kbd_init(), it destroys and recreates the krb5_context, but doesn't reset the global variable errctx which is used by extended_com_err_fn(). That can be fixed with the following patch: diff --git a/src/clients/kinit/kinit.c b/src/clients/kinit/kinit.c index a518284..3fdae28 100644 --- a/src/clients/kinit/kinit.c +++ b/src/clients/kinit/kinit.c @@ -718,6 +718,7 @@ k5_kinit(struct k_opts *opts, struct k5_data *k5) #ifndef _WIN32 if (strncmp(opts->keytab_name, "KDB:", 4) == 0) { ret = kinit_kdb_init(&k5->ctx, k5->me->realm.data); + errctx = k5->ctx; if (ret) { com_err(progname, ret, _("while setting up KDB keytab for realm %s"), Without that fix, we just have the error string for KRB5_KDB_CANTREAD_STORED, not the extended error message set in krb5_db_def_fetch_mkey(). So all we know for now is that krb5_db_def_fetch_mkey_keytab() didn't succeed. It's hard to theorize beyond that. kt_file.c does contain locking calls, but they are straightforward blocking POSIX file locks which shouldn't fail.