Looks like no one’s replied in a while. To start the conversation again, simply ask a new question.

Level 1

31 points

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:30 AM

Best reply

knob1

Level 1

9 points

Posted on Nov 26, 2015 6:50 AM

!! Possible solution that worked for me - at the moment !!

Hello,

I also got the problem that browsing an afp share gets very slow.

My Share is little over 5TB big with much media data.

I tried all the solutions that I found on this forum but nothing helped as much as what I just found.

After spending many hours today to find a solution I finally turned on wireshark to have a look whats going on on port 548 (AFP over TCP Port)

I saw that whenever I opened a folder many requests were send to the server - my guess was that the finder is requesting the little preview images because inside of each request was a filename of the folder I just opened.

My guess is that whenever you open up a folder, OSX sends multiple requests to the server to get the preview image.

The server tries to answer all the requests but when you navigate to another folder the next requests for this folder are sent - kind of DDOS.

After realising this, I went to the root share, right clicked -> Show Vew Options and turned off Show Icon Preview.

The result was phenomenal - afp was fast and the traffic on port 548 was shut down very drastic.

I would like to hear if this solves the problem for others too or if I'm the only one where this helped

View in context

183 replies

Nov 11, 2013 2:35 PM in response to TenjuZenjin

I also have the same problem running on a synology NAS disk station (with SMB2 support for mavericks update installed).

