13.0-U3.1: only new users can't connect over SMB

[JMY1000]

This is an update to this thread, which unfortunately I can't reply to anymore since that portion of the forum is read-only.

For approximately the past year, we've been having trouble when adding new users to our server. The issue started with 12.0-U8, but it's persisted through an upgrade to 13.0-U3.1. Although we're able to create the users just fine, whenever the new user attempts to connect to our main share, they're unable to log in. Based on the AUTH_LOG, it appears that these new users aren't being found:

root@server[~]# midclt call smb.status AUTH_LOG | jq ... { "timestamp": "2023-02-16T15:27:17.345727-0500", "type": "Authentication", "Authentication": { "version": { "major": 1, "minor": 2 }, "eventId": 4625, "logonId": "0", "logonType": 3, "status": "NT_STATUS_NO_SUCH_USER", "localAddress": "ipv4:[redacted]:445", "remoteAddress": "ipv4:[redacted]:53087", "serviceDescription": "SMB2", "authDescription": null, "clientDomain": "SERVER", "clientAccount": "thirteen", "workstation": "FACXC092DQL7F", "becameAccount": null, "becameDomain": null, "becameSid": null, "mappedAccount": "thirteen", "mappedDomain": "SERVER", "netlogonComputer": null, "netlogonTrustAccount": null, "netlogonNegotiateFlags": "0x00000000", "netlogonSecureChannelType": 0, "netlogonTrustAccountSid": null, "passwordType": "NTLMv2", "duration": 10235 }, "timestamp_tval": { "tv_sec": 1676579237, "tv_usec": 345727 } } ]

However, logging in with some of our longer-standing users works just fine:
root@server[~]# midclt call smb.status AUTH_LOG | jq ... { "timestamp": "2023-02-16T15:41:52.272855-0500", "type": "Authentication", "Authentication": { "version": { "major": 1, "minor": 2 }, "eventId": 4624, "logonId": "0", "logonType": 3, "status": "NT_STATUS_OK", "localAddress": "ipv4:[redacted]:445", "remoteAddress": "ipv4:[redacted]:53235", "serviceDescription": "SMB2", "authDescription": null, "clientDomain": "SERVER", "clientAccount": "[olduser]", "workstation": "FACXC092DQL7F", "becameAccount": "[olduser]", "becameDomain": "SERVER", "becameSid": "S-1-5-21-2592541842-2331454169-529703238-20099", "mappedAccount": "[olduser]", "mappedDomain": "SERVER", "netlogonComputer": null, "netlogonTrustAccount": null, "netlogonNegotiateFlags": "0x00000000", "netlogonSecureChannelType": 0, "netlogonTrustAccountSid": null, "passwordType": "NTLMv2", "duration": 14712 }, "timestamp_tval": { "tv_sec": 1676580112, "tv_usec": 272855 } } ]

Both users belong to the same primary group, with no auxiliary groups; both users have Samba authentication enabled. Both users can log in successfully over SSH. Neither user is locked.

This post mentions the same error being thrown after an upgrade to 12.0-U3; however, our SMBD log doesn't show any authentication or Unix account mapping errors like theirs did, and we're running 13.0-U3.1.

root@server[~]# cat /var/log/samba4/log.smbd ... [2023/02/16 15:27:07.575638, 0] ../../lib/param/loadparm.c:989(lpcfg_service_ok) WARNING: No path in service signup - making it unavailable! [2023/02/16 15:27:07.575673, 1] ../../lib/param/loadparm.c:995(lpcfg_service_ok) NOTE: Service signup is flagged unavailable. [2023/02/16 15:41:52.303439, 1] ../../source3/printing/printer_list.c:255(printer_list_get_last_refresh) Failed to fetch record! [2023/02/16 15:41:52.303745, 1] ../../source3/smbd/server_reload.c:67(delete_and_reload_printers) pcap cache not loaded [2023/02/16 15:41:52.305028, 0] ../../lib/param/loadparm.c:989(lpcfg_service_ok) WARNING: No path in service signup - making it unavailable! [2023/02/16 15:41:52.305088, 1] ../../lib/param/loadparm.c:995(lpcfg_service_ok) NOTE: Service signup is flagged unavailable. [2023/02/16 15:41:52.305130, 0] ../../lib/param/loadparm.c:989(lpcfg_service_ok) WARNING: No path in service signup - making it unavailable! [2023/02/16 15:41:52.305167, 1] ../../lib/param/loadparm.c:995(lpcfg_service_ok) NOTE: Service signup is flagged unavailable. [2023/02/16 15:41:52.556169, 1] ../../source3/rpc_server/srv_pipe_hnd.c:104(np_open) np_open: 'MsFteWds' is not a registered pipe!

We've also seen the following, which we're not sure if it's related

Searching the forums yielded this thread, which indicated there was a bug in 12.0 that was fixed in 13.0; however, we're still facing this problem, even after updating. We've also tried running the following, as suggested by @anodos:

rm /var/db/system/samba4/private/passdb.tdb midclt call smb.synchronize_passdb -job

Unfortunately, that resulted in no changes, as did disabling and re-enabling the SMB service.

What might be going on here?

 

[LucP]

For me, I had to enable the old NTLM1 auth and SMB1 support in services->smb for the shares to be visible across all my clients Without those two boxes checked, I get "invalid user or password" when mapping a network drive in Win7 Ultimate. True NAS 13 U4

 

[JMY1000]

For me, I had to enable the old NTLM1 auth and SMB1 support in services->smb for the shares to be visible across all my clients Without those two boxes checked, I get "invalid user or password" when mapping a network drive in Win7 Ultimate. True NAS 13 U4

All of our clients are macOS/Windows 10/Windows 11; we don't need NTLM1 or SMB1. Both the new users and old users are connecting on the same computers.

 

[LucP]

yep, same here, but without those boxes it does not work in my setup. In theory there is no need for the obsolete protocols but..... I pulled my hair out as some logins would work and others would not though the users were setup the same (as far as I can see) on the same server, and with the same client PC some would allow mapping of the shares and some would not. After checking the boxes, no more issues. As always, your mileage may vary, and pictures are simulated :)

 

[JMY1000]

yep, same here, but without those boxes it does not work in my setup. In theory there is no need for the obsolete protocols but..... I pulled my hair out as some logins would work and others would not though the users were setup the same (as far as I can see) on the same server, and with the same client PC some would allow mapping of the shares and some would not. After checking the boxes, no more issues. As always, your mileage may vary, and pictures are simulated :)

What client OS are you using? It sounded like you were using Windows 7 Ultimate, which should explain the need for the old protocols.

 

[LucP]

Android 4.4, Android 7, IOS, Win 10, Win7

 

[sfanla]

"clientDomain": "SERVER",
"clientAccount": "[olduser]",
"workstation": "FACXC092DQL7F",
"becameAccount": "[olduser]",
"becameDomain": "SERVER",
"becameSid": "S-1-5-21-2592541842-2331454169-529703238-20099",
"mappedAccount": "[olduser]",
"mappedDomain": "SERVER",

I just posted about a similar issue, except I have no old users to go off of. Did you ever resolve this?

 

[JMY1000]

I just posted about a similar issue, except I have no old users to go off of. Did you ever resolve this?

Nope, still unresolved.