I am having the same problem. This has been an issue on 10.5 and 10.6. I have had clients complain when I open WIndows the file just appear. When I use the Mac shares it takes 1:30 seconds to 2 minutes to show ~400 folders.
I have so far tried adding
socket options = TCP_NODELAY IPTOS_LOWDELAY
to smb.conf in the [global] section
Setting TCP ack delay to 0
sudo sysctl -w net.inet.tcp.delayed_ack=0
So far nothing has worked. It continues to be painfully slow. Once I access them once they are fine. But I have to go through this every time I connect to the share.
The issue is a little different. These are only a problem when connecting to a SMB share not an AFP share. I have also tried this using the IP address as the mount point to eliminate DNS as a possible issue.
The connection happens fast. It just takes a long time to enumerate the files so they can be displayed. This happens almost instantly on Windows machines.
Using OpenDNS is not an option for me for one reason alone: I need to use our internal Nameserver in order to resolve internal IP-Addresses.
The solution under:
claims the issue is due to a reverse lookup bug in Windows DNS-Server.
To me that sound's a bit unlikely since half of mankind would then suffer from this issue...but still possible
I tried to put the IP Address of the SMB server (which also is the Active Directory Server) into /private/etc/hosts.
This alone did not help. I then realized with help of Google that OS X would not consult /privat/etc/hosts ( == /etc/hosts) by default when using DHCP.
I was under the assumption that /etc/hosts would always the evaluated in first place.
This made me look at /etc/resolv.conf. And I added "order hosts, bind" to it. Unfortunately I can't really tell if that is a supported directive by OS X. The resolv.conf man page is not explicit about it.
Since I'm using DHCP the file resolv.conf is updated by the OS whenever I change network config. And I do change it a lot...
I've written a quick sh script that I can call to add the order directive to the file.
mv /var/run/resolv.conf /etc/resolv.conf.new
echo order hosts, bind > /var/run/resolv.conf
cat /etc/resolv.conf.new >> /etc/resolv.conf
While is can only be considered a dirty hack, I'm not sure it's the real solution to the problem.
After making the change connection seems to work better on the LAN. There are still situations though when fetching the directory content is very slow from Finder.
The hack is not an option at all when I'm on a VPN connection. I assume that this is due to the fact that /etc/resolv.conf might not be used for the VPN connection.
I'm counting on 10.6.2
The issues has improved in 10.6.2 but it's not gone.
Directory Listing is still slow - at least sometimes. "Sometimes" means there seems to be some sort of caching. When the directory listing is loaded once and the folder is read again in the same session then the content is displayed fast. Not sure what determines the session here.
It's also pretty slow on VPN connections.
Just a note of continued suffering under this issue. Kernel-based SMB on a Solaris-based fileserver. Maybe 10 seconds to open any sub-folder after a fresh mount. Subsequent openings of the same folder during the same mount are fast. Listing sub-directories via Terminal is always real fast.
On a lark I tried changing to Google's public DNS service. No difference. Tried playing with .DS_Store files (deleting & creating fresh with 10.6.2). No effect.
Tried connecting with a numerical IP address. No effect.
Oh, the pain of it all...
Message was edited by: nolamike
Message was edited by: nolamike
I could connect just fine to SMB shares, but the first time listing of any directory would take 10-20 seconds.
Based upon the suggestions here I added the OpenDNS DNS servers to my network settings and now everything works fine (as it did in Leopard).
The OpenDNS server settings I used were:
OK. Just finished 10 minutes of testing on the reconfigured server. Delay is GONE. The new server is running Ubuntu 9.10 and Samba 3.4.0 in a default configuration. The old server with the problem was running Solaris with ZFS and the kernel-based SMB service.
So, folks that continue to have the problem might want to try upgrading SAMBA or whatever they are using for SMB software.