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 6 of 12 last Next
  • by David_x,

    David_x David_x May 28, 2014 12:42 AM in response to austinfurlvr
    Level 4 (3,010 points)
    May 28, 2014 12:42 AM in response to austinfurlvr

    Similar here - remote AFP access to 10.6 server via VPN from Mavericks client - grinds to a halt.

     

    Only work-a-rounds that have alleviated the problem somewhat are...

     

    1. Bookmark (in Favourites section in Finder window) individual low-level project folders, rather than crawl the full path from share-point down.

     

    2. Use a Spotlight search for individual project folders.

     

    3. Install Path Finder as an alternative Finder - bypasses whatever the Mavericks FInder is doing to create the delays.

     

    Initial tests with a Mavericks server (replacing 10.6 server) are positive with browsing back to what is expected via a VPN. These tests are ongoing but looks like a replacement is imminent (or possibly a NAS if SMB is found to be a problem for the PCs, as reported on other threads).

  • by shoegazer4,

    shoegazer4 shoegazer4 May 30, 2014 6:00 AM in response to TenjuZenjin
    Level 1 (0 points)
    May 30, 2014 6:00 AM in response to TenjuZenjin

    Anyone else have issues with files sessions not closing? Users cant move, rename or delete unless i log onto the server and close the file session.

     

    We're using Server 2012 R2, and our users files will stay open on the server even though they don't have them open. I know this is a common problem but its only really become an issue now as it keeps happening to multiple users multiple times a day. It wasnt happening with 2008 R2 and Mountain Lion

  • by tekwerx IT,

    tekwerx IT tekwerx IT May 30, 2014 8:33 AM in response to shoegazer4
    Level 1 (0 points)
    May 30, 2014 8:33 AM in response to shoegazer4

    WOW,

     

    I'm just shaking my head after this last post. I have seen it all now. I had issue with a client on 2006 R2, and pretty much thought if they upgraded their server it would solve the connection issues. Apparently not. Just so everyone knows, I have now seen connection isssues of Mavericks clients on almost all versions of Windows servers and Mac servers.

     

    The only setup that I have been able to get working with out any major issues is one where a Mac Server running Mavericks is running file sharing, and ALL clients are running Mavericks, AND they use bonjour to connect to the server, WITH only SMB enabled.

     

    In my 15 years of Mac, I have never had an OS with such a sever issue. I'm embarrased for Apple.

  • by shoegazer4,

    shoegazer4 shoegazer4 May 30, 2014 9:00 AM in response to tekwerx IT
    Level 1 (0 points)
    May 30, 2014 9:00 AM in response to tekwerx IT

    it was happening occasionally on 2008. Thinking about testing out Novell Open Enterprise Server

  • by kazop,

    kazop kazop May 30, 2014 9:35 PM in response to TenjuZenjin
    Level 1 (0 points)
    May 30, 2014 9:35 PM in response to TenjuZenjin

    Hello,

     

    So far i have done quite a bit of work to find a fix to the SMB issues in OSX mavericks. By this time I have tried every single posted "solution" out there.

     

    There are multiple issues with Mavericks SMB and Finder implementations. These issues stack on one another. Some issues may only be evident under the right circumstances.  For example lots of small files and directories and very large SMB shares.  This explains why some people report issues some don't. I belive that the people that report Maverics as working "wonderfully" simple do not have the scale to see an issue. Mavericks works great until you put it under stress.  Here are my findings (general terms is late to type)

     

    Issue 1) Listings of large directories in SMB shares take a long time.   This is one issue that can be fixed if the directory listing is made of other subdirectories.  It is simply a matter of removing all .DS_Store files and modifying the OSX clients to not write these files to network shares. (defaults write com.apple.desktopservices DSDontWriteNetworkStores true)  If the directory/subdirectory structure is well planned then some of of the below SMB issues can be alleviated.

     

    Issue 2) Slow small file operations (list read write).  OSX's SMB implementation does not perform well with small file operations.  This causes slow listings of directories that are full of small files.  The work around is to modify the file structure to avoid large directories of small files. 

     

    Issue 3) Finder likes to adquire all metadata from a directory before it renders the listing.  No fix for this. it just adds to issue 2. However work around is to modify the file structure to avoid large directories of small files.

     

    Issue 4) Slow reads and writes of "files" that are actually directories full of small files, for example keynote files and iPhoto libraries.  I have not found a single solution for this but it comes down to poor small file performance in OSX's SMB

     

    I have done my testings with both single Samba servers.  and Clustered Samba servers. I am very confident on the Samba server side. I have also tried server side tweaks. It always comes down to the OSX client being at fault. Windows Linux clients always perform well.  Working for a creative company means that a large majority of our user base is OSX and I am really eager for apple to address this issues.

     

    I have to add that large file operations work great in Mavericks i ussually get full bandwidth 100MBps to 120MBps when reading and writing single large files.

  • by Phreding,

    Phreding Phreding Jun 6, 2014 8:51 AM in response to pulsar37
    Level 1 (0 points)
    Jun 6, 2014 8:51 AM in response to pulsar37

    Pulsar37 wrote:

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

     

    I am running Windows 8 and sharing folders on my home network with an OS X 10.9.3 MacBook Pro. This tweak worked really well for me.  I am curious why you choose 768 (min) and 16384(max).  Thank you so much for the help!

  • by pulsar37,

    pulsar37 pulsar37 Jun 6, 2014 10:18 AM in response to Phreding
    Level 1 (0 points)
    Jun 6, 2014 10:18 AM in response to Phreding

    Glad to help. Honestly, the numbers were an educated guess and trial and error, based on this MSDN doc and the appendix links in that doc (161 thru 163). The reason I say educated guess is because I haven't yet determined precisely what Mavericks is doing that causes Windows servers to make it "talk to the hand". It could be an issue with Mavericks handling of smb2 sequence numbers, or just overzealousness with simultaneous requests.

     

    In any case, Smb2CreditsMin is the limited number of credits the server will freely give a client just for asking, and that can help with Mavericks' tendency to request tons of info about directory contents immediately upon connecting. Standard Windows has a min value of 128, Windows Server has a min value of 512, so 768 seemed a modestly appropriate incremental increase. I then merely doubled the Smb2CreditsMax value to make sure Mavericks clients wouldn't hit a wall by potentially consuming the min value immediately and then ramping up requests.

     

    While this tweak works well for me, I have no more than 6 Mavericks clients connecting to the server at once. In an environment where there are many more clients than that, this tweak might let all those hungry Macs saturate a small server.

  • by afinotti,

    afinotti afinotti Jun 7, 2014 1:43 PM in response to TenjuZenjin
    Level 1 (0 points)
    Jun 7, 2014 1:43 PM in response to TenjuZenjin

    I have a WIndows 8 server and workstations with OSX 10.9.3.

     

    Force enable NetBios over TCP/IP solved!

     

    This link has the path to get there, but click Enable instead of Disable:

     

    http://chandank.com/os/netbios-disable-windows-8

  • by Domnosil,

    Domnosil Domnosil Jun 9, 2014 5:30 AM in response to TenjuZenjin
    Level 1 (0 points)
    Jun 9, 2014 5:30 AM in response to TenjuZenjin

    I'd like to add one thing which also helped. After forcing the connection to Samba 1 (posted somewhere above in this discussion), listings of folders can be speedier when you shut down the samba notification (the old apple problem). Write "notify_off=yes" to your nsmb.conf file in /etc. You can write this line to Terminal:

     

    sudo sh -cv "echo '[notify_off=yes]' >> /etc/nsmb.conf"

  • by Jorge Secco Caetano,

    Jorge Secco Caetano Jorge Secco Caetano Jun 16, 2014 7:04 PM in response to TenjuZenjin
    Level 1 (10 points)
    Jun 16, 2014 7:04 PM in response to TenjuZenjin

    I would like to add my 0,20 cents here:

     

    Situation =  (same issue here) MAVERICKS + WINDOWS 8.1 shares... very, very slow browsing.

    (Gigabit switch, wired ethernet, RAID 0 on Windows 8.1 with 3HDs and RAID 1 on OSX with 2HDs)

     

    So i decided to test two scenarios:

     

    1) Using only cifs:\\ shares (smb1 on OSX) = a) browsing are really fast, but b) no transfers got more then 450Mbits either for lager files (more then 25Gb) or smaller files;

     

    2) Using smb:\\ shares (smb2 on OSX now) = a) browsing like **** (5min to list 200 files), but all transfers toutched the ceilling here at 850Mbits to files larger than 12Gb and 980Mbits for files smaller than 12Gb (I think that files within the windows cache are faster);

     

    I also tested some NAS providers over my corporate network and one specially designed to operate at 4Gbits speeds (FreeNAS with 6HDs plus two eth interfaces) gave me slow browing under Mavericks. It also had smb2 under the hood and browsing was signifcantly faster then windows 8.1, but really slower then previous OSX versions.

     

    I will try touching the windows parameters here as well as shutting down the .DS files to see how far can my MBPro lands here.

     

    Txns for tips!!!

  • by Jorge Secco Caetano,

    Jorge Secco Caetano Jorge Secco Caetano Jun 16, 2014 7:45 PM in response to Jorge Secco Caetano
    Level 1 (10 points)
    Jun 16, 2014 7:45 PM in response to Jorge Secco Caetano

    Ok, the smb2 parameters did the trick here... it seems windows are quite conservative regarding client requests throttling up, so buffing up these parameters really worked here (might not be the case with VPNs or high latency links).

     

    Just checked some smb2 guides and it is quite ok to change these parameters. Windows are more likely to use smb3 nowadays.

     

    I will try to mimic these smb2 parameters with my NAS devices here and will post results when available.

     

    Cheer up!

  • by Westrex,

    Westrex Westrex Jun 26, 2014 8:59 AM in response to Jorge Secco Caetano
    Level 1 (0 points)
    Jun 26, 2014 8:59 AM in response to Jorge Secco Caetano

    Experiencing the same issues as described by all. Devastatingly slow connectivity speed with Mavericks that has required we bring back older machines running Lion. Its unfortunate Apple will not respond to a show stopper situation that is so critical to their business customers. Here is an interesting fact. Connecting to an old XServe sitting in a Win Server environment running 10.6 offers the same fast afp connectivity from any OSX workstation. Lightning fast with Mavericks.

  • by Jorge Secco Caetano,

    Jorge Secco Caetano Jorge Secco Caetano Jun 26, 2014 2:20 PM in response to Westrex
    Level 1 (10 points)
    Jun 26, 2014 2:20 PM in response to Westrex

    Westrex,

     

    I truly believe this is related to SMB2 parameters in OSX 10.9. I tweaked some parameters in my Windows 2008 R2 server, matching the OSX 10.9 required behavior, and everything got blazing fast using SMB shares (SMB2) (around 960Mbits). I never used AFP for practical reasons, mostly because I have a few MacBooks here and SMB is the default connection (avoiding add another service to my servers).

     

    Regard, that in my tests, SMB2 connections were far better (after the tweaks in the server side) than SMB1 (cifs://) connections, and besides the fast browsing files and folders, transfers were slow (below 400Mbits) using SMB1. I would try configuring the same parameters at your windows SMB2 servers so you could adjust to OSX 10.9 behavior that is more aggressive.

     

    The parameters were:

    "Smb2CreditsMin and Smb2CreditsMax

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

    And I used the sweetcider method (powershell). Smb2CreditsMin set to 768 and Smb2CreditsMax set to 16384 (decimal values)

  • by Westrex,

    Westrex Westrex Jun 26, 2014 3:30 PM in response to Jorge Secco Caetano
    Level 1 (0 points)
    Jun 26, 2014 3:30 PM in response to Jorge Secco Caetano

    Great, I'll give it a go. I was always told to never use SMB for connection using a Mac to Win environment. We use a workaround using afp and Acronis ExtremeZ-IP. I suppose in this case the Win server will think it is, and negotiating like a PC. Just wondering if metadata in files and directories will behave the same or there will be some data loss from the files created in OSX. Thanks

  • by nkalvi,

    nkalvi nkalvi Jun 26, 2014 6:28 PM in response to Jorge Secco Caetano
    Level 1 (0 points)
    Jun 26, 2014 6:28 PM in response to Jorge Secco Caetano

    My experience is also the same.

first Previous Page 6 of 12 last Next