From NetApp (RE: 8.3 but might still apply). Other things I've done, disable SMB 3 on the NetApp and/or hide the snapshot directory on the share being accessed by the Mac(s).

I think you'll find the overall fix for many many versions of OSX (macOS) vs. many versions of OnTap are like below, force the mac to make smb 1 connections.

CAUSE Packet trace displays that there is no issue with the controller response times, and the issue is with the client side settings.

The SMB LargeMTU feature allows an SMB client to issue a single request of up to 1MB. Without support for this feature, SMB clients (both Apple and Mac) are limited to 64KB max request size. Windows clients get around the lack of support for this feature by using another Windows feature called pipelining. Pipelining allows an SMB client to issue multiple outstanding requests without waiting for a response. Apple supports this feature as well; however, they limit their client to just a few outstanding pipelined requests (less than 4 total outstanding requests versus Windows which regularly goes well above that). So despite a lack of support for LargeMTU, Windows clients have a better performance experience on SMB2.x than Apple because they better utilize pipelining, in place of the absence of LargeMTU with clustered Data ONTAP. Apple Spotlight file indexer is a common cause for slowness in accessing CIFS shares.

SOLUTION Perform the following steps to resolve the issue: Add nsmb.conf to ~/Library/Preferences/ with the following details: [default] smb_neg=smb1_only Set Other-Networks and Static IP address in Network Preference. Connect to smb://pathname Additional settings for improving Mac SMB peformance: Exclude network shares from Spotlight searching: Open System Preferences, Spotlight, and add all the network shares to the exclusion list. Disable updating .DS_Store files within network share folders: Run from a terminatel windows: Defaults write com.apple.desktopServices DSDDontWriteNetworkStores true Two additional settings, Disable ARP requests validation and Revert TCP ACK to compatabilility mode, are also available.

On Nov 7, 2016, at 9:21 PM, James Andrewartha jandrewartha@ccgs.wa.edu.au wrote:

...

On 08/11/16 10:16, Christopher S Eno wrote: Any performance difference between mapping shares this way:

cifs://server/share (forces smb 1)

Vs.

smb://server/share (smb 2+)

We did just test that, and cifs:// works fine, no permissions problems. What debug options can I turn on to see what's happening?

-- James Andrewartha Network & Projects Engineer Christ Church Grammar School Claremont, Western Australia Ph. (08) 9442 1757 Mob. 0424 160 877

On 08/11/16 11:00, S Eno wrote:

Perform the following steps to resolve the issue:

1. Add |nsmb.conf |to |~/Library/Preferences/| with the following details: |[default] smb_neg=smb1_only|
2. Set *Other-Networks* and *Static IP address* in *Network Preference*.
3. Connect to |smb://pathname|

This file has changed in Sierra, smb_neg is no longer an option. Instead there is protocol_vers_map, but you can only disable SMB v1, or SMB v1 and v2, not enforce v1 only.

I thought maybe it was Kerberos (not that you can disable that directly either), but logging in as a different user (via smb://user:*@filer/share) has the same problem.

I fired up Wireshark on the client and you can see it pausing when checking file access permissions, 2 seconds between each directory when it gets a STATUS_ACCESS_DENIED response. For admin users who can read all directories, it's quick, but for regular users who don't have access to most you see the delay.

Setting kloglevel=2 in nsmb.conf shows the permission denied responses, but there's nothing else indicative of the problem.