NFS Manager

On this page

NFS Manager 2 (for legacy systems)

Known Issues

There are currently no known issues for this product.

Release Notes

NFS shows significant problems with Mac OS X 10.4.9 and 10.4.10: The component of Mac OS X which emulates Carbon file access on top of the underlying Unix system does not work correctly in 10.4.9 and 10.4.10. This can cause problems in all network file systems which don't use the AFP (AppleShare) protocol, including NFS, CIFS/SMB and WebDAV. The following (and other) symptoms can occur:

Only applications using the graphical user interface are affected by this problem. Applications which operate at the BSD (Darwin) level are not affected.

Workaround: Upgrade to Mac OS X 10.4.11 to repair the operating system.

Kerberos might not be supported although client and server options are visible in NFS Manager: Although Apple is documenting Kerberos options for both the NFS client and NFS server built into Mac OS X, these options have no effect. Apple has disabled Kerberos support for NFS in all current versions of Mac OS X.

Workaround: By recompiling the NFS components of Mac OS X via the Darwin source code, it is theoretically possible to reinstate Kerberos support. NFS Manager can be used to manage Kerberos options for Darwin and Mac OS X directory clients where Kerberos features have been enabled in the operating system.

The NetInfo save operation might fail if you are trying to edit NFS share definitions for the entire startup volume ("/"): If you have shared the entire startup volume (the folder named "/") via NFS, and you have saved this share definition to the local NetInfo node, and you are trying to edit this share entry later, writing the new data back to NetInfo might fail with an "unexpected error". This problem is caused by a subtle defect in Apple's directory services support for NetInfo.

Workaround: Use the following instructions to edit the share definition for "/" in the local NetInfo database:

  1. Select the current share definition for "/" in NFS Manager.
  2. Save the definition to file using the menu item NFS Entry > Export to File.
  3. Delete the share definition using the menu item NFS Entry > Remove Share.
  4. Reimport the definition using the menu item NFS Entry > Import from File.
  5. Make the necessary changes and press the button OK to save the edited share definition.

Apple might fix this problem in future versions of Mac OS X.

Programs accessing the Address Book cannot be launched by users of Mac OS X Panther if their private home folder was placed on a non-Apple NFS server: If you are using Mac OS X 10.3 Panther and have your private folder (home directory) on a third-party NFS server, problems can arise when starting an application that accesses the address book. Among others, the applications Address Book, iChat, and Mail are affected. Mac OS X 10.3 uses POSIX advisory file locks to open the address book database. Some NFS servers are not compatible with the implementation of NFS locking used by Apple. The lock fails and the calling applications hangs.

Workaround: Switch off all NFS locking features with the menu item Computer > Change NFS Locking and restart the client computer. Another alternative is to use an NFS file server compatible with the locking features of Mac OS X 10.3. Compatible NFS servers are: Darwin 7.0 or higher, Mac OS X 10.3 or higher, FreeBSD 5 or higher. Note that the problem can also be resolved by upgrading to Mac OS X Tiger.

The connection to a non-Apple NFS server is suddenly dropped by Mac OS X 10.3 Panther although the connection is in use: If you are using Panther to access an NFS file server for which the option Use secure communication ports must be set, the connection may unexpectantly fail, especially in the following situations: high traffic on the connected LAN segment, reconnect of an expired automount, reconnect after sleep mode. Files currently open on the affected NFS share may become corrupted and all running applications accessing the share may crash.

Workaround: This is a known defect in the Mac OS X 10.3 kernel and the locking service. Apple has corrected the issue in Mac OS X 10.3.3. Update to 10.3.3 or higher to solve the problem.

Manual connections fail if the share name contains a space or other special characters: If you use the menu option Computer > Connect manually and enter a path at Location that contains one or more space characters, the connection will silently fail.

Workaround: Manual connections are handled by the Mac OS X Finder, and the Finder currently cannot handle NFS connections that contain spaces or other special characters. This will also fail if you use the Finder's Go > Connect to Server feature. We made Apple aware of this problem and hope they will fix it in future versions of Mac OS X. As a workaround, define a connection with NFS Manager and activate it. It will be automounted as soon as you access the mount point.

