MacOS Best Practices

Overview

This document outlines the standard settings for Apple’s macOS with the Nasuni Edge Appliance for general configuration and for performance.

The Nasuni Edge Appliance provides file sharing services to the macOS operating system versions 12 (Monterey), 13 (Ventura), and 14 (Sonoma).

Note: The name of the Macintosh operating system changed from “Mac OS X” to “macOS” with macOS version 10.12 (Sierra). This document uses “macOS” to refer to both macOS and Mac OS X.

Nasuni Configuration for macOS clients

The following are suggested configuration choices for macOS clients:

• For all shares that macOS clients access, enable “Enhanced Support for Mac OS X”. This option enables the “AAPL SMB2 create context” for SMB connections to the share. The “AAPL SMB2 create context” adds special handling for the macOS client’s SMB connection protocol, similar to the native SMB sharing implementation in macOS, which improves directory listing performance and compatibility with Mac applications .

• For all shares that macOS clients access, use the Block files configuration within Advanced Options to block .DS_Store files.
   
  Blocking .DS_Store files improves the performance for macOS clients, removes the potential for conflicting .DS_Store files when remote access is used, and does not generally impact macOS functionality. See Disabling the Attributes Store File Setting (.DS_Store).

Note: It is important to block such files before any clients connect to the share, and before migrating any content to the share. If you block such files on a share that already contains .DS_Store files, users experience problems moving or deleting folders that contain .DS_Store files. If .DS_Store files already exist on a share, block these files on the primary share, configure a second share that does not block these files, and use a script to remove the .DS_Store files from the primary share. After the .DS_Store files are removed, delete the administrative share.

Note: If you do block .DS_Store files, decompressing zip archives containing .DS_Store files to the Nasuni share fails. Also, earlier versions of macOS .PKG files are blocked from the share.

SMB connections dropping

Intermittent dropping of SMB connections can occur on some macOS clients. When the SMB connection is dropped, the server is no longer accessible from the client, and users must manually reconnect to access their SMB shares.

These issues are not specific to Nasuni or to SMB. Similar issues occur with AFP Shares and with SMB shares provided by Windows File Server and other platforms. However, SMB connection stability has been a recurring issue for Mac clients. Nasuni has identified certain settings that could help with the issues. Normally, none of these settings need to be adjusted. Only change settings from the defaults if SMB connection dropping occurs.

Disable the Power Nap macOS Energy Saver setting

Disabling the Power Nap Energy Saver setting can help with drops that happen overnight or after long idle periods.

Power Nap is designed to permit a Mac computer to check for email, calendar, and other iCloud updates while sleeping. The switching between states for these modes has been correlated with dropped connections to network drives in some cases.

Users can disable Power Nap by navigating to System Preferences  Energy Saver and unchecking the box labeled "Enable Power Nap". If the Mac is a laptop, this setting exists for both the Battery and Power Adapter profiles, so disable it in both places.

Ensure that Kerberos Tickets are renewable

If users report an issue with SMB connections dropping while they are working, and the SMB connections drop after 10 hours, investigate the state of Kerberos tickets on the affected clients.

Mac clients depend on Kerberos tickets to authenticate with a Nasuni Edge Appliance using Active Directory or LDAP. By default, Kerberos tickets are valid for 10 hours. Also, Kerberos tickets support a "renewable" flag (if requested by the Mac client) that allows the Mac client to automatically renew the ticket for another 10 hours after the ticket expires. Renewal is generally allowed to be repeated over the course of 7 days, ensuring that the Mac always has a valid Kerberos ticket for the connection.

If the Kerberos ticket expires and cannot be renewed, either because renewal isn't allowed by KDC policy or because the ticket has exceeded the default renewal maximum of 7 days, then the SMB connection drops. In that case, the user must attempt to reconnect to the server, which initiates the process to obtain a new Kerberos ticket.

The "klist" Mac terminal utility provides visibility into Kerberos tickets, when they expire, and whether they are renewable. Here are examples of “klist -a” output for healthy and problem environments:

Two root causes are observed for Kerberos renewal problems:

