After upgrading to macOS 10.13 High Sierra or later, a client might not correctly read files from NFSv4 servers created with previous versions of macOS or OS X: If you have used older versions of the operating system to write Macintosh files to an NFSv4 server, and the server implementation supports named attributes, and the files are using Extended Attributes or forks, these attributes and forks will become temporarily inaccessible after upgrading to macOS 10.13 High Sierra.
Workaround: This is a documented policy change in Apple’s NFSv4 client for High Sierra. If you like to continue using named attributes over NFSv4, you will have to enable a new NFSv4 mount option on each client. This option is called Enforce extended attributes and named forks if supported by server in NFS Manager. For Apple’s documentation, enter the command man 5 nfs in Terminal.
If you add automount triggers to the Finder sidebar, the Finder may intermittently remove them: In case your system is configured to use NFS automounts, a user may drag the topmost folder of the automounted file system or an object from that hierarchy into the Favorites section of the sidebar of a Finder window. This way, the automount can be triggered easily, without needing an additional alias object on the Desktop. The Finder might unexpectantly lose such sidebar entries, however.
Workaround: This is a known issue of the Finder. The user has to re-create the sidebar entry. At this moment, no other workaround is known. We hope that Apple will resolve this problem in future versions of macOS.
When using a server running macOS to host home folders for users, a user running a different version of macOS as client for the home folder might experience gradual data corruption in the Address Book database or complete loss of this database: If you have configured an macOS computer to host home directories for network users, and users on client computers run a version of macOS different from that of the server to access their network homes, the server version of Spotlight can severely damage the users’ Address Book databases. (For example, when the server is running Mac OS X 10.6 Snow Leopard and the client is running OS X 10.11 El Capitan.) This can lead to gradual destruction of the Address Book entries until total loss of the entire database occurs. Address Book clients, e.g. applications such as Apple Mail, iCal, Safari, or the macOS Spell Checking Service may also fail as a consequence, causing freezes or crashes.
Workaround: Apple is aware of this problem for a very long time. This problem affects all file service protocols (such as AFP, NFS, or SMB). You should avoid mixing servers and clients of different versions of macOS, OS X or Mac OS X in one network. With Mac OS X 10.7 and later (on the server), you can also use the internal user account _spotlight together with Access Control Lists on the server to control which parts of the file system should be readable and writable by Spotlight.
After you copy downloaded files onto an NFS server, macOS may reject an attempt to open such files at a later time for certain file types: If you download a file with macOS and then store the file by a subsequent copy operation to a location on an NFS file server, you may not be capable of opening the file later. Instead, macOS displays the erroneous error message “file name is damaged and can’t be opened. You should move it to the Trash.”
Workaround: Apple is aware of this problem. It affects all file server protocols that emulate extended attributes. Direct write operations (e.g. saving a downloaded file into a folder Downloads on an NFS server) are not affected, but only subsequent copy operations (e.g. from the Downloads folder to a different folder). There are two possible workarounds: (1) Copy the file to the local hard drive of the computer before opening it. (2) Delete the attribute marking the file as download, by entering the command xattr -d com.apple.quarantine path where path must be replaced by the path of the affected file. If the file is actually a bundle (e.g. an application), use xattr -d -r com.apple.quarantine path.
Some applications cannot process files on an NFS server if those files have not been created using the identical file service protocol: If you write a Macintosh file with Extended Attributes or forks to an NFS server using a different protocol (like AFP, or SMB, or a different NFS standard like NFSv3 vs. NFSv4, or by creating this file directly on the server writing it to the local hard disk), you may later have problems opening this file. Each file sharing protocol uses different techniques to handle Extended Attributes. Those techniques are not compatible with each other, so you cannot write a file with attributes using one protocol but read it with another protocol.
Workaround: You should avoid using different file server protocols at the same time when reading and writing Macintosh files with Extended Attributes. Even when you only use NFS, you must take care either not to allow simultaneous access via NFS3 and NFSv4, or to enforce matching options for the use of named attributes on all clients.