In an update he says:
if your vendor requires disabling SMB2 in order to force SMB1, they will also often require disabling oplocks. Disabling Oplocks is not recommended by Microsoft, but required by some older software, often due to using legacy database technology. Windows 10 RS3 and Windows Server 2016 RS3 allow a special oplock override workaround now for these scenarios – see https://twitter.com/NerdPyle/status/876880390866190336
. This is only a workaround – just like SMB1 oplock disable is only a workaround – and your vendor should update to not require it.
unfortunately when using DBFs (and other file based databases on Windows networks) SMB2 seems to have a major drawback: when workstations are running against a Windows 2008 and later server, they cache the file sizes.
When appending a new record, this is written at the position where the workstation thinks thet the file ends, and when more workstations are doing the same at the same time, they overwrite the records from others - a real nightmare.
I had this issue on a larger customer with (at this time) about 35 users, and was only able to stop it disabling oplocks and SMB2.
Now this customer has more than 70 users, with about 55-60 working at the same time, and using ADS the databases are absolutely stable now.
But since there is one application using DBFs (it is impossible to move it to ADS because of database encryption in place), I cannot enable SMB2.
Maybe the X# DBFCDX RDD will make things better - of course I would prefer to remove these settings.
I have to add that I never had issues with Samba on Linux servers ( not NAS boxes! ) using SMB2, and with larger tables.