AFP/SMB Directory Listings very slow in Finder

We have a Xserve with 10.6.8 server installed on it. Users are connecting to our AFP server trough VPN.

Same issues , so i does affect shares on macservers.

This problem needs to be addressed as a matter of urgency. Not only is it affecting my client's network but it's affecting access to my own NAS.

This is fundamental stuff and being able to connect to network shares is absolutely essential in business and whilst it's broken, I am looking at server alternatives.

The server product is cr*p so I've left it at version 10.6. Now the client is broken. If Apple do not fix this soon then there are going to be a lot of very unhappy customers and I am one of them.

Strange thing is, I have more success with Windows 7 connecting to a Mac share over SMB than I do with a Mac. Go figure.

How to destroy your entire corporate market by not testing the basics. Microsoft is bad enough but this is not something I expect from Apple. I may have to recommend putting in a Windoze server and that's sacriledge in my eyes. Although their more recent server software *****.

Thsi issue gardually came back over a period of time and it was VERY annoying.

I've just upgraded tp 10.9.1 and viewing and accesing large files (PSD etc.) over AFP to a Mac server running 10.5.8 use to be very slow to preview and and load file directories via finder (simple stuff) in my 10.9.1 finder window. Browsing and importing images across the network to an InDesign document also took an age - it's all pole opposite now - quick to load and fluid - much as it was prior to Mavericks.

Apple clealry knew the issue and this update has rectified - well for me anyway. Anyone else?

No, I've upgraded and the problem still exists. Have connected through SMB and AFP and get the spinning 'clock' in the bottom right of the window.

It's appalling. Any upgrade to Mavericks is going to destroy realistic network connectivity. It's totally unacceptable. I'd rather pay for an OS upgrade than suffer this incompetence.

same here - no improvement...

I tried the -KEPHSTER- fix and directory listing is noticably better.

I'm running 10.9.1 and trying to connect to my Synology over AFP and SMB2. I had the same directory slowness regardless of whether I was using wireless 802.11AC or wired GbE.

Directory listing has improved from >5 minutes for a 5,000 object directory to ~30 seconds and about 90 seconds for a 15,000 object directory. Still bad, but now in the realm of majorly annoying vs. useless.

A second issue I've seen is a long delay before starting a copy operation. This can also sometimes be multiple minutes while the dialog shows "Preparing to copy..." The KEPHSTER fix does not appear to have corrected this problem. Have other people experienced this as well?

Has Apple responded to this thread in any way?

Leoinspace - have you made a test with 'Path Finder' - that I was recommending in my previous post?

I have completed the Kephster fix - no disceernible change but left in place.

I've installed Pathfinder - no change to the directory listing.

Network shares are unusable. I've ended up copying the files I need onto a 3TB HD connected locally in order to workaround this problem until Apple comes up with a decent fix for this issue.

I've also tried all the different protocols to connect.

I had similar issue with SMB and AFP connections being slow.

I tried a suggestion from anoher forum.

Turning on "Internet Sharing" from:

System preferences -> Sharing -> Internet Sharing.

This causing my connection not to work as I had set "Share your connection from" as Ethernet.

I then turned off Internet Sharing and went back and re-created the share and now everything is very fast connecting.

might just be a fluke?

Hi all,

I've been experiencing the same very slow browsing of our file server over VPN using the AFP protocol since upgrading to 10.9. The browsing is so slow that working remotely is not possible. Until, that is, I installed Path Finder. I did so after:

• reading this and many similar threads
• my IT team could not figure out a solution (except to move our company over to a cloud-based system like Egnyte)
• I noticed an app on my iPad, File Browser, was able to access our file server through a VPN connection and browse 1,000 times faster than my MBP.

So, I thought maybe a different filebrowser other than Finder would solve the issue. So far, Path Finder has resolved my browsing slowness and I can now work remotely. I'm sure there are many other alternative file browsers out there that will resolve this issue. Maybe others will try them out and report here.

By the way, I did not attempt the Kephster fix.

Hello,