Accessing some third-party NFS servers may show very bad write performance: When working with a connection to a non-Apple NFS server, you may experience the problem that write operations are extremely slow while read performance is normal (typically 8.1 MByte/s when using Fast Ethernet, and 36.5 MByte/s when using Gigabit Ethernet).

Workaround: Some NFS servers may enforce synchronous data transfer mode for their clients. In this mode, each data transfer from client to server has to be acknowledged by the server and the client is blocked until the server has completely written the data to its hard disk. Depending on what file system is used on the server, this can cause very poor write performance. Among others, NFS servers running SuSE Linux 8.0 or higher are affected by this problem. As a workaround, switch off synchronous mode on the server. In Linux this is done by adding the option "async" to each share entry. This will enable standard asynchronous NFS communication and file transfer will run with normal speed. Note however that if the server crashes during a write request from an NFS client before the server had written all the transferred data to stable storage, the client will not become aware of this server error.

Union mounts might not work as expected: If you define union mounts (connecting several shares to the same mount point so that they appear as a single "overlapping" volume), they might not work. Only the first entry of the union is actually connected, all other entries that refer to the same mount point are ignored.

Workaround: This is a known bug in the Darwin automounter and there is no workaround. We made Apple aware of this problem and hope they will fix it in future versions of Mac OS X.

Activating connections when connections are already in use can result in overlapping volumes and Finder problems: If you have active connections to NFS servers in use by running applications and you use the Activate Connections feature of NFS Manager, the Darwin automounter might mount shares twice. This results in unwanted union mounts consisting of several instances of the same shares. The Finder is unable to interpret this situation correctly. All files and folders below the affected mount point are displayed as invalid network aliases.

Workaround: This is a known bug in the Darwin automounter. Update to Mac OS X 10.3.5 or higher to solve the problem.

NFS Manager no longer supports static NFS mounts: NFS Manager 2 has no direct feature to create a static mount (a connection to an NFS server that is fixed and is not handled by the automounter).

Workaround: As of Mac OS X 10.1, Apple intentionally disabled static mounts in the default startup procedure. For this reason, support of static mounts has been removed in NFS Manager as well. Users who actually need this can edit the NFS startup item script (/System/Library/StartupItems/NFS/NFS) and reenable static mounts by removing the option -m /automount static in the automounter call. You also have to integrate a static mount command (e.g. /sbin/mount -a -t nfs) into the startup sequence of the operating system. This modification is only recommended to experienced Unix administrators.

Some applications cannot open files from an NFS server if those files have not been created using NFS: If you write a Macintosh file with resource fork to an NFS server without using NFS (e.g. using AFP file sharing, SMB Windows file sharing or creating this file directly on the server writing it to the local hard disk), you will later have problems opening this file using NFS. Each file sharing protocol uses different techniques to handle Macintosh resource forks. Those techniques are not compatible with each other, so you cannot write a file with resource fork using one protocol but read it with another protocol.

Workaround: You should avoid using different file server protocols when reading and writing Macintosh files with resource forks. If this is not possible for your desired kind of workflow, use our Fork Server Helper application to convert between different resource fork representations.

File locking is not supported via NFS: Depending on what release of operating system you use, file locking over NFS may not be supported. This affects both using Mac OS X as an NFS client and server.

Workaround: Update to Mac OS X 10.3 or later to make sure that NFS file locking is implemented in the operating system. Here, POSIX advisory locking via the flock() function call is fully supported on NFS file systems.

When sharing a volume formatted with UFS, Linux systems can access the files but they cannot list the contents of the shared folders: If you have formatted a volume with the UNIX Universal File System (UFS) and share files on the volume using NFS, some Linux systems might have problems accessing the volume. Access to known files works fine, but the Linux NFS client cannot list any directory on the shared UFS volume. Instead it receives error messages like "reading directory x: Input/output error".

Workaround: First try to enable the option Use 32 bit Readdir cookies for NFSv3 clients to share the UFS volume. If this doesn't help you can downgrade the NFS connection to version 2 of the protocol, using a Linux command like

mount -o nfsvers=2 macserver:/share /mnt