Mount
Options in DetailMount
Options in DetailMac OS X supports a large number of settings which can be defined for each mount. NFS Manager is dividing 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 hold for some time above 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, Mac OS X 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 being 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 Mac OS X is respecting this option in general, there can be cases where Mac OS X 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. Mac OS X would not “understand” such programs.
Don't update file access times: In many operating systems, an attribute is stored for each object 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 being 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 being 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 Mac OS X 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.
Note: When storing the automount entry onto a directory node used by multiple computers, make sure to only use the last two options if all computers accessing the node are using Mac OS X Snow Leopard or later. The options might not be supported for computers running Mac OS X 10.5.x. They cannot be activated if the current computer is running Mac OS X Leopard.
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. If 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 any 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 Mac OS X to cancel the programs, all data currently being 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 will be 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 to be valid when their requests are sent from ports which are usually reserved for operating system services only (i.e. the requests should 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 being 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. Mac OS X 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 unreponsive for __ s: If initial contact to the server succeeded, but later the server becomes unresponsive, Mac OS X will display a “server does not respond” warning on the graphical user interface. You can additionally let Mac OS X disconnect the unresponsive share after a certain amount of time has passed by checking this option and specifying a number of seconds. Mac OS X internally auto-activates this feature when using a soft read-only mount, specifying a timeout of 60 seconds.
Note: This feature is available in Mac OS X 10.6 or later only. When storing the automount entry onto a directory node used by multiple computers, make sure to only use this option if all computers accessing the node are using Mac OS X Snow Leopard or later.
Don't display as being unresponsive on jukebox errors: When checking this option, Mac OS X 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.
Note: This feature is available in Mac OS X 10.6 or later only. When storing the automount entry onto a directory node used by multiple computers, make sure to only use this option if all computers accessing the node are using Mac OS X Snow Leopard or later.
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 cards, 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 will 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 usage of a certain security feature. If the server is offering 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 Mac OS X, 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:
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.
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 Mac OS X makes intensive use of extended attributes, e.g. to store type codes or to hide file name extensions. Classic Mac OS applications also made use of resource forks very often.
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, Mac OS X disables the use of ACLs over NFS because this could be a security risk. ACLs are not a real worldwide 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.
Enforce Access Control Lists and ignore mode attributes (“POSIX permissions”): In UNIX operating systems, the system falls back to using 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.