Intermittent SMB Share Prompting for Credentials at Log on

We have an annoying issue where perhaps once a week some users are getting a message prompting for connection credentials at logon. Even when giving correct creds, the connection is refused.

Only happens to some users, and it just “goes away” after some time.

Active Directory environment, clients are via Windows 2022 terminal servers, TrueNAS is Dragonfish-24.04.2.

Time is correct, same time source to AD and TrueNAS. DNS is good.

We have users on a handful of RDS servers, the issue seems to occur on a single RDS server at a time affecting all new users on that server. New and existing users on other RDS servers are unaffected. The issue moves around the RDS servers without any obvious pattern, what’s good one day is not the next and so on.

We have other TrueNAS / AD environments that work flawlessly, and have never had this issue on other systems.

We are seeing this error in /var/log/error
smbd[1377049]: Too many open files, unable to open more! smbd’s max open files = 16424
but unsure it its related.

There are many posts in the forum about similar symptoms, but there doesn’t seem to be a definitive root cause.

I’m unsure how best to troubleshoot this, very much hoping someone in this community can point me in the right direction.

Thanks in advance,
Dave

So to add to this we are seeing this in /var/log/auth.log when logon fails

"event": "AUTHENTICATION",
"event_data": {
  "becameAccount": null,
  "becameDomain": null,
  "becameSid": null,
    },
  "result": {
    "type": "NTSTATUS",
    "value_raw": 3221225572,
    "value_parsed": "NT_STATUS_NO_SUCH_USER"
  }
},
"success": false

but when logon is normal

"event": "AUTHENTICATION",
"event_data": {
  "becameAccount": **logonname**,
  "becameDomain": **domainname**,
  "becameSid": **thelongSID**,
    },
  "result": {
    "type": "**NTSTATUS**",
    "value_raw": **0**,
    "value_parsed": "**SUCCESS**"
  }
},
"success": false

With nothing else to try we upgraded this server to EEL over the weekend.

We made it through Monday ok, but Tuesday morning we had this same issue back.

There was no instance of the “NT_STATUS_NO_SUCH_USER” message in the logs until the time users started reporting problems, so it appears this message is linked to the problem we are seeing.

Any suggestions from here?