Recently a lot of users complained that they could not access or mount or connect to public shares hosted by a newer Server 2012 R2 virtual machine running on Xen. The users all had a common trait that they were trying to access the shares with SMB1 from XP, and OS X on Apple/Mac computers. Windows 7 and other Server 2012 computers could access the shares without any errors. After a lot of testing, the resolution turned out to be a registry change which turned off SMB2. During testing we did the following:
- I created test shares on the problem server on both the c and e drives, and still was not able to connect to them with OS X 10.9.1 or XP. Whether trying to mount the shares by UNC or DNS, or IP Address, or mapped drives, I could not mount or view the shares. I modified these new shared directories permissions to see if authentication, security, or permissions were the problem, but no difference. The error message on the Macs was: “There was a problem connecting to the server “servername”. The share does not exist.” and on XP was: “The specified network name is no longer available”.
- I created a new share on a separate Server 2012 R2 server. My mac was able to mount this share created on it. This anomaly is what is still vexing because it’s an identical share on an identical operating system, but still the public shares had to be fixed. I looked at differences between the two server’s registries and could not find any discrepancies in the hive located at HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesLanmanServer. It would be nice for such an occasion to have an easy-to-use tool like linux’ diff, sdiff, or colordiff to compare registries side-by-side, but I digress.
- After finding the post by Nicolas Moreno here: http://social.technet.microsoft.com/Forums/windowsserver/en-US/bca317cd-87aa-4fd7-b12a-6715e6dddfe5/cant-access-unc-share-on-windows-server-2012-r2?forum=winserver8gen I checked the good working server and found that it’s server service is using Srv2 (smb2), but it is able to provide shares. Again, the server that can’t share with older clients also was using Srv2 (SMB2), but the symptoms were a lot like the post’s description.
- First, I took a snapshot of the virtual machine, I backed up the Registry Hive/Key with an export, and then made the registry change:
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesLanmanServerDependOnServiceFrom: SamSS Srv2To: SamSS Srv
- After making the change and rebooting the server, all of the clients (2000, 2003, XP, Mac OSX 10.8 Mountain Lion, Snow Leopard, Mavericks) could access the shares again.
An associate had made changes to this server prior to the incident cropping up so it’s hard to be sure just when and what caused the SMB2 windows shares to block access, but for now everyone can access the public drives. Please leave a note if this resolution helped or if you found a way to get broken SMB2 shares working again without changing the registry.