windows 2022 server can't access omnios smb share

Freebsd1976

Active Member
Feb 23, 2018
295
44
28
after update my windows server 2019 to 2022 , can't access omnios smb share anymore.
my smb share use workgroup (no AD), on win 2022 and win10 omnios 15038k have same user and password, before upgrade everything run smooth.
now another windows 10 pc still can access omnios smb share, before upgrade the win2019 also no issues, cloud anyone give me some hints?
 

marv

Active Member
Apr 2, 2015
134
27
28
36
is it authentication issue (meaning it wont accept username/password) or some other issue?
do you see anything in windows event viewer regarding that or anything in omnios log?
 

Freebsd1976

Active Member
Feb 23, 2018
295
44
28
is it authentication issue (meaning it wont accept username/password) or some other issue?
do you see anything in windows event viewer regarding that or anything in omnios log?
can't access omnios server (using ip), no clue in event log and omnios log, but windows 2019 and win 10 fine
 

JSchuricht

Active Member
Apr 4, 2011
185
65
28
You didn't mention if you are using DFS so it may not be relevant but there is a glitch for an in place upgrade from 2019 to 2022 DFS. After the upgrade, the 2022 DFS server appears to work but fails with permission issues. The workaround I found is restarting the DFS service then disabling and re-enabling the DFS server for each namespace. Fun tracking down with multiple DFS servers in the lab and SMB shares working intermittently depending on the server it hits.
 

PeterF

New Member
Jul 28, 2014
29
7
3
65
after update my windows server 2019 to 2022 , can't access omnios smb share anymore.
my smb share use workgroup (no AD), on win 2022 and win10 omnios 15038k have same user and password, before upgrade everything run smooth.
now another windows 10 pc still can access omnios smb share, before upgrade the win2019 also no issues, cloud anyone give me some hints?
This sounds like the same problem I had with Windows 10 Insider and Omnios. After an insider update I could no longer connect to the Omnios SMB server. Tried every settings I could find, nothing helped. In the end I did install the latest official windows 10 in a VM (that connected to omnios without problem) and did capture of the network traffic on both systems. From there I found out that the Insider Win 10 had added 2 more ciphers that it presented to Omnios. Disabling these 2 ciphers made the Win 10 connect to the share!

The ciphers can be set with local group policy (gpedit). They are found under Lanman Workstation - Cipher suite order.
I set it only to use the 2 128 bit ciphers. I have attached a screenshot

I hope this can help you.

BR
Peter Fälth
 

Attachments

  • Like
Reactions: ecosse

Freebsd1976

Active Member
Feb 23, 2018
295
44
28
This sounds like the same problem I had with Windows 10 Insider and Omnios. After an insider update I could no longer connect to the Omnios SMB server. Tried every settings I could find, nothing helped. In the end I did install the latest official windows 10 in a VM (that connected to omnios without problem) and did capture of the network traffic on both systems. From there I found out that the Insider Win 10 had added 2 more ciphers that it presented to Omnios. Disabling these 2 ciphers made the Win 10 connect to the share!

The ciphers can be set with local group policy (gpedit). They are found under Lanman Workstation - Cipher suite order.
I set it only to use the 2 128 bit ciphers. I have attached a screenshot

I hope this can help you.

BR
Peter Fälth
thanks a alot , it works , but after change group policy need restart windows
 

daisho

New Member
Apr 25, 2019
27
4
3
Is it possible that it is not fixed yet?
In the feature I see that there is still a blocking issue: Feature #14047: Add support for SMB 3.1.1 AES-256 - illumos gate - illumos

I am still on W10 and maybe it is a different issue, but I lately updated my OmniOS to omnios-r151038-96eabf6ba4 (September) and napp-it is on current 21.dev (also September). My Windows 10 workstation is 21H1 with latest updates.
I wanted to tighten security on my NFS/SMB shares and during playing around with the settings at some time it stopped working.

When I set SMB server property "max_protocol" to "3.0"

My windows explorer does no longer ask for credentials but instead simply shows a "\poolname\share" folder.
The only content is some .$EXTEND folder (seems to be some metadata folder with info about share size).

I CAN do a "map network drive" though (but only when clicking "provide different credentials") and after a second credential popup (for some reason it does not accept the first try?) it connects and I can browse everything freely (and Get-SmbConnection in PowerShell shows 3.0 version)

I reverted to max_protocol=2.1 and it is working again.

P.S.: I also wondered which protocol versions are possible for the property, the man page still only shows 3.0. Is 3.1 or 3.1.1 also possible? Not sure where I can find the code for that module, just found an already open issue for the man page itself: Bug #13307: SMB manpage regarding [max|min]_protocol is not up-to-date - illumos gate - illumos
 

gea

Well-Known Member
Dec 31, 2010
2,722
940
113
DE

daisho

New Member
Apr 25, 2019
27
4
3
btw, possible versions for min_protocol and max_protocol are probably as following (from illumos-gate-master/usr/src/lib/smbsrv/libsmb/common/smb_cfg.c)

/*
* We store the max SMB protocol version in SMF as a string,
* (for convenience of svccfg etc) but the programmatic get/set
* interfaces use the numeric form.
*
* The numeric values are as defined in the [MS-SMB2] spec.
* except for how we represent "1" (for SMB1) which is an
* arbitrary value below SMB2_VERS_BASE.
*/
static struct str_val
smb_versions[] = {
{ "3.11", SMB_VERS_3_11 },
{ "3.02", SMB_VERS_3_02 },
{ "3.0", SMB_VERS_3_0 },
{ "2.1", SMB_VERS_2_1 },
{ "2.002", SMB_VERS_2_002 },
{ "1", SMB_VERS_1 },
{ NULL, 0 }
};

3.11 and 3.02 are missing from the man page currently. Just if someone want to configure that as e.g. max_protocol.
 
  • Like
Reactions: gea