Finder slow at listing directory content from SMB shares

Question

Level 1

0 points

Finder slow at listing directory content from SMB shares

I'm connecting to SMB shares on an Windows 2003 Server from a MBP running 10.6.1 and face two issues doing that.

1) Finder is slow at listing the directory content of the shares
The problem only occurs in Apple Finder. When I do "ls" from Terminal the directory listing displays in the same moment I hit enter.
The problem also does not occur when using PathFinder from Cocoatech.

2) Reconnecting to the SMB Server fails (sometimes)
It almost always fails when I unplug the ethernet cable and plug it back in. Finder then complains it couldn't find the server by name or the IP address would be wrong.
Both options are not true. DNS is present and working. Connecting by IP only also fails with the same error message.

Anybody seing this also?

I've tried to "optimize" by changing smb.conf but without success.

MBP, Mac OS X (10.6.1)

Posted on Sep 22, 2009 12:20 PM

Reply

Answer 1

Aug 1, 2010 1:27 PM in response to Jola@edyn

I use 6 Macs of various configs on a Windows 2003 SBS server. This problem only appeared in OS X 10.6. My OS 10.5 and 10.4 gear lists SMB shares instantly over the LAN and yet 10.6 takes in excess of 3 minutes for an average SMB share.

Does anyone know if Apple plan to fix this ever ??

JK

Reply

Answer 2

Sep 22, 2009 8:15 PM in response to Jola@edyn

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.

Reply

Answer 3

Jola@edyn Author

Level 1

0 points

Sep 23, 2009 4:23 AM in response to Paul Scott`

yes, it's an issue for some time now 😉
I hoped id would have been fixed in the New Finder of 10.6...

I actually have the impression that performance of the Finder in terms of SMB is worse than in 10.5.
Again: it's not the OS is just the Finder app.
I hope that Apple is listening...

Reply

Answer 4

Oct 2, 2009 8:55 AM in response to Jola@edyn

I've had the same issue. Fixed with information in this thread:

http://discussions.apple.com/thread.jspa?threadID=2134936&tstart=45

(setting OpenDNS have fixed my problem)

Regards

Reply

Answer 5

Oct 2, 2009 3:52 PM in response to fersoft2009

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.

Reply

Answer 6

Oct 3, 2009 5:55 AM in response to Paul Scott`

I know that seems to be a weird solution. I have also tried using an IP address to avoid any DNS issue but the problem persist. Only when I've set a OpenDNS server, it was possible list the file in the folder almost instantly.

May be you have another different problem.

Reply

Answer 7

Jola@edyn Author

Level 1

0 points

Oct 6, 2009 12:57 AM in response to fersoft2009

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:
http://discussions.apple.com/thread.jspa?threadID=2134936&tstart=45

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.
It's:
#!/bin/sh
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 🙂

Reply

Answer 8

Oct 6, 2009 1:26 AM in response to Jola@edyn

take a look:

http://kb2.adobe.com/cps/506/cpsid_50654.html

Reply

Answer 9

Jola@edyn Author

Level 1

0 points

Nov 18, 2009 2:14 PM in response to Jola@edyn

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.

Reply

Answer 10

nolamike

Level 1

29 points

Dec 29, 2009 11:42 AM in response to Jola@edyn

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

Reply

Answer 11

Jola@edyn Author

Level 1

0 points

Jan 24, 2010 2:25 AM in response to Jola@edyn

The reconnecting issue actually seems to be a keychain problem.
Connecting to SMB shares only fails for those shares where I stored the password in the keychain. It never fails for other shares.
This is reproducable for me.

Reply

Answer 12

Feb 8, 2010 3:07 PM in response to Jola@edyn

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:
208.67.222.222, 208.67.220.220

Reply

Answer 13

Feb 9, 2010 9:21 AM in response to Jay Larsen

I take it back - today it is behaving the same (long time to list directory contents) as before the OpenDNS change. So the OpenDNS settings did not fix my issue.

Reply

Answer 14

nolamike

Level 1

29 points

Feb 22, 2010 12:34 PM in response to nolamike

We are going to abandon the Solaris kernel-based SMB on our fileserver, go back to SAMBA under Ubuntu (not because of this issue, but this did not help). I'll let the forum know how it goes.

Reply

Answer 15

nolamike

Level 1

29 points

Feb 24, 2010 10:20 AM in response to nolamike

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.

Mike

Reply