Apple has a long history with computer networking, from AppleTalk to today’s Internet connected world. However, it is Windows networking that still causes all kinds of headaches for Mac OS X users. It seems that with every release of Mac OS X, Apple seems to have recurring issues with Windows shares. Some of Apple’s defenders will state that Apple adopts industry standards as is, and it is Microsoft and others who publish specs, but don’t actually follow them, so when Apple does follow the specs, it seems to just end up breaking things. SMB is the networking protocol that Microsoft uses for Windows networking. It is what allows Windows network file shares to work across the network. With the latest versions of Mac OS X, Apple abandoned the open source SAMBA package that most Linux distros use to connect to Windows, and wrote their own SMB2 software. This makes Mac OS X 10.9 Mavericks connect faster and better to Windows servers. Well that is when it works!
SMB Connections Fail
There is one Windows 2012 Essentials server with multiple shares. There are two Macs on the local network. One iMac is connected over Wireless N and one MacBook Pro is using a wired ethernet 1Gb connection. When using the Connect to Server… option the iMac connects fine and has no issues. The MacBook Pro opens the share and then never displays any files, it just spins in the lower left hand corner of the window that opens. Both computers are running Mac OS X 10.9.3 Mavericks.
Connecting via CIFS instead of SMB seems to work for the MacBook, but it is slower.
The solution ended up modifying the Windows 2012 Essentials server. There are two registry keys that need to be added in order to fix the problem for the MacBook.
Under this Registry Key:
Add these DWORD values:
- Smb2CreditsMin – make this 768
- Smb2CreditsMax – make this 16384
Once you made the changes restart the Windows Server and then the Macintosh clients. It should now fix the problem.
Microsoft provides the following information on these registry keys:
The defaults are 512 and 8192, respectively. These parameters allow the server to throttle client operation concurrency dynamically within the specified boundaries. Some clients might achieve increased throughput with higher concurrency limits, for example, copying files over high-bandwidth, high-latency links.
After upgrading to Mac OS X 10.8 Mountain Lion, I started to experience problems with Safari 6 and some HTTPS connections. For example I could no longer log into Amazon or even browse forums who used SSL connections. Ironically, I found a post on Apple’s forums that described some of my symptoms, but since the support forums are HTTPS, I could not use Safari. Luckily Firefox still worked. The problem on Apple’s forum went on about SSL Certificate issues and the solution is described on this blog posting, but this problem was specific to Mac OS X 10.7.4 Lion. There is also a bug that has to do with specifying a proxy in Mountain Lion. This seemed more plausible to me, since I use pfSense with Squid Proxy in transparent mode at home, however this also would not explain why only SSL connections had issues and regular HTTP sites worked fine.
After much research, it seems the simplest solutions work best. I had to manually specify my MTU setting from 1500 to 1492 in System Preferences – Network – Advanced… – Hardware – MTU. This immediately resolved my Amazon logging in issue.
Recently, I had the opportunity to diagnose a problem with an external Firewire drive and Mac OS X. The drive would no longer mount on the OS X desktop and the only place you could see it (other than Terminal) was in Disk Utility. If you ran Disk Utility – Verify or Repair, the message: invalid content in journal would appear. The fix to make it mountable again was to do the following in Terminal.
The first command gives you a list of all drives and in the right most column, you will need to identify what the Identifier Name is for your volume. Once you have that, run the second command and substitue the IDENTIFIER_NAME with the correct Identifier Name for your volume.
/System/Library/Filesystems/hfs.fs/hfs.util -N /dev/IDENTIFIER_NAME
If it successful, this will mark the disk as no longer Journal, so you can now shutdown the Firewire drive and then unplug it. Wait a minute or so and then start it back up and plug it back into the Macintosh and then you should be able to see the drive mount again.
This allowed me to mount the drive again, but I believe there is still a problem with this drive, so my recommendation was to backyp the drive right away and then reformat it and exchange it for a new drive. I am not sure if the problems with the 1.5TB Seagate drives in RAID configuration apply to other Seagate drives as this one was a 1TB drive, but you never know.