Created attachment 13800 [details] smb.conf file We are seeing refused/very long login times (more that 10 seconds, and sometime minutes/failures) on our fileservers for a minute or two at exactly every 10 hour since the smbd/winbindd daemons were last restarted. (We used to restart our smbd/winbindd daemons at 4am every night, which caused problems and bug reports from our users at 2pm every day. Have since moved the restart to 7am so we at least can avoid having this problem during daytime). My guess is that this issue is due to the 10 hour default lifetime for Kerberos service tickets and something happens/goes wrong/takes a long time when winbindd(?) tries to renew it? Our setup: Samba 4.7.2 on FreeBSD 11.1 servers. Joined to a Windows 2012 AD domain (six AD servers). What makes the problem even more fun to pinpoint is that we don't _always_ see it (or perhaps we just miss it - we have a login latency testing system running that tests how long a smbclient takes to login to our four samba servers - every minute. Ideas? Anyone else see something like this? One wild idea I have is that it is due to slow kerberos ticket propagation between the AD servers and that when we see the problem the klient and the Samba server happen to be bound to different AD servers. Attaching our smb.conf file.
the kerberos method system keytab might be related to your problem. In case you still hvae this problem, I think this is too complex to analyze here, this is why nothing happens here. I recommend to look for alternative support for example from one of the companies offering samba support: https://www.samba.org/samba/support/globalsupport.html
Just a quick update on this old problem in case someone else does a search and finds this: For some unknown reason this issue that we've had since 2017 suddenly on Nov 6 2020 stopped occuring and hasn't reappeared again. We _think_ it might coincide with the AD guys upgrading their AD servers to Windows Server 2019 (and moved to new hardware), but a lot of stuff happend those days - servers moving to new locations, new network switches&routers... We didn't upgrade the Samba servers though (except for pointing to the new AD servers). Anyway, it's gone now and I hope it stays away... :-)