Mac Thread, Mac OSX 10.6.7 slow to read smb file shares in Technical; We have integrated a hundred Macs into our network. When ever a Mac tries to read a directory on a ...
We have integrated a hundred Macs into our network. When ever a Mac tries to read a directory on a Windows 2003 R2 file share or Windows 2008, it takes an inordinate amount of time. Even listing a simple sub-directory with just 3 1K files in it can take upwards of a minute.
Now we installed an afp file share and speed is dramatically faster under exact same testing conditions.
But of course we are a Windows and Linux shop running AD. And even if we bought three or four Mac Pros and set up afp file shares, we'd have no way to manage them.
This problem of slow smb directory and file listing is driving us crazy. We have tested for months, replaced a core switch, tested and replaced cables, new N AP. All work perfectly with Windows client. No delays etc. Even simultaneously with Macs and Windows laptops, Windows machines are fine.
I had this exact situation and switched to using AFP shares on a Mac Pro a few weeks ago as the situation got so bad. If you search online for issues there are tens of different things you can try adjusting. A few of the top of my head:
Tweak TCP/IP stack settings to modify delayed_ack value from 3 to 0 or 1 (this stops delayed transmission of packets to piggyback data and use less packets, try 0 for wireless clients and 1 for wired)
Tweak TCP/IP stack settings to modify newreno value from 0 to 1 (this turns on a enhanced algorithm which came make a difference of some wireless networks)
Check reverse DNS (this was definitely causing us some problems but I only sorted this after the switch to AFP, the Apple AD and Centrify Direct Control will, by default, send dynamic DNS updates which were clashing with the updates provided by the DHCP server).
Make sure everything is set to use NTP so kerberos tickets will remain consistently valid.
Disable spotlight indexing (home folders will get indexed as you log in which can cause performance issues).
Disable Bonjour advertisements (On 10.6 don't disable Bonjour as it also now handles the unicast DNS as well, just stop advertisements)
I think it's likely that if reverse DNS isn't perfect then the system will fallback to using mDNS lookups through Bonjour and this will introduce the delay although I've yet to re-test. My situation sounds identical to yours though, no apparently bottlenecks or problems with any of computers, but Apple systems were slow in accessing it (and unstable because of it).
Interesting Apple are using their own SMB client in 10.7 instead of SAMBA components so this may rectify any issues or potentially make it all worse. I'm currently trying to get Kerberos working with Netatalk so we can store the shares on Linux on actual server hardware and have something that can actually scale, still playing with it at the moment though but the speed is good.
We had this problem too, and found that 10.6.7 is honoring IPTOS. Try setting IPTOS_LOWDELAY for a socket option on the samba server -- this solved our problem
I went through everything list on that page and still couldn't get it to work properly, the fileserver I was using was 2008R2 though so maybe some fixes only apply to older Windows products or Samba shares.
I've read somewhere that Windows 7 uses a newer version of cifs/smb for their file sharing. Apple have decided to build their own smb client to access these shares as SAMBA doesn't work properly with this newer type. How true it is I don't know. I'll see if I can find a link to it.
Not sure how much use this pdf guide is to anyone but something I put together a while back in my previous position to disable smb signing on windows 7
I assume that Windows Server 2008 uses the newer MS SMB2
Windows 6.0 (Vista/2008) supports SMB 2.0, while Windows 6.1 (7/2008 R2) support SMB 2.1. Both are a huge improvement over the original SMB in terms of performance.
LinkBack URL
About LinkBacks
Reply With Quote
Originally Posted by HodgeHi 
