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 4 of 12 last Next
  • by pguthrie,

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

    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.

  • by Hevisko,

    Hevisko Hevisko Feb 28, 2014 11:55 PM in response to pguthrie
    Level 1 (0 points)
    Feb 28, 2014 11:55 PM in response to pguthrie

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

     

    Waiting for 10.9.2.1 or 10.9.3 ;(

  • by surogat70,

    surogat70 surogat70 Mar 2, 2014 4:26 AM in response to TenjuZenjin
    Level 2 (150 points)
    Mar 2, 2014 4:26 AM in response to TenjuZenjin

    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.

  • by Cthulhu,

    Cthulhu Cthulhu Mar 2, 2014 6:48 AM in response to surogat70
    Level 1 (68 points)
    Wireless
    Mar 2, 2014 6:48 AM in response to surogat70

    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.

  • by surogat70,

    surogat70 surogat70 Mar 2, 2014 8:21 AM in response to Cthulhu
    Level 2 (150 points)
    Mar 2, 2014 8:21 AM in response to Cthulhu

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

        }

  • by osinkboy,

    osinkboy osinkboy Mar 3, 2014 10:46 PM in response to Cthulhu
    Level 1 (0 points)
    Mar 3, 2014 10:46 PM in response to Cthulhu

    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.

  • by Cthulhu,

    Cthulhu Cthulhu Mar 4, 2014 6:49 AM in response to osinkboy
    Level 1 (68 points)
    Wireless
    Mar 4, 2014 6:49 AM in response to osinkboy

    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.

  • by Domnosil,

    Domnosil Domnosil Mar 11, 2014 2:43 PM in response to TenjuZenjin
    Level 1 (0 points)
    Mar 11, 2014 2:43 PM in response to TenjuZenjin

    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.

  • by Ted413,

    Ted413 Ted413 Mar 19, 2014 2:53 AM in response to -KEPHSTER-
    Level 1 (0 points)
    Mar 19, 2014 2:53 AM in response to -KEPHSTER-

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

  • by Ronesy,

    Ronesy Ronesy Apr 14, 2014 7:22 AM in response to TenjuZenjin
    Level 1 (0 points)
    Apr 14, 2014 7:22 AM in response to TenjuZenjin

    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.

  • by joewebdms,

    joewebdms joewebdms Apr 18, 2014 7:48 AM in response to TenjuZenjin
    Level 1 (0 points)
    Apr 18, 2014 7:48 AM in response to TenjuZenjin

    I tried all of the fixes in this thread and none of them worked for me.  Then I started looking into the various options in the nsmb.conf.   I noticed that you can force the mac client to only connect over port 445 (netbois over tcp):

     

    [default]

    smb_neg=smb1_only

    port445=no_netbois

     

    I tried that and could not connect at all.  That meant the server was not allowing netbois over tcp. I went to our Windows server and enabled netbois over tcp.  Reconnected and poof, everything was fast again.  If you still can't connect after enabling netbois over tcp, then the Windows firewall could be blocking you.  You will then need to allow 445 in your firewall.

     

    By the way, I did not have to change all the Mac's in our office after I could connect.  The mac client defaults to NetBIOS over TCP, if that is unsuccessful, it tries to connect over straight NetBIOS.  I just forced NetBIOS over TCP to test whether server was accepting NetBOIS over TCP.

  • by pulsar37,

    pulsar37 pulsar37 Apr 29, 2014 11:57 AM in response to surogat70
    Level 1 (0 points)
    Apr 29, 2014 11:57 AM in response to surogat70

    Ok, I think I have another possible solution (workaround). There seem to be a variety of similar problems in this thread, but for me, the problem was  incredibly long delays for directory listings when connecting from a Mac running Mavericks to any Windows server using SMB2. The problem was worst when connecting to Windows 8/8.1/2012 R2.

     

    My OSX console log sometimes mentioned a timeout waiting for smb2 credits, so as per this Microsoft document, I created these two registry DWORD entries on my Win8.1 machine:

     

    Smb2CreditsMin and Smb2CreditsMax

    HKLM\System\CurrentControlSet\Services\LanmanServer\Parameters\Smb2CreditsMin 
    HKLM\System\CurrentControlSet\Services\LanmanServer\Parameters\Smb2CreditsMax 

    The defaults, usually not present in the registry by default, are 512 and 8192, respectively. I simply created a new DWORD for Smb2CreditsMin set to 768 and Smb2CreditsMax set to 16384 (decimal values). This made  browsing a Windows share over SMB2 at least as fast as it used to be. Please keep in mind that there could be other implications for your network if you change these (probably not in most small-ish networks), but I have seen nothing but a benefit over both wireless and gigabit LAN, and all over computers (win7, win8.1, mavericks, mountain lion), seem unaffected. As always, be careful in the registry, but if you have the ability to change your server/share settings, hopefully this helps you as much as it helped me.

     

    For clarity's sake, a screenshot:

     

    reg.png

  • by c41,

    c41 c41 Apr 29, 2014 5:41 PM in response to pulsar37
    Level 1 (4 points)
    Apr 29, 2014 5:41 PM in response to pulsar37

    pulsar37 & joewebdms

     

    your last 2 posts above (not sure if it was one or combined) have pretty much* solved the issue for me - finally - in connecting to a Windows 8 Server. I have tried everything in this thread and others, and installing 3rd party apps (pathfinder - which eased the problem, but ideally i dont want to rely on 3rd party apps).

     

    so thankyou!

     

    * when browsing directories on a windows share drive now i'd say 9 out of 10 directories display their contents instantly. about 1 in every 10 seems to stall for 2-5 seconds, i get a beach ball spinning, then it displays. i can live with that

  • by pulsar37,

    pulsar37 pulsar37 Apr 30, 2014 12:31 AM in response to c41
    Level 1 (0 points)
    Apr 30, 2014 12:31 AM in response to c41

    You're welcome! Glad I could help. For others or FYI:

     

    I think the suggestion given by joewebdms to check port 445 and NetBIOS settings is important especially if you're getting  connectivity issues even with basic SMB1/CIFS.

     

    If, on the other hand, you can connect to your Windows server/share just fine, but it takes a really long time (a couple minutes) for any files/folders to appear (and Finder slows to a crawl in the meantime), then your problem might be addressable by making the registry edit I posted above. If you adjust the Smb2CreditsMin and Max parameters in the registry on your Windows server, you shouldn't need to adjust anything on your Mac (Mavericks default SMB2 should work, no changes to nsmb.conf file).

     

    To reiterate: the Smb2credits adjustment should only possibly fix directory listing and painfully slow browsing when opening a new connection from Mavericks to a Windows computer - it probably won't fix other miscellaneous connection issues.

  • by austinfurlvr,

    austinfurlvr austinfurlvr May 6, 2014 7:07 PM in response to TenjuZenjin
    Level 1 (0 points)
    May 6, 2014 7:07 PM in response to TenjuZenjin

    Hi Folks - so I'm having this exact same issue except I'm using a Mac as a server running Snow Leopard ... all the clients were on Lion or Mountain lion and had lightning fast access via internet just connecting via IP address.   However as soon as the clients connected after the update to Mavericks 10.9.2 - it would take 5 to 10 mins to render the file list in the finder window.

     

    I've tried the DS store fix, and I've also add the parent folder of the server to the EXCLUDE list in Spotlight and it "may" have helped as I think there is some caching involved however if you click on a new folder and drill down into another level - after 3 or 4 folder levels it can take a couple of minutes even to display 3 or 4 files in the folder at that level.

     

    I've also tried the TRIAL of TOTALFINDER and experience the same issue....  so that didnt work either.  

     

    Anyone have anything else to offer?   I also logged a case with Apple (on a brand new 27" iMac that is a dinosaur accessing the server next to my 2007 Lion iMac ---  not a very good experience...    Appreciate any new ideas.

first Previous Page 4 of 12 last Next