• The Mac client is not requesting renewable tickets, which depends on how Mac clients are configured to obtain Kerberos tickets. Mac clients using Active Directory automatically renew Kerberos tickets, and usually do this correctly.
  JAMF Connect/NoMAD and Apple Enterprise Connect are two other frameworks that are used to provide Kerberos tickets to their end users. It has been observed that Apple Enterprise Connect could be configured incorrectly and might not request renewable tickets for Mac clients.

• The customer has changed Kerberos KDC settings from the defaults, so that either renewal is not allowed or that expiration is much shorter than the defaults. In most environments, the Kerberos KDC is an Active Directory Domain Controller. This article describes how to confirm the Kerberos settings using the Group Policy on the Windows Domain Controller.

Enable macOS Server Performance Mode

If users report that SMB connections drop while they are actively working with files on the SMB share, then enabling Server Performance Mode might be the best setting to try. By default, macOS is tuned to favor application performance over background networking processes, including connections to SMB shares. This weighting can cause instability or connection drops under heavy application load.

This Apple support article describes how to configure Server Performance Mode. Changing this setting requires Administrator access and requires a reboot to be effective. Even though this article refers to macOS Server, the guidance is also valid for macOS clients. Apple does not fully specify which system tunables change when Server Performance Mode is enabled, but this article covers some of the settings.

Server Performance Mode might be particularly helpful for video editing applications, such as Final Cut X and Adobe CC Applications, because these applications are very demanding and are more likely to dominate the networking processes that the SMB connection requires. Even though the nature of the setting seems to indicate that application performance could be lowered to accommodate network or system processes, users have not reported this. Some users have reported better SMB performance, in addition to greater stability, after enabling Server Performance Mode.

*.DS_Store conflict files with remote access

If *.DS_Store files are not blocked on the client or server side, and a volume is enabled for remote access, .DS_Store files can result in conflicts within folders.

To prevent conflicts, or to resolve the issue after it occurs, remove the conflict files, and perform these procedures:

• Change the macOS client .DS_Store handling. Apple HT208209 has more information on this setting and how it works. Depending on the macOS version, the setting works in different ways:

  • On 10.13, the Finder no longer creates .DS_Store files on network volumes, and also ignores them when listing folder contents on network volumes.

  • On 10.14 and higher, the files are still created by clients, but any client with this setting enabled ignores them when listing the contents of a directory, greatly speeding up directory listing.

• Configure server-side, share-level blocking of .DS_Store files. Blocking .DS_Store files improves the performance for macOS clients, removes the potential for conflicting .DS_Store files when remote access is used, and does not generally impact macOS functionality.

Note: It is important to block such files before any clients connect to the share, and before migrating any content to the share. If you block such files on a share that already contains .DS_Store files, users might experience problems moving or deleting folders that contain .DS_Store files. If .DS_Store files already exist on a share, block these files on the primary share, configure a second share that does not block these files, and use a script to remove the .DS_Store files from the primary share. After the .DS_Store files are removed, delete the administrative share.

Listing and Removing *.DS_Store files (including conflicts)

When removing .DS_Store files from a Nasuni share, you need two shares: the primary share that end users access, and a secondary share that you use with the following script to remove .DS_Store files.
On the primary share, edit the “Block files” configuration within the “Advanced Options” section to block “*.DS_Store” files. This prevents end users from creating new .DS_STORE files, and prevents them from accessing existing .DS_Store files.
Finally, create a secondary share for the same path as the primary share, but do not configure the “Block Files” option for this share. This share should not be accessed by end users and is only used in conjunction with the cleanup script below. Using the secondary share that does not have the “Block Files” setting allows the script to see and remove .DS_STORE files. When you are done running the cleanup script, you should delete the secondary share.

There are several ways to remove .DS_STORE files from the share, but using PowerShell supports the long filenames and paths that are possible when Mac clients are used with a Nasuni share. The following software versions are required:

• Windows Management Framework 5.1

• .Net Framework 4.6.2 or more recent

• Windows 10 / Windows server 2016 (Build 1607 or newer) \

The following command must be executed in an administrative window of PowerShell to enable long paths for PowerShell:

Set-ItemProperty 'HKLM:\System\CurrentControlSet\Control\FileSystem'
-Name 'LongPathsEnabled' -value 1

