AFP/SMB Directory Listings very slow in Finder

-Kephster- Thank you!

Excluding the network shares in Spotlight AND updating Synology NAS to latest Version 4.3-3810 Update 4 has done the trick => speed is back! (btw. Synology NAS had not mentioned that there is a "new" update! Had to click "search for updates" by myself to get the Info that there is more than just 4.3-3810 out there!)

The following settings seemed to have fixed my issues:

System Preferences -> Network -> USB Ethernet -> Advanced... -> Hardware -> Configure: Manually -> MTU Custom: 1320

Disconnect from server and re-establish connection

Changing MTU is not the best idea, this is quite old problem. Usually performance is miserable especially on WAN / VPN Links when accessing 3rd party servers. In our case, we could get full performance from OSX Server but Solaris machine with netatalk was miserable.

To solve the problem, run following on your OSX client machine:

sudo sysctl -w net.inet.tcp.delayed_ack=2

No need to reboot, this should become active immediately. Check your performance, if it became better, make this change permanent / survive reboot by putting

net.inet.tcp.delayed_ack=2

into /etc/sysctl.conf file. (You might need to create it)

Thanks, -Kephster-, that really did help. One thing I noticed is that other users were creating these files, which caused my browsing to be slower. So I did the folling two things:

1) I ran the defaults write com.apple.desktopservices DSDontWriteNetworkStores true command on all Macs that connected to the share.

2) I ran the command find /Volumes/[Volume Name] -name .DS_Store -exec rm {} \; replacing [Volume Name] with my share name (e.g. find /Volumes/ProjectB\ Shared\ Files -name .DS_Store -exec rm {} \;).

Browsing is ridiculously faster for all users now, and quite usable. It is nowhere near as fast as FTP or just an ls in the command line, but at least it's usable.

Despite the changes in MTU and protocol adjustments from SMB2 to 1 (smb to cifs in the url for mounting), to me this seems like a Finder issue more than than a protocol issue. That fact that a directory listing in a terminal is lightning fast, as are alternate file browsers, seem to support that.

BTW, I tried AFP as well, despite Apple moving away from that. I found that while browsing in the Finder was faster, my logs were filling up with errors and file transfers were less than half the speed, all the while connected to an Airport Extreme with a hard drive hanging off of it (so Apple to Apple).

Did anyone find that the 10.9.2 update helped browsing? I have one client who it seems to have fixed slow performance, while another who says no it didn't do anything and is still slow.

10.9.2 did not help. I just did a side by side comparison between 10.9.2 and 10.8.5 and 10.8.5 was significantly faster.

Apple had to rush out 10.9.2 for the SSL bug ;(

Waiting for 10.9.2.1 or 10.9.3 ;(

All these "fixes" do not work for me. I run an Microsoft Windows 2012 R2 Server in my local gigabit network. All clients use static IP's. But if I try to access a admin windows share from OS X 10.9.2 it lasts 30 minutes until the finder window is listing the directories and files. This is more a downgrade from 10.9.1 to 10.9.2 than an improvement.

surogat70,

One thing I had to so in a multi-user environment was make the changes to all machines that connect to the volume and then remove the .DS_Store files. Have you tried that? The improvement for me was really dramatic.

Your experience may vary, but I see online your Windows server also supports Appletalk. You might want to giver that a try. 10.9.2 broke AFP for me, so I switched over to mounting everything as SMB. Specifically, 10.9.2. floods my logs (even when connected to other Macs) with:

3/2/14 8:37:33.000 AM kernel[0]: AFP_VFS afpfs_vnop_getxattr: bad dataLength offset 2 replySize 2

3/2/14 8:37:33.000 AM kernel[0]: AFP_VFS afpfs_vnop_getxattr: bad dataLength offset 2 replySize 2

3/2/14 8:37:33.000 AM kernel[0]: AFP_VFS afpfs_vnop_getxattr: bad dataLength offset 2 replySize 2

I can get scrolling screens of these per second. The fans come on and it's so bad that I seriously doubt anyone at Apple actually tried mounting any AFP volumes before shipping. Or actually Samba for that matter.

Yes, I have done this already. There is not difference. I get constantly following messages in my system log:

02.03.14 17:11:35,000 kernel[0]: smb_fid_get_kernel_fid: No smb2 fid found for fid 864195d8b0de08f6

02.03.14 17:11:35,000 kernel[0]: smb_iod_reconnect: Reconnected share Edata$ with server server1

This seems to be the code behind this error:

if (found_it == 1) {

/*SMBERROR("fid %llx -> smb2 fid %llx %llx\n",

fid,

smb2_fid->fid_persistent,

smb2_fid->fid_volatile);*/

error = 0;

}

else {

SMBERROR("No smb2 fid found for fid %llx\n", fid);

}

Cthulhu,

Could you describe what changes you made? I'm pretty dang curious!

What change did you do to each machine, and did you just manually delete all the dsstore files?

Cthulhu wrote:

One thing I had to so in a multi-user environment was make the changes to all machines that connect to the volume and then remove the .DS_Store files. Have you tried that? The improvement for me was really dramatic.

osinkboy,

1) First, I ejected the offending volumes on each Mac manually.

2) As long as I was on each Mac anyway, I ran the following command on every Mac:

