AFP/SMB Directory Listings very slow in Finder

For me it was night and day. On 10.10.5 it took around 1 min 30 to open a particular folder. Doing the same from 10.11.4 it was a few seconds. I checked it twice as I couldn't quite believe it.

Today I've noticed something strange. My samba shares loaded slower than usual, so I checked the logs on the NAS. It showed that I was connecting with a user I logged in earlier today, even though I unmounted the shares and used smb://[new.username]:*@[IP_addr]/ to log in again. After a reboot, the logs no longer showed the old user and the shares loaded at their usual speed.

I went into Preferences->Networks and deleted WiFi, re-added it, re-connected and all of my samba connections suddenly started working at the normal speed. Even in-progress video playing and command line copies speeded up over an order of magnitude. I am on El Capitan and connecting to a Linux samba server.

Thanks! I would never have suspected my wireless connection as the culprit.

This – deleting the WiFi protocol from Preferences and re-adding it – seems to have solved the problem of the veeery slow finder listings, connecting over AFP to our QNAP TS-853 Pro.

I´ll wait some days to be really sure this solution sticks.

I had a problem with Finder being very slow when accessing shared folders on a Mac Mini from my iMac. I tried switching off the file previews as suggested above (a task in itself which involved using Terminal to delete all the folder presets stored in .DS_Store files and then changing default settings), this made no difference. In the end, I had to force it to connect using AFP instead of SMB, these are the steps that worked for me:

