macOS supports a high number of settings which can be defined for each mount. NFS Manager divides these settings into five areas:
Each of these areas is displayed in a tab view after the button Show advanced options has been pressed.
NOTE TO EXPERIENCED UNIX ADMINISTRATORS: Perhaps you know many of those options under their abbreviations (“option letters”) which are used on the command line. To make it easier for you to understand the settings, NFS Manager displays the option letters as help tags when the mouse cursor is held for some time over the corresponding entry field of each option.
Mount as read-only: When checking this option, each write operation to the share will be blocked even if the user would have write permission. The network volume behaves like a read-only disk, like a CD or DVD for example.
Ignore “set user-ID” privileges: If this option has been set, the special permission markers SUID and SGID will no longer be respected for files from the server. If a program on the server has been flagged with such settings, macOS would otherwise be forced to execute the program under the name of a different user or different group when the program is started, without any password entry necessary. This could even be the highest system administrator root. Because this could create a serious security hole, it is recommended to leave this option active.
Ignore Unix device files: Each Unix file system contains special files which allow direct access to devices. Those files are usually stored in the folder /dev. After enabling this option, access to such files will be blocked.
Ignore ownership: When checking this option, the owners and group owners of files on the share will no longer be respected. Instead, the volume will be handled like a removable drive. In this case, the user which has triggered the mount operation will become the effective owner of all files.
NOTE: Although macOS is respecting this option in general, there can be cases where macOS decides for security reasons not to let this setting become effective.
Don’t allow execution of programs: This function can be used to prevent the client from executing programs stored among the shared files. This is recommended when the programs are known to be designed for the server only and the server uses another processor type or even a different operating system than the client. macOS would not “understand” such programs.
Don’t update file access times: In many operating systems, an attribute is stored for each object which keeps information when this object has been accessed the last time. If this option is enabled, those attributes will no longer be updated when accessing data on the NFS server.
Overlay contents with mount point folder: If the folder used as mount point contains local files already, those objects will be temporarily hidden while the connection to the NFS server is active. Alternatively, the files can be integrated into the data coming from the server, i.e. the folders seem to mix. This mode of operation is also called Union Mount. The following rules apply: When files or folders are newly created, they will be stored on the NFS server. When an object is accessed, it will first be attempted to open it on the server. If it doesn’t exist there, the local file system will be accessed.
Hide in Finder: When activating this option, the mount point won’t be displayed in the Finder or similar graphical file system browsers. This is useful for “internal” data which should only be used by the operating system, but should be hidden for normal users.
Enforce display in Finder: Some versions of macOS follow the built-in policy never to display any automatic NFS mounts in the Finder, even if the aforementioned hide option has not been set. If your system is affected by this problem and you like the Finder to handle the automount like a normal disk volume, enable this option.
Don’t enforce server operations to be performed asynchronously: In asynchronous mode, the server is allowed to confirm a successful write operation of data to the client, even before the server can be sure that the data has actually been written (e.g. when it has no positive confirmation from the hard drive units yet). This way, the client doesn’t have to wait for the server. Operations become faster, but there is the risk of undetected data loss because the client can never “know” if the data has actually been stored. If this item is checked, the server can in no case be forced by the client to switch to asynchronous mode. Whether a given connection is indeed operated asynchronously will then depend on other default settings of server and client.
Wait until the server has executed each operation (synchronous mode): Checking this item causes the connection to be operated synchronously. When the client executes a write operation on the server, it must wait until the the operation has successfully completed. This avoids the risk of undetected data loss. The speed will drop, however.
Allow hanging operations to be canceled without server response: This option controls how the client should behave when the connection to the server fails while an access operation is running. Under normal circumstances, the operating system of the client will monitor the connection and stop all affected file operations until the connection has been reestablished. This way no data can be lost. If the server hangs however, all connected clients will automatically hang, too. After checking this field, the client operating system will be allowed to cancel all applications which are affected by the server failure. When the user activates the Force Quit function of macOS to cancel the programs, all data currently transferred will be lost but the client can continue.
Allow operations to fail if server doesn’t respond (“soft” mode): If the client experiences a connection problem, it will usually retry endlessly to retransfer the data until the connection is restored. If this option is enabled, access will be canceled after a certain number (see below) of retries, and the client will display an error message that the network volume is not working correctly. Such a mount is also called to be soft.
NFS protocol version: This option sets the version of the NFS protocol which should be used for the mount. The recommended setting Detect automatically will cause the client and server to negotiate the best version. If compatibility issues arise with servers of third-party vendors, it could help to switch back to an “older” NFS version.
Internet protocol: The option controls which versions of the Internet protocol should be allowed for this mount. The recommended setting Detect automatically will cause the client to choose the protocol based on the way you have specified the server. The options IPv4 addressing only and IPv6 addressing only will force the client to select IPv4 or IPv6 communication only.
Transport protocol: permits the setting whether the protocols TCP or UDP should be used to transport data. By default, the connection type will be negotiated automatically. At first, TCP will be tried. If the server does not support this, UDP will be used. The additional option Use UDP during mount phase can enforce that UDP must be used for the initial mount request, even if both communication partners will use TCP for the actual data transfer later.
Server uses non-standard port or has multiple interfaces: This must be checked if the server does not use the NFS default port 2049, or if it has multiple IP addresses or network interfaces. This will avoid that the UNIX function connect will be used to establish a UDP socket connection.
Use privileged source port number below 1024: This option is equivalent to the option Use secure communication ports in the short overview of mount options. Due to the special security model of NFS, some operating systems —Linux for example— expect that accessing clients are only considered legit if their requests are sent from ports which are usually reserved for operating system services only (i.e. the requests must not come from normal applications). Those reserved ports have port numbers less than 1024. If you access such a protected system, you must leave this option checked, otherwise all access attempts will be rejected as invalid.
Use specific mount port number: This will enforce that the mount request will be sent to a specific port of the server. A value of 0 means that the port number should be selected automatically.
Use specific NFS port number: This option controls the port number for the actual data transfer to the NFS server. Compliant with the industry standard, the usual port number is 2049.
Retry in background after initial server contact failed: This setting controls the behavior in case the first contact attempt to the NFS server is not successful. If the mount is critical for operation of the client (e.g. because all private home folders are located on the server), the client should wait until the server responds. In that case, the client is basically stopped and “hangs”. If this behavior is not desired, you can enable this option to make the client continue its work, retrying in the background to contact the server.
Override default limit for retry attempts to: If the initial contact fails and the client is trying to connect to the server in the background, it will not endlessly repeat the contact attempts. macOS will give up after 10,000 retries. This option can be used to set a different limit. A value of 0 will select the default of the operating system.
Forcibly disconnect if reported unresponsive for __ s: If initial contact to the server succeeded, but later the server becomes unresponsive, macOS will display a “server does not respond” warning on the graphical user interface. You can additionally let macOS disconnect the unresponsive share after a certain amount of time has passed by checking this option and specifying a number of seconds. macOS internally auto-activates this feature when using a soft read-only mount, specifying a timeout of 60 seconds.
Don’t display as being unresponsive on jukebox errors: When checking this option, macOS will suppress warnings on the graphical user interface that an NFS server does not respond if the server sends a special message that it will need more time to access the requested data. This function should be used if the server might have to access very slow devices like a storage jukebox or something similar. The server must return either a jukebox error compliant with NFSv3 standards, or a delay message according to NFSv4 protocol.
When exchanging data between client and server, the currently transferred data for each connection will be held temporarily in main memory (“buffering”) to ensure fast operation even if short-term bottlenecks occur due to network overload or waiting for hard drives. The buffer sizes are usually negotiated automatically between client and server, but they can also be set manually. There are four different buffer sizes:
Read buffer size: size of the cache when reading files.
Write buffer size: size of the cache when writing files.
Folder read buffer size: size of the cache for reading folders.
Read-ahead buffer size: size of the cache the server is filling in advance when it expects access to subsequent data blocks.
There is no easy answer how to tune those sizes. Depending on network chips, network load, version of the server operating system, and version of the client operating system, increasing the values may sometimes increase the speed, sometimes the performance will drop. The optimal settings for communication between two given computers can only by found by trial and error.
Use ReaddirPlus NFSv3 feature: If using the protocols NFS version 3 or NFS version 4, there will be an alternative NFS operation to read the contents of folders. This operation has been optimized differently and tries to cache the attributes and names of objects more aggressively when scanning folders. This will reduce RPC traffic in some cases, however the caches will be flooded with many entries which can reduce performance in other areas.
Don’t estimate timeouts dynamically: After a communication problem has been experienced, a retry will be attempted after a certain time interval, which is estimated based on previous behavior. When checking this option, this estimation will be switched off. This can be useful for UDP mounts on an overloaded server which doesn’t respond immediately, so the usual estimates might be too small.
Set initial timeout to: After the dynamic estimation of wait intervals has been switched off by the previous option, this option can be used to set the initial wait time for retries manually, optimizing the mount operation on highly loaded networks or servers.
Set maximum number of retransmits: For a soft mount (see Allow operations to fail if server doesn’t respond) retransmission attempts will be canceled after a certain number of failures. This limit can be set by this option.
Security options: If client and server have been setup to use a Kerberos realm, the mount can be configured to ensure secure identification of users and computers and to enable data encryption. By default, the server is responsible to request use of a certain security feature. If the server offers multiple security mechanisms, this option on the client will control which feature should be used.
Disable NFS file locking: Up-to-date implementations of NFS support file locks to coordinate simultaneous access to shared data by multiple clients. Should compatibility issues arise, locks can be disabled by this option even if the server is offering locking features.
Lock on the client instead of on the server: If an old NFS server does not support file locks, the usage of locks can be enforced on the client side as a fallback solution. In this case, simultaneous access by several independent computers will still not be protected by locks, but multiple access by applications on the same client will be coordinated by lock operations.
NOTE: Even if not explicitly displayed in the application, the option Lock on the client instead of on the server will be automatically activated by macOS, when the options Mount as read-only and Allow operations to fail if server doesn’t respond have both been switched on.
Disable file system quota operations: All functions for file system quotas can be disabled by this option, even if the server is supporting the remote quota protocol. If the client attempts to use a quota feature, it will receive the error code for “feature not supported” from the operating system.
Process all names as Unicode Normalization Form C (NFC): When sending names to the server during NFS communication, enabling this option causes the client to use Unicode Normalization Form C as standard to encode the transferred characters. This can enhance compatibility with specific servers that expect this standard to be used for character encoding.
Limit number of groups in credential lists to: Because NFS implements a distributed file system, an NFS server has to check the permissions of the accessing user when that user is opening an object. According to industry standards, a user can be member of up to 16 different user groups which have to be checked when computing the group access privileges during NFS access. Some older NFS servers may not support such a high number of group memberships. If users who are members of many groups unexpectantly receive “permission denied” errors when accessing server objects, you should try to limit the number of group memberships which have to be tested to a smaller value.
Disable negative name caching: This will disable the temporary memory used to hold results that objects with certain names do not exist on the server.
Disable attribute caches: This will disable the temporary memory used to hold attributes of objects.
The following settings are specified separately for access to files and folders:
Set … cache minimum timeout:The time in seconds a read attribute should at least be held in memory until it expires and has to be fetched again from the server.
Set … cache maximum timeout: The maximum time in seconds a read attribute can be held in memory until it expires and has to be fetched again from the server.
Disable callback requests from the server and any associated features: Some particular features of NFSv4 require two-way communication, so the server may send callback requests back to the client. If this should not be allowed for some reason, it can be switched off by this option. Of course, this will also disable all features that require this sort of communication.
Disable extended attributes and named forks: NFSv4 server can offer features to support the storage of extended attributes for file system objects and files with multiple streams of data (“forks”). Because previous NFS versions did not support this and the use of such features might not be desired, this can be disabled even if the server is capable of supporting this. Note that the Finder of macOS makes intensive use of extended attributes, e.g. to store type codes or to hide file name extensions.
Automatically disabling named attributes and forks on NFSv4 is the default with macOS 10.13 High Sierra or later.
Enforce extended attributes and named forks if supported by server: This is basically the opposite of the previous option. When activated, macOS will use extended attributes and named forks if the NFSv4 server is capable of supporting this. This option is only available in macOS 10.13 High Sierra or later.
Enable Access Control Lists (ACLs): Access Control Lists are an enhanced way to process file system permissions with fine granularity. They can also be used with non-UNIX operating systems like Microsoft® Windows, for example, and are fully supported by NFSv4. By default, macOS disables the use of ACLs over NFS because this could be a security risk. ACLs don’t comply with a real standard, and their exact meaning varies in detail between different operating system vendors. If you like to switch ACLs on, this will be possible with this option.
Most NFSv4 servers implement ACLs using the semantics of Microsoft® Windows, so they don’t behave like macOS, which uses POSIX semantics.
Enforce Access Control Lists and ignore mode attributes (“POSIX permissions”): In UNIX operating systems, the system falls back to use mode attributes, the classic POSIX permissions, when ACLs are not available. Some non-UNIX systems might not support POSIX permissions natively, but emulate them for NFS connections, so it can make sense to use ACLs only to get reliable and well-defined permission settings. Clients will receive mode settings where all permission bit have been set (“01777”) if this feature is enabled. The option overrides the setting Enable Access Control Lists.
Permitted encryption types for Kerberos session: Three options allow you to define what encryption types you allow to be used for Kerberos sessions. These settings are only available if you are using NFSv4 on macOS Sierra or later. Apples does not officially document these options at the moment, so we won’t guarantee any specific effect. The following settings are supported:
All settings in the box Override Kerberos default configuration for this mount can be used to override the Kerberos configuration normally used by this computer with different values, specifically for this mount operation. You don’t need to specify all three values in the box, but only those that should be different from the default. The NFS client uses the values for all Kerberos-related operations, both for the security features, as well as for determining access permissions for NFSv4.
Realm: This value sets a different Kerberos realm. The realm name can begin with an “@” character, but this is not necessary. Note that realm names are usually specified with uppercase letters only.
Principal: With this entry, a different Kerberos principal (equivalent to a user account) can be set when credentials are established for this mount.
Service Principal: This option is rarely used. It can be used to specify a different principal for the server side when credentials for this mount are established. Under normal operating conditions, macOS will automatically use a principal name of the pattern “nfs@server”.