What's recommended to avoid issues with minimum SMB version in services config?

[Stilez]

I've been having issues on a "known good" test network with 9.10.2U3 with failed SMB browsing network-wide. I'm getting the error NT_STATUS_REQUEST_NOT_ACCEPTED very early in the session, as soon as he client has reached the server and tries to get a tree of browsable objects, followed by restarting the use of SMB and retrying - for the end user it shows as browsing fails, although Wireshark and the Samba logs all show there's no connectivity issues. I get similar running smbclient -L localhost -U% on the host: "protocol negotiation failed: NT_STATUS_INVALID_NETWORK_RESPONSE". But I could use samba by IP which suggested a name server issue.

A google search eventually pinned down the culprit, which was setting minimum client version = SMB2 in SMB config. Apparently this causes this issue for reasons not known, and indeed when I reversed it and restarted samba, the test network resumed running smooth as butter.

My question is, is this a SMB bug (if so is there a bug#/fix/workaround?) and as at least some other people have hit it, is there a sensible workaround I can apply or a way to avoid the issue, if I want to block insecure early versions of the protocol, since using this parameter seems to have the slightly unfortunate side-effect of destroying SMB browsing on my test net right now? :D


(Sorry if this has been asked before now - it probably has. I did try searching but nothing came up for that specific text and there are thousands of posts for SMB2 issues and browsing failure; I couldn't find anything covering this. Thank you for help!)

 

[anodos]

I've been having issues on a "known good" test network with 9.10.2U3 with failed SMB browsing network-wide. I'm getting the error NT_STATUS_REQUEST_NOT_ACCEPTED very early in the session, as soon as he client has reached the server and tries to get a tree of browsable objects, followed by restarting the use of SMB and retrying - for the end user it shows as browsing fails, although Wireshark and the Samba logs all show there's no connectivity issues. I get similar running smbclient -L localhost -U% on the host: "protocol negotiation failed: NT_STATUS_INVALID_NETWORK_RESPONSE". But I could use samba by IP which suggested a name server issue.

A google search eventually pinned down the culprit, which was setting minimum client version = SMB2 in SMB config. Apparently this causes this issue for reasons not known, and indeed when I reversed it and restarted samba, the test network resumed running smooth as butter.

My question is, is this a SMB bug (if so is there a bug#/fix/workaround?) and as at least some other people have hit it, is there a sensible workaround I can apply or a way to avoid the issue, if I want to block insecure early versions of the protocol, since using this parameter seems to have the slightly unfortunate side-effect of destroying SMB browsing on my test net right now? :D


(Sorry if this has been asked before now - it probably has. I did try searching but nothing came up for that specific text and there are thousands of posts for SMB2 issues and browsing failure; I couldn't find anything covering this. Thank you for help!)

What client? Post your smb4.conf file (/usr/local/etc/smb4.conf)

 

[Stilez]

Clients are all Win 8.1 x64 patched up to date. Also tested on the FreeNAS 9.10.2U3 server itself using smbclient
and other functions. Tested using a direct NIC-to-NIC patch connection isolated from WAN with Windows firewall fully disabled; connectivity confirmed by the ability to use SSH, web GUI, ping both ways etc.

My conf is at the end of this post and works nicely. But when I set "server min protocol = SMB2" or "server min protocol = SMB2_10" under "services -> SMB". the errors I described occur - the share can be used by IP and testparm is fine, but browsing fails and the shares aren't shown or usable if manually pasted, in Explorer; also some machines whose details should be provided by the browser master aren't listed either. When I remove that setting and restart SMB, these issues immediately stop and immediately, refreshing explorer quickly shows all shares which behave properly. I haven't tried selecting other minimum SMB levels than SMB2, SMB2_10, and "Unset".

The same behaviour happens locally on the server itself, when following the browser troubleshooting steps on samba.org. Commands such as "smbclient -L localhost -U%" or --user run on the FreeNAS box, switch back and forward between the errors shown, and the expected file share information output.

Server hardware is Supermicro X10 + Xeon E5 1620 v4 + 96GB ECC + both Chelsio 10G and Intel 1G NICs (the NIC used for connectivity doesn't change the behaviour). Relevant clients tried are Ivy Bridge X79 desktop, core2 HP laptop, and ASRock Haswell workstation, all Windows 8.1 x64 up to date with Intel 1G NIC (except the laptop), all show the same behaviour.

Other recent (2017) reference to the same apparent issue

# cat smb4.conf

[global]
server max protocol = SMB3_11
encrypt passwords = yes
dns proxy = no
strict locking = no
oplocks = yes
deadtime = 15
max log size = 51200
max open files = 2827136
logging = file
load printers = no
printing = bsd
printcap name = /dev/null
disable spoolss = yes
getwd cache = yes
guest account = nobody
map to guest = Bad User
obey pam restrictions = no
directory name cache size = 0
kernel change notify = no
panic action = /usr/local/libexec/samba/samba-backtrace
nsupdate command = /usr/local/bin/samba-nsupdate -g
ea support = yes
store dos attributes = yes
lm announce = yes
acl allow execute always = true
dos filemode = yes
multicast dns register = yes
domain logons = no
local master = yes
idmap config *: backend = tdb
idmap config *: range = 90000001-100000000
server role = standalone
netbios name = FREENAS-A
workgroup = WORKGROUP
security = user
pid directory = /var/run/samba
create mask = 0666
directory mask = 0777
client ntlmv2 auth = yes
dos charset = CP850
unix charset = UTF-8
log level = 3
# set socket options
socket options = TCP_NODELAY IPTOS_LOWDELAY SO_KEEPALIVE
# cache current directory content
getwd cache = yes
# speed up SMB by not testing if same filename exists with different casing, when saving
case sensitive = yes
preserve case = yes
short preserve case = yes
# disable client side caching
csc policy = disable
# disable MD5
reject md5 clients = yes
reject md5 servers = yes
# disable some various DOS and OS/2 functions
store dos attributes = no
ea support = no
# NetBIOS election priority
preferred master = yes
os level = 200

[Test_share_1]
path = /mnt/Testpool/Testdataset
printable = no
veto files = /.snapshot/.windows/.mac/.zfs/
writeable = yes
browseable = yes
recycle:repository = .recycle/%U
recycle:keeptree = yes
recycle:versions = yes
recycle:touch = yes
recycle:directory_mode = 0777
recycle:subdir_mode = 0700
vfs objects = zfs_space zfsacl streams_xattr recycle aio_pthread
hide dot files = no
guest ok = no
nfs4:mode = special
nfs4:acedup = merge
nfs4:chown = true
zfsacl:acesort = dontcare

 

[anodos]

Clients are all Win 8.1 x64 patched up to date. Also tested on the FreeNAS 9.10.2U3 server itself using smbclient
and other functions. Tested using a direct NIC-to-NIC patch connection isolated from WAN with Windows firewall fully disabled; connectivity confirmed by the ability to use SSH, web GUI, ping both ways etc.

My conf is at the end of this post and works nicely. But when I set "server min protocol = SMB2" or "server min protocol = SMB2_10" under "services -> SMB". the errors I described occur - the share can be used by IP and testparm is fine, but browsing fails and the shares aren't shown or usable if manually pasted, in Explorer; also some machines whose details should be provided by the browser master aren't listed either. When I remove that setting and restart SMB, these issues immediately stop and immediately, refreshing explorer quickly shows all shares which behave properly. I haven't tried selecting other minimum SMB levels than SMB2, SMB2_10, and "Unset".

The same behaviour happens locally on the server itself, when following the browser troubleshooting steps on samba.org. Commands such as "smbclient -L localhost -U%" or --user run on the FreeNAS box, switch back and forward between the errors shown, and the expected file share information output.

Server hardware is Supermicro X10 + Xeon E5 1620 v4 + 96GB ECC + both Chelsio 10G and Intel 1G NICs (the NIC used for connectivity doesn't change the behaviour). Relevant clients tried are Ivy Bridge X79 desktop, core2 HP laptop, and ASRock Haswell workstation, all Windows 8.1 x64 up to date with Intel 1G NIC (except the laptop), all show the same behaviour.

Other recent (2017) reference to the same apparent issue

# cat smb4.conf

Oh. That. I believe there's a bug in the version of Samba in FreeNAS (and older versions of samba) that causes it to freak out during protocol negotiation if the Min protocol is set to something higher than 2.02. (FYI, SMB2 = SMB2_10 = SMB2.10). FreeNAS 11, which is due in a few days, is supposed to bump the samba version to 4.6.2 or 4.6.3.

 

[Stilez]

Perfect information. Extra kudos points for "Oh, that" which made me chuckle - thanks!

 

[Stilez]

Just a heads-up in case anyone checks this thread, I'm still having this issue with 11.0-U1. Looks almost certainly like a Samba regression hitting 11.0-U1 (haven't checked 11.0).

Bug links:
* @ Samba: https://bugzilla.samba.org/show_bug.cgi?id=12895
* @ FreeNAS: https://bugs.freenas.org/issues/25104