defaults write com.apple.desktopservices DSDontWriteNetworkStores true

For good measure, I went ahead and restarted the Macs.

3) I then shut off Samba on the file server (in my case a Linux server) using:

sudo stop nmbd sudo stop smb

Your command may be a little different.

3) Next, on the server I ran a command to remove all the .DS_Store files from all the directories accessed over Samba/CIFS. So, for example, if everyone sees a volume "Corporate Files" that starts at /srv/files/corporate on your actual server, you would do:

sudo find /srv/files/corporate -name .DS_Store -exec rm {} \;

If your file server is not Linux or Unix, you can run this from any Mac's terminal:

find /Volumes/Corporate\ Files -name .DS_Store -exec rm {} \;

Adjust the directories as needed. Mind you, if you run this command as a single user from the Mac, you may have permission problems, so be sure to check the terminal output for any errors.

4) With your .DS_Store files gone, and the preference to create them disabled, they should not bother you again.

Keep in mind while this made it better for the Finder, it did not make it perfect. My Windows and Linux shares are still able to browse at at least double the speed, but oddly enough, if I use the terminal on the Mac to copy files or ls directories, the Mac is the fastest by far. So this is some sort of Finder problem, and I would not bother tuning the network or any making any more advanced changes, because I doubt they will really help.

It also seemed to take a bit of time to cache up the diectory on the server, so the first time I went to a folder, it was as slow as always, but the next time, even of files have changed, it was much faster.

Good luck - let me know how it works out for you.

I found something which has dramaticaly speeded up my network. Try to turn off IPv6 on all sides, especially if your shares run under Windows. I switched it off in the ethernet adapter preferencies. It boosted up all shares under Finder as well as VPN. Tested on Maverics, disks shared from Windows 7 through CIFS.

@Kephster: Thank you very much!

Mavericks 10.9.2 here with the same problem: very slow directory listing on AFP share (OpenIndiana FileServer, no VPN; PCs and Macs with older OS could access AFP/SMB share without any speed problem). 10.9.2 over 10.9.1 didn't bring any improvments, but Kephster fix with network share exclusion under Spotlight brought the speed back. I did't apply any of other fixes, since I'm happy with that. Thanks Kepshter, Apple should pay you big time!

I went through a bunch of the steps in this thread with no luck.

Ended up forcing the Macs to use SMB1 until this is fixed by Apple:

echo "[default]" >> ~/Library/Preferences/nsmb.conf; echo "smb_neg=smb1_only" >> ~/Library/Preferences/nsmb.conf

That's all one line and it fixed the issue for use instantly. No reboot required.