This is a longshot, because this issue seems over-reported and unanswered on the internet (see references below), but it is about time this issue is permanently solved.

The facts:

  • Server: Windows Server 2008, acting as a file server
  • Client: OS X Lion 10.7.3.
  • Method of connecting: directly via IP through Finder: smb://

The problem:

  • The initial connection attempt takes about a minute.
  • After the connection is made, it takes one more minute to show the directories in Finder.
  • After navigating to any other directory, it takes several seconds/minutes to parse the directory, seemingly based on the size of the contents.
  • Actually, my entire Finder has this problem after connecting. When using Finder to show my desktop, it can literally take up to a minute to load.

Obviously, this is not right. I have no clue how to fix this and would appreciate any help I can get. I am unsure about other relevant information I can provide, but if there is any, please let me know so I can update the post.

I seem to be not the only one having this problem:

  • Samba is not used at any point in this setup.
    – Sven
    Feb 23 '12 at 17:18
  • @SvenW my bad, mistakenly assumed smb==samba, but obviously wrong :) Feb 23 '12 at 21:09
  • 1
    What happens if you use cifs:// in stead of smb:// ? For a clean test: Disconnect the existing smb:// connections, reboot the and then try with cifs://
    – Tonny
    Nov 10 '12 at 10:18
  • I had this problem too, but I never found a solution and I no longer use a Mac for work. Short of doing a network trace and dissecting the conversation, I'm not sure what would reveal the solution.
    – john
    Jul 21 '13 at 6:53

I would not be surprised if this is an incompatibility problem related to the newer SMB2 protocol which debuted in Windows Vista (and the original Windows Server 2008). If you can get your hands on a Windows 2000/XP machine and test the Mac's performance when accessing a share on the 2000/XP host, you'll find out if it's an SMB2-related problem, since XP and below didn't have SMB2 and the introduction of the SMB2 protocol is notorious for having caused similar problems, specifically related to "fast queries." If an XP or below system doesn't exhibit the same file sharing issues with your Mac, and you have admin rights on the server or can talk to someone who does, a .reg file which will turn off the fast queries behavior on the server (and any Vista or above system, remember that WS2008 is effectively "Windows Vista server edition") is as follows:

Windows Registry Editor Version 5.00


Also see the tips on this page for additional suggestions that are specific to this problem with Snow Leopard (and probably newer OS X versions also): http://www.macwindows.com/snowleopard-filesharing.html#030311b

One other possibility is that the network's DNS server is returning the wrong IP address for the name of the server, or that you are using an incorrect DNS server when on this network. If this is a domain, the Windows Server should be used as the primary DNS server. If the DNS server settings in use go to the ISP's DNS servers or a router, and the ISP DNS has standards-noncompliant "typo correction" or "search suggestions" features on by default which redirects non-existent domain names to an ISP search page rather than returning the (correct) NXDOMAIN response, attempts to reach the server by its name will misbehave a lot. Try using the IP address of the server instead of its NetBIOS name to see if a misconfigured or misbehaving DNS situation is causing the problem. For more information about the ISP DNS issue, see: https://en.wikipedia.org/wiki/DNS_hijacking#Manipulation_by_ISPs


Setting these two registry keys helped me drastically improve windows share performance for Macs on Windows Server 2012 and Windows 8.1


Windows Registry Editor Version 5.00


From the MSDN description:

Smb2CreditsMin and Smb2CreditsMax HKLM\System\CurrentControlSet\Services\LanmanServer\Parameters \ (REG_DWORD)

The defaults are 64 and 1024, respectively. These parameters allow the server to throttle client operation concurrency dynamically within the specified boundaries. Some clients might achieve higher throughput with higher concurrency limits. One example is file copy over high-bandwidth, high-latency links.

Altering the values from the default 64/1024 to 768/16384 helps the OS X considerably.

  • This would be a much better answer if it explained what this does and how it solves the problem. Oct 4 '14 at 14:12
  • Added as much info as I know for now.
    – Vedran
    Oct 4 '14 at 15:05

I have a gut feeling that it has something to do with recent changes in their SAMBA implementation. I was struggling with Linux shared printer with Lion 10.7.3. Turned out, apple switched to their own implementation of samba in Lion, which doesn't like using Bonjour advertised services on port 139 instead preferring 445 and I had my SAMBA server started only on 139.

Please consult following URL, i think you will find something that answers your issue

  • this problem is happening to me since Snow Leopard, sadly. Feb 24 '12 at 19:52
  • URL i mentioned have all the things related to Snow Leopard. Have you checked it brother ?
    – kaji
    Feb 25 '12 at 2:45
  • yes, I have and it does not apply to Lion or fix the issue. Thanks for the answer though, I appreciate the fact that you at least responded :) Feb 25 '12 at 8:14

I had that problem on Snow Leopard. Is your Mac connecting to the share using airport ? Try with Ethernet. Also, disable IPv6 (enabled by default on OSX 10.7).

  • 1
    I am not connecting via airport, and the problem persists with ethernet and IPv6 off. Apr 13 '12 at 7:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.