After satisfying these requirements, perform the following procedure to list .DS_Store files:

1. Mount the secondary Nasuni share as a drive letter on a Windows client.

2. Open PowerShell and execute the following command, replacing "C:\longpath" with the path that you mapped in step 1. The "\\?|" at the beginning of the path argument is required in order to support long paths:

get-childitem -literalpath \\?\C:\longpath
-Filter "*.DS_STORE" -Recurse | Remove-Item -WhatIf

This loops through the specified path, looking for files matching ".DS_Store", and passing them to the Remove-Item cmdlet with the
"-WhatIf" argument that lists the action that the cmdlet would perform, without actually performing it.

Perform the following procedure to remove .DS_Store files:

1. Mount the secondary Nasuni share as a drive letter on a Windows client.

2. Open PowerShell and execute the following command, replacing "C:\longpath" with the path that you mapped in step 1. The "\\?|" at the beginning of the path argument is required in order to support long paths:

get-childitem -literalpath \\?\C:\longpath
-Filter "*.DS_STORE" -Recurse | Remove-Item -Force

This loops through the specified path, looking for files matching ".DS_Store" and, since the "-WhatIf" argument is missing, the Remove-Item operation fully executes.

Errors saving from Adobe Illustrator CC 2020

Users of Adobe Illustrator CC 2020 have reported intermittent issues saving to Nasuni. When they attempt to save, they get the error: "The specified network location is unavailable. Check your network connection and/or save your file to a different location." This appears to be an issue with SMB servers and Illustrator 2020.

In Illustrator’s Preferences, in the File Handling section, disable "Optimize File Open and Save Time on Slow Networks (Beta)".

Errors using Adobe Bridge for metadata tagging

Customers have reported that recent versions of Adobe Bridge (CC 2019) are unable to update metadata on server-based mount points (including Nasuni). A confirmed workaround restores this functionality.

On Adobe Bridge, click the "Adobe Bridge CC 2019" menu to the right of the Apple menu. From the dropdown menu, select "Camera Raw Preferences". On the Camera Raw Preferences dialog box, find the section labeled "JPEG, HEIC, and TIFF handling". Change the setting for JPEG/HEIC from "Automatically open JPEGs and HEICs with settings" to "Disable JPEG and HEIC support". Close the Camera Raw Preferences dialog box by clicking OK in the top right of the window.

Clear the Adobe Bridge cache, quit Adobe Bridge, and try again. Setting metadata through Adobe Bridge should now work.

Blocking “dot underscore” files for CIFS shares breaks saving for some files

“Dot underscore” or “dot bar” files (files that begin with "._" followed by the name of the file) are an annoyance for some Mac admins, and we have seen instances where they attempt to use the Block Files advanced share setting to block them.

However, dot underscore files are used by the “Enhanced Support for Mac OS X Clients” share-level feature for the storage of the com.apple.FinderInfo and com.apple.ResourceFork ADSs (Alternate Data Streams), and blocking them causes saves to fail for files that contain either of these. Usually, this gets reported as applications like Adobe Photoshop being unable to save. While it is safe to block .DS_Store files, dot underscore files are necessary for Mac operations, and they must not be blocked.

Removing "._*" from Block Files resolves this issue.

Permissions

NTFS Permissions Best Practices for Mac Clients

There is a known NTFS permissions problem that can result from accessing SMB shares (regardless of server vendor) from a macOS client bound to Active Directory using the built-in macOS Active Directory integration functionality.

Macs with this configuration have been observed to add or remove NTFS permissions and to break inheritance during routine operations such as duplicating folders or copying files that have existing permissions from local storage or another SMB share. These change to NTFS permissions could break access for the connected client or other clients accessing the share.

This permissions problem has not been observed with Macs that are not bound to Active Directory or when Active Directory/Kerberos integration alternatives such as Apple Enterprise Connect or JAMF Connect (formerly NoMAD) are used in lieu of Active Directory binding.

Fortunately, two settings exist to mitigate this known issue. Ideally both settings should be applied for full mitigation of the underlying issue, although setting 2 requires the Nasuni 8.5 release.

• Setting 1: Restrict NTFS Full Control Permissions (compatible with all Nasuni releases)