I am experiencing a delay of 10 - 15 sec browsing my directory directly on my MBAir (mid-2012) NOT over a network. If I want to attach a document to a mail or do a <print >> save as pdf> of a safari page the machine takes 10-15 sec to display the subfolders of a particular folder in my directory.

Also another issue is that when I address a mail to a group (110 members) and then write the mail as I am composing I spend a lot of time waiting for the beachball to stop spinning rather than actually writing the mail. If I write the mail first and then address it to the group, the composing goes okay,. However, in both cases the machine takes a much longer time than in 10.8 (whatever bloody cat that was) to actually send the mail.

What is going on? are these Mavericks features? Do I have a corrupted copy of Mavericks (directly installed by my local physical Apple Store)?

Thank you for any thoughts/solutions.

Best wishes,

Richard

-KEPHSTER Fix imoved the direcory listing a little bit.

-Within Path Finder i can't detect any delays in folder listing. so for me it works as a workaround.

But Finder still should be fixed!

Grrr.

This may not be the exact right thread to be asking this in but we have the same slowness connecting to a coud-hosted Win 2008 Server from our Macs over VPN. It was wlays pretty slow on the Macs but has become unbearable after Mavericks. It;s not the network as connecting to same server from Parallels running on one of the Macs over same VPN is lightening fast. Also, on the Macs, RDC into ternminal sevices sessions on the Server for QuickBooks works as if the QuickBooks was on the local machines. It's super fast! Only thing taht is slow is connecting to and browsing the file structure in Finder and open/save dialog boxes. Has anyone with a similar setup seen this solution fix the issue for you?

http://www.grouplogic.com/enterprise-file-sharing/mac-windows-file-sharing/

NAS 1513+

- Two RAID1 volmes, 1 plain disk.

- DSM 4.3-3810 U4

- LACP on 2 1GB ports

2009 Mac Pro

- 2.66Ghz, 32GB RAM, SSD boot drive (1TB)

- LACP on 2 1GB ports

- Mount the RAID1 volumes via AFP

- Mount the 1 plain disk via AFP for time capsule.

No updates are currently available for either.

Since upgrading to 10.9, like others I at times get HORRIBLE network attached storage performance, but it is not constant, nor have I found the trigger for it. I have symptoms on both SMB2 -OR- AFP links, not just one or the other. Sometimes I can remedy it by merely booting mounted user from the Synology control panel and then reconnecting to the volume.

Here is an example, copying a 3.85GB file from local disk (SSD) to an AFP NAS volume...it basically was lagging my user interface, but this seems to be because finder/launcherd has some thread blocking issues when the network seems to hiccup.

Traceroute ping against the NAS unit from the MAC, you can see when I attempted to start to copy the file. For note, MAC is 192.168.1.2, NAS is 192.168.1.5, this is a 1024-byte ping:

1032 bytes from 192.168.1.5: icmp_seq=88 ttl=64 time=0.317 ms

1032 bytes from 192.168.1.5: icmp_seq=89 ttl=64 time=0.300 ms

1032 bytes from 192.168.1.5: icmp_seq=90 ttl=64 time=0.368 ms

1032 bytes from 192.168.1.5: icmp_seq=91 ttl=64 time=0.351 ms

1032 bytes from 192.168.1.5: icmp_seq=92 ttl=64 time=0.290 ms

1032 bytes from 192.168.1.5: icmp_seq=93 ttl=64 time=589.964 ms

1032 bytes from 192.168.1.5: icmp_seq=94 ttl=64 time=206.975 ms

1032 bytes from 192.168.1.5: icmp_seq=95 ttl=64 time=325.690 ms

1032 bytes from 192.168.1.5: icmp_seq=96 ttl=64 time=146.775 ms

1032 bytes from 192.168.1.5: icmp_seq=97 ttl=64 time=630.380 ms

1032 bytes from 192.168.1.5: icmp_seq=98 ttl=64 time=2325.074 ms

1032 bytes from 192.168.1.5: icmp_seq=99 ttl=64 time=1323.902 ms

