TenjuZenjin

Q: AFP/SMB Directory Listings very slow in Finder

Hello comunity!

 

Since the upgrade to OS X Mavericks we are experiencing server problems, browsing AFP/SMB shares on remote servers (VPN). The Directory Listing is very slow an can take up to 30 minutes for large listings.

 

Here's the setup

 

  • 2 networks are connected thanks to a VPN connection.
  • All clients, in all connected networks can communicate to a common fileserver (MacPro with OS X 10.6 SnowLeopard Server) in Network A
  • Firewall is not an issue between those networks
  • The fileserver also has other network services set up (DNS, Mailserver, SMB, AFP, Firewall, ...)
  • The clients authenticate via OpenDirectory and Kerberos to the fileserver

 

So the problems occur if i want to connect a client on network B to the server on network A. Connection, authentication, ... all good. Even the performance over the VPN, to tranfer files is OK. But browsing subfolders is catastrophic. I used AFP and SMB alike, results are the same.

 

I also made tests on older clients, to see if the fileserver is the problem. 10.6 and 10.8 clients can browse normally, speed is OK. Even Windows Clients can browse normally all the subfolders of the fileserver.

 

I analyzed different approaches made here, but none of them worked:

  • Connect to share with explicit port
  • Connect to share with FQDN
  • Connect to share with port 445 (SMB)
  • Setup an nsmb.conf with notify_off=yes
  • ...

 

I also did analyze different logs and there's something i found, but can not say if it's connected. I did see many log entries like this:

...

29.10.13 12:21:51,960 icbaccountsd[775]: -[ICBLocalDictionary writeLocalMapping:]: Status: Writing out local mapping to disk

29.10.13 12:21:51,960 icbaccountsd[775]: -[ICBLocalDictionary writeLocalMapping:]: Status: Ending writing out local mapping to disk

29.10.13 12:21:51,960 icbaccountsd[775]: -[ICBRemoteDictionary writeDevices]: Status: Writing out of devices

29.10.13 12:21:51,960 icbaccountsd[775]: -[ICBRemoteDictionary writeDevices]: Status: Ending writing out of device

...

 

I also saw tha a process "icbaccountsd" was often coming up an using all of my CPU, when i start browsing the share. Thus i could not find any documentation on it.

 

So my question: What can I do to accelerate the browsing of my AFP/SMB shares for all my Mavericks clients? What can I do to speed up the Directory Listing? And yes: i know about solutions like PathFinder, TotalFinder, .... but i'm more interested in a native solution to this problem.

 

Thx!!

OS X Mavericks (10.9), 10.6.8 Server

Posted on Oct 29, 2013 4:33 AM

Close

Q: AFP/SMB Directory Listings very slow in Finder

  • All replies
  • Helpful answers

first Previous Page 3 of 12 last Next
  • by leoinspace,

    leoinspace leoinspace Jan 3, 2014 11:00 PM in response to jynk
    Level 1 (4 points)
    iLife
    Jan 3, 2014 11:00 PM in response to jynk

    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?

  • by kakalaka,

    kakalaka kakalaka Jan 4, 2014 1:36 AM in response to leoinspace
    Level 1 (0 points)
    Jan 4, 2014 1:36 AM in response to leoinspace

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

  • by eurisko67,

    eurisko67 eurisko67 Jan 4, 2014 5:13 AM in response to TenjuZenjin
    Level 1 (0 points)
    Jan 4, 2014 5:13 AM in response to TenjuZenjin

    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.

  • by red_star,

    red_star red_star Jan 7, 2014 7:30 AM in response to TenjuZenjin
    Level 1 (0 points)
    Jan 7, 2014 7:30 AM in response to TenjuZenjin

    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?

  • by lorenz1111111111111,

    lorenz1111111111111 lorenz1111111111111 Jan 8, 2014 5:31 AM in response to TenjuZenjin
    Level 1 (0 points)
    Jan 8, 2014 5:31 AM in response to TenjuZenjin

    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.

  • by Richard Wallstein,

    Richard Wallstein Richard Wallstein Jan 8, 2014 8:00 AM in response to TenjuZenjin
    Level 1 (0 points)
    Jan 8, 2014 8:00 AM in response to TenjuZenjin

    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

  • by Marcel van Setten van der Meer,

    Marcel van Setten van der Meer Marcel van Setten van der Meer Jan 10, 2014 7:52 AM in response to TenjuZenjin
    Level 1 (4 points)
    Servers Enterprise
    Jan 10, 2014 7:52 AM in response to TenjuZenjin

    -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.

  • by Michael Strum,

    Michael Strum Michael Strum Jan 14, 2014 7:08 AM in response to TenjuZenjin
    Level 1 (0 points)
    Jan 14, 2014 7:08 AM in response to TenjuZenjin

    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/

  • by newjerseydan,

    newjerseydan newjerseydan Jan 14, 2014 10:40 AM in response to Marcel van Setten van der Meer
    Level 1 (0 points)
    Jan 14, 2014 10:40 AM in response to Marcel van Setten van der Meer

    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

  • by -KEPHSTER-,

    -KEPHSTER- -KEPHSTER- Feb 1, 2014 7:18 AM in response to TenjuZenjin
    Level 1 (0 points)
    Feb 1, 2014 7:18 AM in response to TenjuZenjin

    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 ... =)

  • by chain86,

    chain86 chain86 Feb 8, 2014 3:20 AM in response to -KEPHSTER-
    Level 1 (0 points)
    Feb 8, 2014 3:20 AM in response to -KEPHSTER-

    -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!)

  • by vikas911,

    vikas911 vikas911 Feb 14, 2014 6:37 PM in response to chain86
    Level 1 (0 points)
    Feb 14, 2014 6:37 PM in response to chain86

    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

  • by Codeangels,

    Codeangels Codeangels Feb 17, 2014 12:51 PM in response to TenjuZenjin
    Level 1 (0 points)
    Feb 17, 2014 12:51 PM in response to TenjuZenjin

    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)

  • by Cthulhu,

    Cthulhu Cthulhu Feb 21, 2014 4:33 AM in response to -KEPHSTER-
    Level 1 (68 points)
    Wireless
    Feb 21, 2014 4:33 AM in response to -KEPHSTER-

    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).

  • by tekwerx IT,

    tekwerx IT tekwerx IT Feb 26, 2014 5:12 PM in response to TenjuZenjin
    Level 1 (0 points)
    Feb 26, 2014 5:12 PM in response to TenjuZenjin

    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.

first Previous Page 3 of 12 last Next