The NTFS Full Control permission should not be used for folders and files associated with macOS shares. The NTFS Full Control permission includes the "Change Permissions" right, and can allow for accidental permissions changes.

Instead, use the Modify permission, or select Advanced permissions and then uncheck the “Change permissions” and “Take ownership” boxes. This prevents macOS clients from inadvertently changing their permissions on save.

Nasuni also recommends restricting Full Control permissions to a specific service account that you explicitly create to manage file permissions, rather than a general-purpose group such as Domain Admins or IT Department. That helps prevent members of these groups from accidentally manipulating permissions when creating folders and files via the Finder or an application.

• Setting 2: Use the Owner Rights Windows Well-known SID to Limit Permissions for Owners (Supported in the 8.5 Nasuni Release)

Restricting NTFS Full Control Permissions to a service account, or to a select group of administrator accounts, as outlined in Setting 1, is generally effective to prevent permissions corruption, although an issue with the rights implicitly granted to owners of files or folders in NTFS can cause problems if the owner attempts an operation (such as duplicating a folder or file) that can impact permissions.

The owner of a folder or file in NTFS can always change permissions on the object, regardless of its permissions. Even if the ACL list does not contain any permissions entries, the owner is still able to change permissions. The behavior of the owner principal is implicit in NTFS and is by design.

Beginning in Nasuni version 8.5, shares with the “Enhanced Support for the Mac OS X” share setting are now compatible with the Windows "Owner Rights" well-known SID to give administrators the ability to limit the permissions that NTFS Owners are implicitly granted. The “Owner Rights” well-known SID can be used on volumes with either the “NTFS Compatible Mode” or “NTFS Exclusive Mode” Permissions Policy.

The “Owner Rights” well-known SID was first introduced by Microsoft in Windows Server 2008 to limit the default behavior of NTFS owners. When used in conjunction with Nasuni permissions best practices, adding the "Owner Rights" well-known SID to the NTFS ACLs with Modify rather than Full Control permission, owners can no longer change NTFS permissions. When the Owner Rights well-known SID is applied and set to Modify, duplicating folders and files on a Nasuni share, or copying files and folders from another server or the Mac desktop, complete without error, and permissions inheritance is not broken.

Adding the Owner Rights Well-known SID using Windows Explorer:

An example of NTFS Permissions with Owner Rights applied:

Note: The Owner Rights well-known SID is incompatible with the version of “Enhanced Support for Mac OS X” that was included in Nasuni versions before 8.5. Adding the Owner Rights well-known SID to the NTFS ACLs to folders and files on a pre-8.5 Nasuni Edge Appliance breaks folder creation for connected clients.

Resetting Permissions on Move

When a Mac SMB client uses the Finder to move a file or folder within a share, the permissions from the source location move with the file or folder, and are not reset to inherit permissions from the target location during the move. This is a difference between Mac and Windows clients. When a Windows client (Windows 7/Server 2008 or newer) uses Windows Explorer to move files or folders from one location to another, the permissions are reset to inherit from the target location.

However, resetting permissions on a move to inherit from the target can be helpful for environments where permissions inheritance is utilized to enforce permissions. For environments that do depend on permissions inheritance and must support move operations, it is a best practice to use one set of permissions at the top level of the share and to avoid unique permissions for subfolders and files. If unique permissions are required for folders and files, it is best to implement a new share. Then, when data is moved between shares, each with unique permissions, the permissions are reset to inherit from the target folder and are not preserved.

Note: Copy operations are distinct from move operations in this regard. Copied files always receive the inherited permissions of the target directory.

A good Microsoft Blog post explains this behavior and why it varies based on the client version or OS.

Additional NTFS Permissions Best Practices

Using inherited permissions with macOS clients is recommended to avoid issues that can arise when path length exceeds the limits imposed by native Windows tools such as Windows Explorer or cacls (260 characters).

“.TemporaryItems” folder

The ".TemporaryItems" folder is a hidden folder that Mac clients create at the root of all shares. Mac users must have at least Modify permission or Full control minus “Change permissions” and “Take ownership” to this folder for certain operations to complete. Mac applications use this folder for temporary storage and not having appropriate access to this folder can break file saving or zip archive expansion. Active Directory-bound Macs create per-user folders within ".TemporaryItems" based on the Active Directory user ID. Some issues with the ".TemporaryItems" folder only occur when Mac clients are bound to Active Directory.

