6.11 Update -> SMB Passwords do not work anymore :-(

[MAM59]

after the Update the (formerly working) Users cannot connect to shares anymore. Every username and password is invalid, when it comes from a windows client within a domain.

The unraid server itself is not part of the domain (and it never should be).

I have tried many combinations of <workgroup>\username or <ip>\username, nothing works anymore.

 

Even resetting the passwords on the unraid box does not help, there is no secure connection available anymore 😞

 

(the shares can be accessed with the same users from other osses like FBSD, Libreelec or other linux running samba, but not from ANY windows machine !)

 

What to do???

 

Update: I was wrong, also other osses cannot accsess those shares anymore! 🙂

Always get an "authentication error"

[root@l3router ~]# ./remountsmbfs -r
mount_smbfs: unable to open connection: syserr = Authentication error
Mount Filme fehlgeschlagen

 

Edited September 24, 2022 by MAM59

[JorgeB]

Can you connect to a public share? And to the flash share if exported as public?

[MAM59]

2 minutes ago, JorgeB said:

Can you connect to a public share? And to the flash share if exported as public?

No public shares here yet, I have to calm down the users before... may take some time but I try it soon and report back

 

btw, Libreelec still can access the shares (but it only uses r/o shares)

 

Edited September 24, 2022 by MAM59

[MAM59]

There is another new strangeness:

If a windows client clicks on a link to a share, UNRAID notes this:

 

Sep 24 20:23:33 F  nmbd[24342]:
Sep 24 20:23:33 F  nmbd[24342]:   Samba name server F is now a local master browser for workgroup WERRIES2015 on subnet 172.17.0.1
Sep 24 20:23:33 F  nmbd[24342]:
Sep 24 20:23:33 F  nmbd[24342]:   *****
Sep 24 20:26:26 F nginx: 2022/09/24 20:26:26 [error] 7090#7090: *184504 limiting requests, excess: 20.419 by zone "authlimit", client: 192.168.0.161, server: , request: "PROPFIND /login HTTP/1.1", host: "f"
Sep 24 20:26:26 F nginx: 2022/09/24 20:26:26 [error] 7090#7090: *184506 limiting requests, excess: 20.406 by zone "authlimit", client: 192.168.0.161, server: , request: "PROPFIND /login HTTP/1.1", host: "f"
Sep 24 20:26:26 F nginx: 2022/09/24 20:26:26 [error] 7090#7090: *184508 limiting requests, excess: 20.392 by zone "authlimit", client: 192.168.0.161, server: , request: "PROPFIND /login HTTP/1.1", host: "f"
Sep 24 20:26:26 F nginx: 2022/09/24 20:26:26 [error] 7090#7090: *184510 limiting requests, excess: 20.378 by zone "authlimit", client: 192.168.0.161, server: , request: "PROPFIND /login HTTP/1.1", host: "f"
Sep 24 20:26:26 F nginx: 2022/09/24 20:26:26 [error] 7090#7090: *184512 limiting requests, excess: 20.364 by zone "authlimit", client: 192.168.0.161, server: , request: "PROPFIND /login HTTP/1.1", host: "f"
Sep 24 20:26:26 F nginx: 2022/09/24 20:26:26 [error] 7090#7090: *184514 limiting requests, excess: 20.351 by zone "authlimit", client: 192.168.0.161, server: , request: "PROPFIND /login HTTP/1.1", host: "f"

 

What has nginx to do with an SMB share????

(this happens everytime one wants to access a share from windows, no browser involved!)

 

[MAM59]

13 minutes ago, JorgeB said:

Can you connect to a public share? And to the flash share if exported as public?

No and no. Just because Windows has a stored connection with username and password. it will automatically send them, so you have no access to public shares at all...

 

I will try to delete the info and reboot and see what happen..s

 

[MAM59]

no, impossible 😞

You have not the slightest chance, if there is no stored data, windows automatically uses the domain credentials. Unraids log are flooded with these mysterious nginx errors (because the logon tries to reestablish the home shares) and that was it.

whatever you try, the credentials are send from now on and unraid cannot decipher them

 

Are you sure you have added proper domain support into 6.11?

Or has some crypto stuff changed so that passwords are meaningless now ? (but them, even resetting them does not help anymore 😞 )

 

I guess  I better rollback to 6.10 😞

 

 

[MAM59]

fyi: downgraded to 6.10, everything is back fine!

 

So I would recommend that limetech looks after what they have messed up with smb authentication in 6.11 and fix it asap

 

[JorgeB]

You should post a bug report.

[chatchka33]

I am having the same issue. I updated to 6.11 and now Windows cannot access private Unraid SMB shares that were working in 6.10.x.

[chatchka33]

I just reverted back to 6.10.3 and the shares are working again.

[MAM59]

7 hours ago, JorgeB said:

You should post a bug report.

where? how?

 

[JorgeB]

I see you found where, thanks.

[Jaybau]

I lost SMB access to shares too.

Windows 7

 

Reverted from 6.11.0 to 6.10.3, and now I have access to my shares again from Windows 7.
 

[dlandon]

9 hours ago, Jaybau said:

I lost SMB access to shares too.

Windows 7

 

Reverted from 6.11.0 to 6.10.3, and now I have access to my shares again from Windows 7.
 

Are you using AD or are any of your clients on a domain?

[Jaybau]

3 hours ago, dlandon said:

Are you using AD or are any of your clients on a domain?

 

No domain.  Home network.  "WORKGROUP".

 

I'm assuming it might have something to do with "SMB: remove NTLMv1 support".

Edited September 26, 2022 by Jaybau

[Frank1940]

11 minutes ago, Jaybau said:

 

No domain.  Home network.  "WORKGROUP".

 

I'm assuming it might have something to do with "SMB: remove NTLMv1 support".

Should not be an issue as Window 7 support SMB 2.1  as shown here:

 

 

And this:

Edited September 26, 2022 by Frank1940

[Unrayed]

Same thing happened to me there, updating from 6.10.3 to 6.11 - no smb access to any of my exported shares, credential errors. I reverted back to 6.10.3 and all is good again.

[Unrayed]

30 minutes ago, Unrayed said:

Same thing happened to me there, updating from 6.10.3 to 6.11 - no smb access to any of my exported shares, credential errors. I reverted back to 6.10.3 and all is good again.

Sorted there on Windows 10, I changed the attached setting to display as shown. It was set to "Use NTLMv2 Security Session if needed", and I vaguely remember changing this setting ages ago to help with slow SMB speeds, so maybe that's the issue? Unfortunately though, I'm still seeing fluctuating/slow smb transfers to my cache drive (980 Evo x2 in BTRFS)

Edited September 26, 2022 by Unrayed

[MAM59]

this is really tricky. so far I did not find the difference between "working" clients and non working ones.

It is NOT :

* windows version and edtion

* Domain membership or not

 

Anyway, I have a working and nonworking client on the same lan now and can do measurements against a 6.10 and a 6.11 server at the same time. But debugging SMB is not really my thing...

At least I was able to do some captures, two clients, domain members, same user, same command issued ("dir \\g\frei") to view a public share on an 6.11 server. One client works, one gets "wrong password" denial. Comparing the packets I found the first difference in the session setup packet:

the green lines mark the spot. the "good" client sends zeros as challenges, the "bad" one sends some data (and UNRAID answers with "don't like you error" and cancels the connection (red frame on the left).

(I did the same with 6.10, looks alike, but this time Unraid is pleased to get a challenge and lets the user access the data)

 

I have no idea what makes windows to insert a challenge or not and even fewer ideas how to control/stop it.

Maybe somebody can make an educated guess?

 

[MAM59]

AAAARRGGGGHH! woke up this morning, started the machines, rechecked the bug: GONE! 😞

Now even the formerly not working workstations can flawlessly connect to 6.11.

Besides sleeping I have not done or changed anything!

Just 2 days of waiting and testing.

(and maybe deleting some old GPOs, but obviously it took very long for them to produce a visible change)

 

Just did a recapture and now the marked fields are all zero too in the login packet.

Both private and public shares work from either wks I have tested this morning already.

Maybe I should give the update another chance???

 

GEEE, I DO HATE THESE BUGS THAT COME OUT OF NOWHERE AND VANISH THE SAME WAY A FEW DAYS LATER!

Still no clue what happened and why...

[Frank1940]

Welcome to the wonderful world of Samba!  Seven plus years back this was often the case.  (In those days, I often said that fixing Samba  issues was more witchcraft than science.)   One thing to check is to see if your Windows server and PC's received an update in the past twenty-four hours. 

 

 

[miicar]

On 9/24/2022 at 1:30 PM, MAM59 said:

There is another new strangeness:

If a windows client clicks on a link to a share, UNRAID notes this:

Sep 24 20:26:26 F nginx: 2022/09/24 20:26:26 [error] 7090#7090: *184504 limiting requests, excess: 20.419 by zone "authlimit", client: 192.168.0.161, server: , request: "PROPFIND /login HTTP/1.1", host: "f"

 

(this happens everytime one wants to access a share from windows, no browser involved!)

 

 

I am also RANDOMLY getting this error in the logs, and while that PC (attached to the IP) isn't even being used.  sometimes other random PCs (IP) on the network are showing up as this error as well.  it is quite frustrating, as my designers cannot access their files, or the access is extremely slow for a while...then its fine for weeks....

It seems 6.11.5 has some weird bugs the older versions didn't...is unraid trying to do too much?    

Does anyone have real world experience with this (nginx error) issue existing on earlier versions of 6.11.x? I am using multiple pools, and i am afraid of going back too far in versions (till 6.12.x is official/stable as the changelog seems to address this nginx issue) will start causing me other issues as well.  I can cleanly go back to 6.11.3 (UNraids built in downgrade), but if i'm still getting the SMB locking up issues, whats the point.  It seems that 6.10.x didn't have this issue, so if i have to, i'll go back to that i guess.

 

 

Edited April 4, 2023 by miicar