I haven't done the regression testing of rolling back to old versions of windows, but I can share that I'm seeing the same problem here, with Win 10 19044.1415 connecting to a TrueNAS Core 12 box. It works, but it certainly creates some noisy logs:
[2021/12/24 21:40:18.383339, 1] ../../source3/smbd/service.c:355(create_connection_session_info)
create_connection_session_info: guest user (from session setup) not permitted to access this share (personal)
[2021/12/24 21:40:18.383383, 1] ../../source3/smbd/service.c:544(make_connection_snum)
create_connection_session_info failed: NT_STATUS_ACCESS_DENIED
Per a previous commenter's question, my ICACLS output:
C:\>icacls \\nas\personal
\\nas\personal S-1-22-1-0:(F)
CREATOR OWNER:(OI)(CI)(IO)(F)
S-1-5-21-3997689159-3832354152-3824094002-1005:(M,DC)
CREATOR GROUP:(OI)(CI)(IO)(M,DC)
Successfully processed 1 files; Failed processing 0 files
EDIT:
This issue from November 2020 (!) seems very similar:
https://docs.microsoft.com/en-us/answers/questions/122178/windows-10-sends-unauthenticated-smb-requests.html
Also, in my case, unfortunately the client logs the same error (SMBClient Error code 31010) in the Windows event log for every single error that shows up in the samba server logs.
EDIT 2:
Possible success?
I've been able to get this behavior to stop by disabling Windows Defender real-time inspection globally on the Win10 client. I haven't yet discovered any tweaks to Defender settings that allow me to leave it enabled but not produce this behavior - for example, mapping a drive to the share and excluding that mapped drive from scanning in Defender settings does /not/ work.
EDIT 3:
The only long-term workaround I've found so far (that doesn't require killing all real-time malware protection) is to give in and enable guest logins for SMB shares. This lets the broken Windows behavior continue without triggering a flood of errors, and the rest of my Samba setup doesn't permit a guest to access anything (the guest user maps to 'nobody' and the filesystem ACLs are all chmod xx0) so this works fine for me. YMMV.
Interestingly, after this change, the Windows client now logs a complaint in the event log (once per share connection) that the remote SMB server is permitting guest connections when it really shouldn't...oh, the irony.