If explicit permissions are required for long paths, Administrators can set them using PowerShell with long path name support, included in the latest versions of Windows 10 and Server 2016. Optionally, third-party utilities, such as SetACL Studio from Helge Klein, also support setting permissions for files and folders that exceed the Windows default path limit.

Viewing and Setting NTFS Permissions

Unlike Windows clients that list the NTFS User or Group permissions of an Edge Appliance or folder through the Windows Explorer properties, the Mac Finder does not list specific User or Group permissions. Instead, the Mac Finder shows a message that "You have custom access."

The macOS Finder does not correctly display Windows Access Control Lists for mounted SMB shares. This limitation is inherent in macOS and impacts other NAS devices and Macs connected to Windows file servers.

While the permissions are not displayed properly in the Mac Finder, they are enforced properly by Nasuni. That is because, per the SMB protocol, the permissions enforcement is done by the SMB Server, in this case Nasuni, and does not depend upon the client to enforce permissions.

Note: While the macOS Finder does not show NTFS permissions, they are visible through the macOS Terminal if the Mac client is bound to Active Directory, albeit in a limited form. In order to view the information, use the following syntax with the ls command.

ls -le

Because of the lack of Full Native support for Windows ACLs in macOS, an administrator must use a Windows system to set NTFS permissions.

CIFS Protocol best practices

On the NMC, under Filers → CIFS Settings → CIFS Settings dialog box, the Protocol Level should be set to "CIFS & SMB3". This is now the default for new Nasuni Edge Appliances deployed since version 7.2. The other available Protocol Level options can cause performance and stability problems for Macs.

End-User Mac Guidance for Nasuni and SMB

Mac Compatibility with SMB

Nasuni supports both SMB 2 and SMB 3 for connected Mac Clients. Apple added compatibility for SMB signing in macOS 10.11.5. SMB signing for Mac Clients is supported, if negotiated by the client. There is no customer-facing setting to require SMB signing for the server or share. If SMB signing is required, contact Nasuni Support.

Connecting to Nasuni shares

To connect to a SMB share on a Nasuni Edge Appliance, use the Connect to Server feature of the Finder. With the Finder selected, select Go  Connect To, and enter the fully qualified DNS name for the Edge Appliance in the connection dialog.

Note: Always use smb://FQDNofEdgeAppliance to connect. Using an IP address, rather than the FQDN of the Edge Appliance, to connect breaks Kerberos SSO for connecting clients.

Note: Never use CIFS:// to connect. The Mac implementation of the CIFS protocol has performance, security, and application compatibility concerns that make it undesirable.

Column View False Locking Issues (most macOS versions)

Nasuni recommends against the use of the macOS Finder Column view. An interaction between the Finder’s Column view and the Finder's Quick Look feature can cause issues, including difficulty saving files to SMB shares.

Note: The error message from the Finder might state that the user does not have permissions to save the file. The actual lock issues are caused by Column View and Quick Look, and are not permissions issues or the result of a write lock by another user.

The following are best practices to use:

• The Finder’s Quick Look feature can cause issues when saving files. Avoid using Quick Look.

• If users are having problems saving files because the operating system or application says that the file is locked or read-only, try the following:
  1) Close all Finder windows or
  2) Select another folder in the Finder, then try saving the file again. If this resolves the issue, have users leave the Finder window open, but use List View instead of Column View. This procedure works because Column View uses Quick Look, but List View does not use Quick Look.

Column View with nested directories

Nasuni recommends against the use of the macOS Finder Column view. When you use Column view with nested directories, the Finder Column view refreshes the directory tree recursively whenever any metadata changes. This can result in a condition of continuous attempted loading, which can obstruct other operations. This situation is worse with large numbers of directories, or “wide” trees with many directories at the same level.

The following are best practices to use:

• The Finder’s Column view can cause performance issues with nested directories. Avoid using Column view.

• List view solves this issue and is a workaround.