• I disconnected my iMac from the shared Mac Mini folder (clicked eject button and/or disconnect button in Finder, it's not always clear if it has disconnected as it still displays in the Shared list on Finder, but if you go into terminal and look in the Volumes folder it is no longer visible, so disconnected I guess).
• Went to Go > Connect To Server and could see that the last connection made was using SMB, so deleted this and cleared the recent server list too.
• Went into Keychain and deleted all password entries for the Mac Mini. (I was then fairly sure that all previous settings for connecting were deleted.)
• Went to the Shared Folder setting options on the Mac Mini itself and switched off the SMB option and unchecked the admin account under the Windows File Sharing box. (I was then fairly sure that it would be impossible to reconnect with anything other then AFP).
• On the iMac I clicked on the Shared machine in the Finder bar, and it connected as always, this time (I believe) using AFP.
• Bob's your Uncle, Finder is suddenly fast again when accessing the shared folder.

A few of things still puzzle me:

1. Why is AFP so much faster than SMB and why had two Apple machines connected with SMB by default, when AFP is the "native" Apple protocol and SMB is from MS Windows?
2. Why, when I enter the File Sharing options on the Mac Mini, does it say there is one connection with SMB and one connection with AFP when SMB is totally turned off? What/who is connected using SMB?
3. Why does it initially say in Finder that I'm "connected as" to the shared folder using my iCloud account (displays email address) but then when I go into the folder it switches and says I'm "connected as" and displays my admin login instead? How do I completely disable the ability to share a folder using an iCloud account?

Hope first part above helps someone and if anyone has any answers to the second part I'd love to hear them!

Communication Common wrote:

I had a problem with Finder being very slow when accessing shared folders on a Mac Mini from my iMac. I tried switching off the file previews as suggested above (a task in itself which involved using Terminal to delete all the folder presets stored in .DS_Store files and then changing default settings), this made no difference. In the end, I had to force it to connect using AFP instead of SMB, these are the steps that worked for me:

• I disconnected my iMac from the shared Mac Mini folder (clicked eject button and/or disconnect button in Finder, it's not always clear if it has disconnected as it still displays in the Shared list on Finder, but if you go into terminal and look in the Volumes folder it is no longer visible, so disconnected I guess).
• Went to Go > Connect To Server and could see that the last connection made was using SMB, so deleted this and cleared the recent server list too.
• Went into Keychain and deleted all password entries for the Mac Mini. (I was then fairly sure that all previous settings for connecting were deleted.)
• Went to the Shared Folder setting options on the Mac Mini itself and switched off the SMB option and unchecked the admin account under the Windows File Sharing box. (I was then fairly sure that it would be impossible to reconnect with anything other then AFP).
• On the iMac I clicked on the Shared machine in the Finder bar, and it connected as always, this time (I believe) using AFP.
• Bob's your Uncle, Finder is suddenly fast again when accessing the shared folder.

We did all af the steps described above but none of it did help solve the problem with the tooootaaaally slow finder listings served from our QNAP Share.

A few of things still puzzle me:

Why is AFP so much faster than SMB and why had two Apple machines connected with SMB by default, when AFP is the "native" Apple protocol and SMB is from MS Windows?

Hope first part above helps someone and if anyone has any answers to the second part I'd love to hear them!

I really don´t know if to connect over AFP is faster than to connect over SMB, but AFP is deprecated by Apple since OS X 10.9 ("Mavericks").

That's interesting, I didn't know about the deprecation, but presumably this is why Apple machines connect with SMB, not AFP by default. Perhaps it's a coincidence that AFP works faster for us and it's due to some other setting being changed in the process that it now works faster (problem with Keychain, for example). Sorry it didn't help you, but I'll let you know if we work anything else out!

Hi !

Check this : http://juosukai.github.io/2014/12/29/samba-4-mac/

You may try to add these following lines in your smb.conf :

vfs objects = fruit streams_xattr recycle

fruit:resource = file

fruit:metadata = netatalk

fruit:locking = none

fruit:encoding = private

It also seems that, without the previous add, using SMB1 protocol fixes slow issues (on Finder only) I got with SMB2+ protocols.

Seeing as disabling the Show icon preview got a lot of votes as "this helped me" I tried it. I also tried removing and logging back into my WiFi. Neither helped the issue. I also tried a few (but not all) of the various prior fixes here in this thread. I did lots of experimentation with different SMB levels (my QNAP NAS has 3.0, 2.1. 2.0, 1.0) and none make any difference. I also just updated my NAS firmware. I'm running 10.11.4 and about to update to 10.11.5. I had similar problems on my last much older ReadyNAS. As others have stated the problem here is clearly the darn Finder...

It's truly amazing that Apple could have gotten this so wrong for so long and it is still not fixed. I submitted a report to Apple as well.

After various tests, it seems that we got issues with vfs_fruit concerning copying files or directories even if it corrected our rename issue and slow update of the volume content.

By removing :

vfs objects = fruit streams_xattr recycle

fruit:resource = file

fruit:metadata = netatalk

fruit:locking = none

fruit:encoding = private

And adding :

vfs objects = streams_xattr

in your smb.conf it seems that all issues get fixed.

Here a part of the result of cmd : smbutil statshares -m <volume_name>

SMB_NEGOTIATE AUTO_NEGOTIATE

SMB_VERSION SMB_3.0

SMB_SHARE_TYPE DISK

SIGNING_SUPPORTED TRUE

EXTENDED_SECURITY_SUPPORTED TRUE

LARGE_FILE_SUPPORTED TRUE

FILE_IDS_SUPPORTED TRUE

DFS_SUPPORTED TRUE

MULTI_CREDIT_SUPPORTED TRUE

ENCRYPTION_SUPPORTED TRUE

I hope this can help you.

Thanks PerryBelik, can you provide slightly more detailed instructions for implementing the changes you found that correct the issue?

Important:

The main problems of slow connections to NAS servers are the processor of the NAS. OSX force the use of samba even if you connect as CIFS. Before make any change check how the samba process is working in NAS. In my case it is 100% cpu usage and creates a bottleneck that makes painfully slow navigation in folders with too much files.

Hi Codeangels,

Can you help. When I run the sudo code, it works perfectly and I have lightning quick access to my NAS drive but I can't suss out the making it stick after reboot. I'm running 10.11.6, made a file with net.inet.tcp.delayed_ack=2 in Text edit, saved as a .txt into /etc/ as suggested but every time I reboot I'm back to slow.

If I enter the command back into terminal, I'm back to lightning. What am I missing to make it stick. Am i putting the file in the wrong folder?

You might want to consider starting a new discussion. Since this one is a couple of years old, less people are likely to look at it. A new post would be much more visible. You can link to this one.

This issue has something to do with the cloudd (double-d) service.

Loading a 200 subdir on my Sybnology NAS could take 20-40 minutes. Now it loads in seconds.

Here is how to solve this:

Go to ~/Library/Caches/CloudKit/

Remove CloudKitMetadata, CloudKitMetadata-shm, CloudKitMetadata-wal

Kill Cloudd in Activity monitor. Cloudd will restart automatically, and rebuild the databases.

DONE.

Good luck, and backup you data!

Richard