Running a windows 8 VM on the same machine as Mavericks loads the share in seconds, the same folder in Mavericks takes 30mins plus.
To confirm https (WebDAV) is no quicker either (to add to TenjuZenin's list above)
I'm on a LAN so I can't image how painful this would be on a VPN.

Apple, please can you provide some enterprise support for file shares and other basics (including iSCSI). It can (and does) take hours to do basic file maintenance jobs which takes minutes on a PC.

Nov 14, 2013 1:58 PM in response to TenjuZenjin

As with everyone here, I'm experiencing the exact same issue. I've used the solution to force the network connection using SMB1 (via the CIF protocol).

However the implementation by Apple and without clear warning has ground my business to a halt with problems due to not being able to access the server. The solution isn't guaranteed to work.

Maverick's was in beta for 3 months and has now been out for over a month. This should have been resolved by now and the fact that everyone except Apple have made comment is unsatisfactory.

This has got to be fixed as a matter of urgency or a valid workaround.

Nov 14, 2013 2:38 PM in response to TenjuZenjin

Have you tried using NFS?

What's the network throughput on the VPN?

Nov 14, 2013 3:00 PM in response to chattphotos

Thank you for a quick reply to my post charrphotos.

I'm no network or protocol expert but able to follow instructions and understand the technical rudimentaries.

As shares have been easy to connect to as Bonjour/zeroconf have developed, I haven't needed to look at other protocols such as NFS. Help on this would be welcome.

In this scenario, I was in the midst of moving all the business data from a simple Netgear Stora (clearly based on a Linux OS) to the Mac temporarily. Therefore NFS could be supported but I'm not sure because the only interface to configure the Stora is web-based. I never really use it since it's just a storage vehicle (that currently isn't moving at all).

It's all setup on a one-subnet straightworward LAN. The Mac and the NAS are connected to the same switch. I've tried this on another Mac and the result is the same.

Internet access isn't necessary and therefore there is no VPN to complicate matters. All I need to do is a simple copy of files but the directory structure is quite lengthy which is probably exacerbating the issue. However in the directories I have been able to access, copying is impossibly slow.

Do I force the NFS protocal via the Finder? Also will the Stora recognise that protocol without hacking?

Nov 14, 2013 4:42 PM in response to dpasarchi

To note, I replied to the OP...

You network setup is quite different from the original post, so the troubleshooting steps may be different.

To attempt an NFS connection:

Connect to Server (Command + K) NFS://server.name.ip.here

Is your network Gigabit (1000mbps)?

If not, there will be a bottleneck if anything is going over a 10/100mbps port which sounds like that may be your issue.

Do you use any Wifi connections?

TenjuZenjin Author

Level 1

31 points

Nov 14, 2013 11:42 PM in response to TenjuZenjin

To reply to the new informations: yes, i did try NFS and it was as slow as AFP and SMB2. I also did try to force to SMB1 using CIFS, with no better results as SMB2. I think all those protocols are based on the same implementation. That's why switching protocols does not offer any relief.

The only solution thats seems practicable for the moment is SSHFS/SFTP. The directory listings are quick, browsing is fast and file transfers are quite comfortable. I think the SSH protocol is the only one that they left untouched and is still based on the original OpenSource implementation. It's sad that you have to think first:"What did Apple not touch?" to get to a working solution...

Note that using SSHFS/SFTP is a quick and dirty fix and should not be used further in the future. I'm hoping Apple fixes this URGENTLY! I'm also conerned about the fact that Apple until now did not commented this issue, even to just say:"OK, we will fix this ASAP".

Also note: i tested all teh protocols on other clients with other systems (Windows 7 and OS X with Snow Leopard or Mountain Lion) and they all did not have any problems with any of the cited protocols. I did not try OS X Lion because IMHO it's not a working system, it's a **** of a mess.

neilp

Level 1

1 points

Nov 15, 2013 1:58 AM in response to -KEPHSTER-

Experienced similar problems; most probably due to problems with the browsing client's Finder using .DS_store files on the remote server. The deeper into the remote server's directory tree you browse, the longer the delay. All good though after typing the following in Terminal (no SUDO needed) and rebooting the client.

defaults write com.apple.desktopservices DSDontWriteNetworkStores true

This fix worked for me - cheers -KEPHSTER-

Nov 15, 2013 8:56 AM in response to TenjuZenjin

Is your network Gigabit?

Do you have anything with a 10/100 port/switch?

What is your VPN throughput/internet bandwidth?

pguthrie

Level 1

0 points

Nov 15, 2013 9:22 AM in response to chattphotos

I think I can reply to this as I'm seeing the same thing. I have one desktop running Snow Leopard and two laptops running Mavs on the same network. Our VPN performance to the data center is very good ( downstream above 10Mbits and upstream 2-3Mbits). Doing the same thing on SL vs. Mavs is night and day difference... SL is immediate, Mavs takes many minutes. I'm using AFP.

TenjuZenjin Author

Level 1

31 points

Nov 15, 2013 9:22 AM in response to chattphotos

If you're asking me, here are the specs:

VPN is a network to network tunnel with a QoS of 2MBit/s up/down guaranteed. The peak can go up to 30MBit/s down and 6MBit/s up, on the weakest side. The strong side has 50MBit/s up/down. Internet connection is VDSL on the weakest side and fibre on the strong side.

Both networks are 10/100/1000 BASE-T Gigabit Ethernet. All clients are connected with CAT-6 Cables connected to Cisco 10/100/1000 stackable switchs, stacked with 10Gig fibre cables.

I dont wanna go into detail but we are also talking DHCP, internal DNS, Firewalls, Port management and routing, VLAN, ... Generally said: you can exclude all those params as possible problem. Why? Because all other OS X and Windows clients have the same network specs and dont suffer from the performance loss, as the Mavericks clients do... To keep it short: all the same for everyone and the problems only occur on the Mavericks clients.

Nov 17, 2013 12:26 PM in response to chattphotos

defaults write com.apple.desktopservices DSDontWriteNetworkStores true

This worked for me... I spent a total of 8 hours troublshooting insanely slow file transfer speeds for a new client (the reason they called me). I even reconfigured their network and put in a new gigabit switch and patch cables.

Wow, I can't believe it had to do with the .ds stores.

Dec 7, 2013 2:37 AM in response to tekwerx IT

defaults write com.apple.desktopservices DSDontWriteNetworkStores true

While turning off creation off the invisible .DS_Store files made browsing over VPN a bit faster, it's still nowhere close to acceptable speed.

What really made a 10x speed improvement - in our case - is using 3th party product 'Path Finder' instead of Finder.

Not to mention: if we copy a file to the local Desktop from an OS X Server over VPN(afp/smb) and initiate a copy of another file too > these 2 copy processes are sharing the bandwidth 50-50%

With 'Path Finder' it's possible to queue file transfers which is a nice feature I personally like.

I don't like to replace the built-in functionality of the OS by default, but it seems like I have to,

if this is the best what apple engineers / product managers are able to offer.

Dec 7, 2013 4:28 AM in response to Mac Admin1

I have already turned off the .DS_Store option and have just downloaded the trial of Pathfinder. The result at my end was that Pathfinder stopped responding when attempting to access a network share and I got the spinning beach ball. It required a force quit.

Clearly there's a more involved change to the filesystem that is causing this issue and essentially the Mavericks upgrade is going to break a lot of networks if applied in business.

Apple should address this issue urgently OR provide a work around until fixed.

I suspect, like their badly implemented rewrite of the SMB protocol with a previous OS upgrade, is to blame. This is URGENT. I've managed to spend days FTPing the files of the network disks to copy locally but this is unacceptable. My clients however are another matter.

Dec 17, 2013 7:38 AM in response to TenjuZenjin

I have the same issue here !

After some upgrades of clients to Mavericks, directory listing is very slow in Finder. (Network shares AFP, CIFS.)

Some of our people have upgraded to Mavericks, stupid, nothing is free for a reason.... 😉

10.6.8 however seems to me the most stable relaible version. After testing with a client on 10.6.8, the results are mutch better. Directory browsing on a network disk is a lot quicker.

I Hope apple wil fix this very soon. Then they will be happy in the office again.

Dec 18, 2013 9:00 AM in response to tekwerx IT

Update:

Some users are now saying that the .DS stores command is not working for them, and still have issues browsing AFP. One in particular uses a Time Capsule and going more the 2-3 levels deep in the folders takes Finder 30-90 seconds to show the files.

One thing to note is that users connecting to Mac servers don't seem to be complaining. I'm not sure if they are experincing any issues or not. I assume if they were I would hear about it, making me think Mavericks clients on Mac server is not affected. The compaints I have recieved are mainly from users of Time Capsules (5th gen), and other NAS storage such as the Buffalo LinkStation Pro.

Anyone have any other updates besides how no one can believe this isn't fixed yet?

AFP/SMB Directory Listings very slow in Finder