Directory Rename or Moves Blocked by Read or Write Locks

If a client has an open file within a directory, or the directory or parent directories are renamed by another client, MacOS Applications lose track of the file’s path, causing problems on save. When attempting to save, the application might prompt the user for a new directory, exit unexpectedly, or result in a state where the user is unable to save changes. Adobe Photoshop is particularly impacted by renames or moves, and these changes usually result in a state where the user is unable to save changes.

To prevent this behavior, shares with “Enhanced Support for Mac OS X” enabled automatically block directory renames or moves if a client has a read or write lock within the folder or its children.

Note: Please be aware that false locks from the Finder or the Finder Quick Look process used to generate icon previews are indistinguishable from valid Application initiated locks and can also prevent directory renames or moves.

In addition, it is possible to allow renaming or moving a directory, even if there are open files in that directory or in a subdirectory. If this option is required, contact Nasuni Customer Support.

Guidance for Spotlight and Mac Finder Searches

Spotlight searches in macOS depend on a server-side index in order to quickly return search results to clients. However, the Nasuni Edge Appliance does not currently support the server-side generation of a Spotlight-compatible search index. Instead of Spotlight, Mac users should use the Mac Finder's search functionality to perform searches of Nasuni shares.

When using the Mac Finder search, it is important to first navigate to the top-most folder relevant for the search, but not any higher, so that the scope of the search is limited. Searching from the top level of a Nasuni share, especially a share with thousands of folders and files, is slower than a folder-focused search, because the Mac Finder must search the content of every item in the tree. Apple publishes guidance on using the integrated Mac Finder search, and how to focus searches, here: https://support.apple.com/kb/PH25589?locale=en_US

Mac Troubleshooting and Administrative Guidance

Windows Client Interoperability Recommendations

