Stop SMB corrupting files on your network
Help! My files keep corrupting when using SMB 2/3
Data corruption can be a headache, even more so when it’s within a database and the last restore point means rolling back several hours worth of work! Don’t let SMB issues get you down …
Banish those SMB woes!
The Scenario :
You have a nice fast network running SMB 2 (or 3). File access speeds are great and everything is running fine but then, out of nowhere, you keep ending up with a corrupted file or database no matter how many times you repair it. This is one of those situations that can drive you CRAZY!
We came across this exact situation ourselves while configuring a new network for a client. Their previous system consisted of an old Windows Server 2000 unit (somehow it had managed to keep running all this time!) with Windows XP machines on a domain. They had an old Access 2003 database shared from the server which they each had a shortcut to and, for the most part, everything ran without issues. Roll forward to the year 2014 and the new setup is a Server 2012 R2 Micro Server with Windows 8 Pro machines on domain and … *drum roll* … an Access database that kept corrupting!
The Approach :
After working our way through an exhausting list of possibilities that could be causing the corruption, a headache that I’m sure a lot of you can associate with, it came to light that the issue only occurred when SMB 2 (or 3) was enabled on the network. As soon as we forced the network to run in the old SMB 1 mode the Access database worked without hiccup, however, as soon as SMB 2/3 was re-enabled any access to the database by multiple users resulted in a corrupted .MDB file.
I’m sure, at this point, that a lot of people would just cut their losses and run the network using SMB 1. Whilst this would have the net result of everything working the real caveat of this approach is the network speeds. When using SMB 1 there is no caching and data has to be accessed in real-time whereas with SMB 2/3 the caching utilised leads to a much quicker response time when working with shared data hosted on a server. To leave SMB 2/3 disabled just felt like a step backward.
The Issue :
The issue itself lies within the decisions that Microsoft made with SMB 2/3 and how to optimise the cache of file meta information such as size, update time and whether the file exists on the server. As a result of this design decision the SMB 2/3 protocol, with its default configuration, ‘breaks’ applications that rely on shared and concurrent data access, which in our case was the MS Access database.
Anyway, time to move onto the part you are really here for …
The solution to the issue is one of those that is so obscure, you wonder how you ever stumbled across it, yet so simple to implement.
NOTE: You do not need to make these changes to the server, only the client machines.
Located within the registry of the client machines is the key:
Within this key create the following DWORD (32-bit) values:
Set each of the new DWORD values to ’0′ and then reboot the machine.
Non-Manual Solution :
If you are not a fan of manually editing the registry or would rather have a one-click (or double-click as the case may be) solution then you can download and use the provided .Reg file which will add the three values mentioned above.
Please be assured that the download from our site is virus free, however, as always we would advise you to always scan downloads for your own peace of mind.
Sometimes you look at something and think ‘Why on Earth did they choose to do it that way’ and believe me when I say we have come across our fair share of those!
With regards to the SMB issue the decisions made by Microsoft are correct for 99.9% of situations and when you are not using ‘old’ database systems that are sensitive to concurrent data access (ideally you should be looking to use SQL) everything works great.
Unfortunately this is one of those situations where it really does benefit from upgrading your systems throughout and not just in parts.