[Samba] Failed to find cifs/fs-share at dom.corp (kvno 109) in keytab

L.P.H. van Belle belle at bazuin.nl
Tue Nov 5 15:55:33 UTC 2019


> > Change this one.
> > /etc/hosts
> > fs-a.dom.corp fs-a oldsamba  # Old/wrong
> > fs-a.dom.corp fs-a oldsamba.dom.corp oldsamba  # 
> new/correct
> > Or
> > fs-a.dom.corp fs-a oldsamba.dom.corp  # new/correct
> No, none of them are correct

No, Rowland, your really wrong here. ( i dont say that often.. )  :-p
But i give you the doubt, once.. ;-), so show me why that is incorrect.. 

> >
> > Here i personaly preffer :
> > fs-a.dom.corp fs-a
> But that is.

All examples i showed are correct, how people use it, is up to them. 
I show why i say it is correct. what i showed complies with RFC's. 

And handy to know. 

Format is : 
IP	FQDN 	ALIAS (Optional other Aliasses.) 

I have things like this. 
IP hostn1.domain1.tld hostn1 somenamehere.completlydiffernt.tld somenamehere whatever.dom.tld 

And All work fine with kerberos any alias.. because i have 1 IP for 1 hostname and 1 PTR. 
All other things, are CNAMES in DNS and if only used locally on the server then i have it in /etc/hosts.

> >
> > Why is this used : getwd cache = yes ?
> > For my understanding, i think you can remove it, because 
> this is should be handled differently in samba4.
> Yes, it should be removed, but only because it is a default setting.

Ok, that confirms what i saw, in some old list mails. (somehere 2012)

> > Which ofcourse defaults to FILE:/etc/krb5.keytab
> I was trying show that a keytab was being created but not used.

Ahh.. And i created a keytab for him that did not overwrite his original keytab..
And in the other mails you missed the mv /etc/krb5.keytab2 /etc/krb5.keytab   ;-) 

> >
> >
> >>> Failed to find cifs/oldsamba at DOM.CORP(kvno 113) in keytab
> >>> MEMORY:cifs_srv_keytab (arcfour-hmac-md5)]
> >> Then something reads the keytab in memory and cannot find the
> >> required SPN, or to put it another way, whatever is trying 
> to find the
> >> SPN isn't  reading the keytab you created above, it is 
> reading the one in memory.
> > Ok, this part above, yes, your right, its reading in 
> memory, but to my believe,
> > From:  kerberos method = secrets and keytab,  and as far i 
> know "secrets" = MEMORY

> Sorry but no, 'secrets' = secrets.tdb (unless this is something else 
> wrong in the smb.conf manpage)

Ok, so then we need a reboot of that server, that clears the memory then, correct? 
But after a reboot.. Its still there because its in secrets.tdb which might be use in memory,
We can ask that @ one off the other devs. 

> > but ask youself, why is it using the "oldsamba" name if he 
> is using oldsamba as aliasname.
> > Thats the key here, so conclusion resolving 
> problems/incorrectly setup.
> >
> > So there for im saying. ( typed this before i got the 
> script output ).
> > OLDSAMBA is still in /etc/hosts but before the newHostname
> > Or it still has a dns A record.
> > Or samba is also using the Netbios Alias names while 
> creating keytab entries.
> >     ... And this, should in my opinion not happen, so lets 
> wait what comes back.
> > AND his keytab file is still incorrectly setup.
> >
> > And as i saw in the debug script output, i betting now on 
> /etc/hosts that needs fixing.
> This is quite possibly a DNS problem, my gut feeling is to leave the 
> domain, clean everything up and then rejoin, hopefully this 
> will fix things.

Yes, that is the last option AFTER the DNS/resolving fixes. 

So what is the output of : tdbdump secrets.tdb 
(apt-get install tdb-tools) 

I'll be entry is there. 

Of an other simple test, this part. 

    kerberos method = secrets and keytab
    dedicated keytab file = /etc/krb5.keytab

Change that to 
    kerberos method = dedicated keytab
    dedicated keytab file = /etc/krb5.keytab

That removes the use of secrets.tdb 

! Stop/start samba, dont restart.. 

And try again. 



More information about the samba mailing list