The advanced settings for shares are divided into four categories which are displayed on a tab item each. Most settings extend the options which can be set for shares in the control window.
The tab item Shared Folder shows advanced options to define which files should be shared in the network. The settings Only allow mounting the specified folder and Allow mounting the folder or any subfolders inside are equivalent to the two options you already know from the control window. The third item Allow mounting the folder or the following subfolders allows to combine these options: In this case you’ll have to explicitly list the subfolders that clients should be permitted to mount.
Under certain circumstances, there may be special cases where macOS cannot exactly decide based on the folder path alone, which files it should share: If the shared folder is the mount point of a disk volume, it might not be clear whether the folder at that mount point, or the contents of the mounted disk should be shared. It could also happen that the mount point is hosting different disks from time to time. For example if you have two external hard drives which both have the name “Data”, macOS will mount them at the locations /Volumes/Data and /Volumes/Data–1, however it is not exactly specified which disk will be mapped to which mount point. Those special cases can be clarified using the following two items:
In both cases, NFS Manager will display a sheet to choose the volume path, or the identification of a drive, respectively. The drive must be connected to the computer at that moment. macOS identifies each disk volume by a unique code (UUID) which is 32 characters long.
The tab item User Mapping holds extended options to define how accessing users should be mapped onto the user and group accounts of the NFS server when checking access permissions. The setting Map the “root” account to the unprivileged user “nobody” is known from the control window already.
The item Map the “root” account to a different identity as specified below allows you to select a freely choosable account onto which the user will be mapped. The item Map all accessing users to a different identity as specified below is similar, but will become effective for all users of the accessing computer.
The account onto which the identity will be mapped can be chosen via the button Select… from a list of all known accounts. Afterwards, the selected short name will be shown in the field Mapped user account (short name).
The control elements below allow you to define to which group account the mapping will be targeted. By default, the group memberships of the user account to which the mapping took place will be taken to check group permissions (Map to the specified user account, including group memberships). The option Map user identity only, removing group memberships is simulating a case as if the user were not member of any group. The button Map to specified user, replacing group memberships by allows to map to groups which are specified manually.
The checkmarks Clients must support the following security mechanisms define the defaults for protected NFS access. If a respective item has been checked, you will enforce that this or one of the other checked mechanisms have to be supported by the client. In case the client is not capable of supporting any of the selected mechanisms, macOS will reject mount requests from that client.
The field Share “read only” is equivalent to the field known from the control window already.
The option Share folder but reject all access attempts to its contents (“offline mode”) can be used to create some kind of pseudo share. The share will become visible in the network and clients can mount it, but any attempt to access its contents will result in an error response by the server, stating the data is currently not available.
Using the option Enforce 32 bit folder cookies although NFSv3 requires 64 bits can resolve a special compatibility problem which can arise on clients not using macOS. NFS Version 3 actually requires that client and server must exchange markers of 64 bit length to identify folders. Some clients may not implement this correctly and process 32 bits only. In this case the NFS client will not “see” all or even can’t see any files when listing folders. When this option is enabled, macOS will be forced to send the folder cookies to clients in such a way that only 32 bits of the possible 64 bits are used.
NOTE: This is a less-than-ideal solution which can reduce performance of this share. A better solution can be to reconfigure the erroneous client to use NFS version 2.
Some old operating systems may not accept file names containing more than 255 bytes. When sharing files with longer names, the NFS server can offer to shorten the names for clients, so names always fit within this maximum length, using a scheme which still guarantees that files can be identified reliably. This technique is automatically used with NFSv2. When using NFSv3, this feature can optionally be activated by setting a check mark at With NFSv3, enforce file name support for clients accepting 255 bytes only.
The tab item Access Restrictions is used to specify that only particular clients are permitted to mount a share.
In mode Allow access from any computer of any connected network no restrictions for clients will be established at all.
The item Allow access from any computer of the specified IPv4 subnet can restrict access by using the IP addresses of the clients. The fields IPv4 address and Subnet mask configure the address of the subnet which is granted access. Because macOS does not accept the subnet mask 0.0.0.0, you can use the option Specify a single client address to express that access should be granted for a single address only.
The third option has the name Allow access from listed client computers only. In that case, a non-empty list of clients has to be specified using the table below. Press the buttons [+] and [—] to add, or respectively, remove entries. The following types of entries can be used to specify a client computer:
IMPORTANT: A prerequisite of specifying DNS names is that both server and client can resolve each DNS name in both directions (name to address and address to name). Prerequisite for specifying a netgroup name is, that the name is known to the server, either by using the file /etc/netgroup, or via a directory service which is capable of maintaining netgroup entries compliant with typical Unix standards.