macOS clients are capable of working with filenames and file paths that exceed the limits imposed by the Windows OS (including blocked characters in the NTFS such as ‘/’, ‘?’, ‘<’, ‘>’, ‘\’, ‘:’, ‘*’, ‘|’, and ‘ " ‘ ), and the Nasuni Edge Appliance allows macOS clients to create and edit long file names and paths without restriction.

This can create problems for Windows clients that lack support for long paths and illegal characters. If Mac and Windows clients need to access the same files, Administrators and Users must be careful to observe Windows naming conventions and path limitations.

Finder Color Tagging is Broken

Users might report that they are unable to use the Mac Finder to set single or multiple color tags for folders or files stored on a Nasuni SMB share. If this is reported, make sure that "Enhanced Support for Mac OS X” is enabled for the share. If "Enhanced Support for Mac OS X” is not enabled for the share, color tagging is not fully functional.

Warning about “Permanent Version Storage”

When mounting a network drive, or during save operations, the macOS Finder, and some macOS Applications provided by Apple (such as Keynote, Numbers, and Pages), might show a warning that the document is “on a volume that does not support permanent version storage” and that “You will not be able to access older versions of this document once you close it”.

According to Apple KB HT203598, this behavior is expected when saving to some network volumes (such as AFP, SMB, and NFS), and users should either ignore this message or check the box to “Do not show this message again.”

Nasuni still preserves previous versions of saved documents. macOS clients can access shared versions directly (through Web Access). Administrators can also restore previous versions for Mac users by using the NMC File Browser or Edge Appliance File Browser.

Gray Files in the Mac Finder

Customers occasionally report that the Mac Finder does not open a file, and the filename and properties appear as gray in the Finder, rather than black. The Mac Finder implements a "File Busyness" mechanism to mark files as in-use during copy operations so that other clients cannot access the file until the operation completes.

While the copy is in progress, the Mac Finder sets the file creator code to "MACS" and the type to "brok". The file create date might also be set to Jan 24, 1984 3:00 AM. If, for whatever reason (usually if I/O is interrupted during save), the Mac leaves either of those attributes set after a file copy or save action, the file appears gray to Mac clients. Windows clients are unaffected, and NTFS permissions are also okay.

Here is an example of the ADS (Alternate Data Stream) for a file that has a matching creator and type code:

[macbookpro08:~] xattr -l /Volumes/FAT32/example/bigfile.dmg

com.apple.FinderInfo:

00000000  62 72 6F 6B 4D 41 43 53 00 00 00 00 00 00 00 00  |brokMACS........|

00000010  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  |................|

00000020

Removing the AFPInfo ADS clears this flag. Here's how to do this using the mac terminal:

xattr -d com.apple.FinderInfo <filename>

where the filename is substituted without the brackets.

The touch command can be used to correct the 1984 creation date issue. For example:

touch -t YYYYMMDDhhmm <filename>

Substitute the desired timestamp for YYYYMMDDhhmm and substitute the filename without the brackets.

Dropbox

On macOS platforms, if Dropbox is installed, Dropbox might interfere with accessing certain folders. Try disabling all other Finder Sync extensions (under System Preferences  Extensions  Finder).

Disabling the Attributes Store File Setting (.DS_Store)

Apple uses a hidden file (.DS_Store) to store the custom attributes of a folder. By default, the Finder creates a .DS_Store file in every folder that it accesses, which can affect performance in the Finder window. Disabling the .DS_Store setting can improve performance when browsing SMB shares. For further information, see https://support.apple.com/en-us/HT208209.

To disable the .DS_Store setting, follow this procedure:

1. Click the Terminal.
   

2. Execute the following command:

   defaults write com.apple.desktopservices DSDontWriteNetworkStores -bool TRUE

3. Restart the Mac.

Improve Performance by Disabling SMB Packet Signing

Beginning with macOS version 10.11.5 (El Capitan) and ending with macOS version 10.13.4 (High Sierra), SMB Packet Signing is enabled by default when connecting to SMB volumes. Newer versions of macOS (10.13.4 and newer) ship with SMB Packet signing set to optional rather than required.

In certain situations, such as workflows involving large files or large quantities of files or high latency transfers, Apple’s SMB packet signing implementation can degrade client SMB performance.

Apple provides the following procedure to disable SMB Packet Signing for macOS clients by adding a setting to /etc/nsmb.conf: https://support.apple.com/en-us/HT205926.

Note that disabling SMB Packet Signing means that SMB traffic between the Nasuni Edge Appliance and macOS clients is no longer encrypted. Therefore, before disabling SMB Packet Signing for clients, consider your network topology and security posture.

macOS Migration Guidance

Existing AFP-based macOS shares or older SMB shares might contain legacy content that is not required for the SMB protocol. To speed migration and reduce file overhead when performing data migrations, consider excluding these files. Excluding certain files might cause a loss of functionality:

Migration Issues

Acronis File Connect Robocopy Migration Fails with Access Denied

When using robocopy to migrate files from a Windows Server running Acronis Files Connect, the robocopy to Nasuni may fail with access denied errors. A similar copy using Windows Explorer should succeed. Acronis Files Connect adds an Alternate Data Stream (ADS) named GLIAFP_Mapping to the root level folder of each Acronis AFP share. This ADS is typically larger than the 64K maximum ADS that Nasuni supports.

Acronis provides the following info on the GLIAFP_Mapping ADS:

The most important secondary stream used by Files Connect is called "GLIAFP_Mapping"; this stream is used to store the mapping between NTFS file IDs and Mac file IDs. It is located in the topmost directory of a Mac share. For example, if you were sharing the directory, "D:\Macintosh Files" as a volume for Macintosh users, then Files Connect would create an invisible NTFS secondary stream in this directory.

Workaround options:

• Use the Acronis delstream utility to remove the GLIAFP_Mapping ADS. This only works if Acronis is still installed, because delstream is an Acronis utility. For instructions, see Deleting ExtremeZ-IP Volume Streams.

• Use PowerShell on the Windows server (requires PowerShell 3.0 or newer) to replace the contents of the GLIAFP_Mapping ADS with a small dummy/placeholder entry that does not cause an error with robocopy. Here’s an example script that does that:

#provide the path to the folder containing the GLIAFP_Mapping ADS

$path = "Z:\Shares\Design"

$streamName = 'GLIAFP_Mapping:$DATA'

$GoodStream = "smallEnoughToCopy"

set-content -path $path -Value $GoodStream
-stream $streamName

Copyright © 2010-2024 Nasuni Corporation. All rights reserved.