AFP/SMB Directory Listings very slow in Finder

I've read through this thread in hopes that someone would cover "searching" SMB shares on a Windows server. We are having issues when trying to search. The speed itself of navigating the shares is fast enough, but trying to search is basically nonexistent due to how slow it is.

I've added the Volume as a spotlight index via the mdutil terminal command. That has allowed for some searching, but does not function as a true search, as it won't find certain things (Folders, files, etc) I'm not sure if it's still indexing (nothing going on via the spotlight icon) or what if it's doing anything.

Anyone have similar issues, or experiences?

Thanks,

Jason

Unless something has changed in 10.11 that I am not aware of, you can only do file name searching of network shares, not content searching, which may be why you have limited results. Spotlight is only supported on AFP shares, or network shares from a Mac server. Since Windows servers do not use Spotlight indexing, you rarely get dependable searching. If you use a Windows server, try Extreme Z-IP to create AFP shares on your server for full Spotlight indexing.

Thank you, that is what I was afraid of but wasn't able to confirm from the searches I've done.

Apple believes that Mac users only need to search Mac formatted drives that are directly connected to a Mac.

When I upgraded to El Capitan I expected better support for SAMBA. Accessing shares over VPN is extremely slow and buggy. The problem is El Capitan because I have a Windows VM installed on it and it works 10x faster than Mac.

Kiwiro wrote:

When I upgraded to El Capitan I expected better support for SAMBA.

Samba changed their license to exclude Apple from shipping Samba with OS X. Apple had to roll their own CIFS/SMB support into OS X.

If you want Samba, it is available as an open source package at

<https://www.samba.org/>

Interesting. Until today, I thought SMB and Samba are the same thing. Anyway, linux and windows machine work a lot better than Mac with my NAS. I understand why it doesn't work well, but it's not a good excuse. Considering SMB/Samba are widely used in the consumer market and that Apple plans to drop AFP support, it should work a lot better than it does now.

Samba has been tuned for many many years (at least 15 or 20), and it is often what runs on other open source platforms. And until a few years ago it was distributed as part of OS X. But then Samba changed its license to explicitly exclude distributing the software with any closed source packages (Apple, and other commercial Unix operating systems).

But the license changes do not exclude you. You are allowed to install Samba on your Mac if you desire. It is only Apple that cannot install it for you.

As for performance, it is not easy getting a network file system working efficiently (speaking as someone that worked on an AFP implementation for OpenVMS back in the late '80s and early '90s).

Yes, it would be nice if Apple's CIFS/SMB implementation worked well with Windows. Suggest you provide Apple with feedback for you needs

as it is possible Apple is mostly testing against Macs and less so against Windows and Samba implementations on other platforms. After all, they are selling Macs, not Windows, Linux, Solaris, AIX, HP-UX, etc... 🙂

Hi Kiwiro, what're the typical speeds you're getting from OS X and Windows VMs? Is it better when not using VPN?

I've been using the default (SMB2) from El Capitan to access Windows 8/10 shares on the same Gigabit ethernet and I get 80-110MB/s read/write speeds (typically for files larger than a 2GB). I did make the changes suggested in https://discussions.apple.com/thread/5500165?answerId=25626139022#25626139022 after I experienced terribly slow browsing in 10.9.3.

On the work NAS (qnap), to which I can connect through VPN only, I get 1 MB/s both on Mac and on Windows 7 VM. That's the upload speed limit of the NAS. Finder crashed 2 times till I got to the test file.

On the home server, I got 20 MB/s from Mac and 25 MB/s from Win VM. 25-30 MB/s is the server's limit (an old dell laptop).

My home server is on Linux so I can't use the solution from the link.

Thanks. I'll let you know when I get a chance to test with a Linux machine.

BTW, I assume SMB3 is enabled on Linux (I thought that the default on El Capitan was SMB2, but it is SMB3 https://www.apple.com/jp/osx/all-features/pdf/osx_elcapitan_core_technologies_ov erview.pdf).

It took me a while to check whether the home server was actually using SMB3 or not and it does. The work NAS has SMB3 active but I don't know if it's using it because Wireshark shows the packets as SSL. My problem is with directory listing and Finder crashing when accessing shares, not necessarily the transfer speed.

I've also had Finder crashing while trying to browse Windows 10 shares in the earlier betas (including 10.11.2), but I haven't had any problems with the latest one (beta 4). Sorry - I thought browsing and transfer speeds were related.

Would Wireshark capture on Mac help isolating the cause for Finder crash?

Hello All, wasted a good few days checking every possible reason why SMB shares are slow to access on OSX 10.11.x (and possibly before but not wasting more time)

Tried Samba on multiple NAS distros and Windows vanilla SMB file sharing... nada Tried downgrading server versions smb nt/v1, smb v2, and applied tests of recommended OSX smb/nsmb.conf testing, excluding spotlight from indexing volumes, changing finder views, changing finder display thumbnails/previews, nothing improves the slow smb browsing speeds.

Here is a great document on finder's behaviour on a network http://www.emc.com/collateral/TechnicalDocument/docu51273.pdf - very specific and looks like EMC had a hard time getting things to work with there SAN/Storage tech also.

Two machines side-by-side, one is win 7, other OSX 10.11.x i5 macbook, browse a network share with more than 100 objects... win7 near instant, OSX poor and un-productive content loading, wait anywhere between 20sec to 5min for larger folders.

In OSX, browse the same SMB mount via terminal, instant results, no delays in fetching file names, size (e.g.# ls /Volumes/smbShareName/dir1), this is not a smb version issue or size of folder. Its finder!

Makes me really sad that Apple made finder resource hungry for network volumes, whats even worse is the latest Office 2016 only supports the SMB protocol and AFP left with various user issues like opening re-corrupt files (when they are fine via slow OSX smb access).

For the love of G*#, Apple give use a network optimised finder... you want to get on the SMB bus, put the wheels back underneath so we can start rolling forward as I cannot support Mac in a business environment much longer.

webmaster@data2 wrote:

For the love of G*#, Apple give use a network optimised finder... you want to get on the SMB bus, put the wheels back underneath so we can start rolling forward as I cannot support Mac in a business environment much longer.