1032 bytes from 192.168.1.5: icmp_seq=100 ttl=64 time=323.091 ms

1032 bytes from 192.168.1.5: icmp_seq=101 ttl=64 time=69.879 ms

1032 bytes from 192.168.1.5: icmp_seq=102 ttl=64 time=190.796 ms

1032 bytes from 192.168.1.5: icmp_seq=103 ttl=64 time=712.165 ms

1032 bytes from 192.168.1.5: icmp_seq=104 ttl=64 time=3.779 ms

1032 bytes from 192.168.1.5: icmp_seq=105 ttl=64 time=229.078 ms

1032 bytes from 192.168.1.5: icmp_seq=106 ttl=64 time=1037.666 ms

I kicked off the mounted user through the interface I had open (once I could get it open, the first to connects timed out) via Firefox on the Synology. I then remounted the volume and copied the same file and it worked fine and fast, here you can see the ping go from .3 to 2.X or so during the copy:

1032 bytes from 192.168.1.5: icmp_seq=0 ttl=64 time=0.312 ms

1032 bytes from 192.168.1.5: icmp_seq=1 ttl=64 time=9.421 ms

1032 bytes from 192.168.1.5: icmp_seq=2 ttl=64 time=0.272 ms

1032 bytes from 192.168.1.5: icmp_seq=3 ttl=64 time=0.293 ms

1032 bytes from 192.168.1.5: icmp_seq=4 ttl=64 time=0.266 ms

1032 bytes from 192.168.1.5: icmp_seq=5 ttl=64 time=2.626 ms

1032 bytes from 192.168.1.5: icmp_seq=6 ttl=64 time=17.977 ms

1032 bytes from 192.168.1.5: icmp_seq=7 ttl=64 time=5.908 ms

1032 bytes from 192.168.1.5: icmp_seq=8 ttl=64 time=2.226 ms

1032 bytes from 192.168.1.5: icmp_seq=9 ttl=64 time=2.511 ms

1032 bytes from 192.168.1.5: icmp_seq=10 ttl=64 time=0.347 ms

1032 bytes from 192.168.1.5: icmp_seq=11 ttl=64 time=0.336 ms

1032 bytes from 192.168.1.5: icmp_seq=12 ttl=64 time=0.297 ms

1032 bytes from 192.168.1.5: icmp_seq=13 ttl=64 time=0.680 ms

1032 bytes from 192.168.1.5: icmp_seq=14 ttl=64 time=2.641 ms

1032 bytes from 192.168.1.5: icmp_seq=15 ttl=64 time=0.347 ms

1032 bytes from 192.168.1.5: icmp_seq=16 ttl=64 time=2.576 ms

Something gets very broken and starts blocking on the network stack. Whatever breaks in the connected volume does NOT fix itself without disconnected the user and reconnecting the volume. During this time, I was able to ping my router from the MAC with no issues.

--- 192.168.1.5 ping statistics ---

30 packets transmitted, 29 packets received, 3.3% packet loss

round-trip min/avg/max/stddev = 14.590/456.075/1846.661/463.270 ms

Tron:~ daniel$ ping -s 1024 192.168.1.1

PING 192.168.1.1 (192.168.1.1): 1024 data bytes

1032 bytes from 192.168.1.1: icmp_seq=0 ttl=64 time=0.720 ms

1032 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=0.632 ms

1032 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=0.630 ms

1032 bytes from 192.168.1.1: icmp_seq=3 ttl=64 time=0.602 ms

1032 bytes from 192.168.1.1: icmp_seq=4 ttl=64 time=0.588 ms

1032 bytes from 192.168.1.1: icmp_seq=5 ttl=64 time=0.571 ms

Recently got significant improvements regarding response times for (network shared) directory listings using AFP.

The actual problem at hand seems to depend on a faulty implementation of Spotlight search-reuse in OSX Finder.

Try excluding an entire network share under the Privacy settings of Spotlight in OSX System preferences ... =)