Adding NFS to Windows NT Servers

WRQ is well-known for their Reflection X and TCP/IP suites for Windows machines, allowing those platforms to participate as X clients to a UNIX X server. Some of these suites include NFS (Network File System) clients, which have allowed Windows machines to participate in NFS, mounting UNIX-based exported NFS files and directories. WRQ’s Reflection NFS Gateway takes a different approach, allowing any Windows machines on a network to go through the Reflection NFS Gateway server to NFS shares, providing a centralized NFS interface to normal Windows networking. This eliminates the need for each machine on the network to run NFS clients, saving money and easing configuration considerably.

To run Reflection NFS Gateway you need a Windows NT 4.0 Server with Service Pack 3 installed. Reflection NFS Gateway also worked under our beta of Windows NT 5 Server. Multiprocessor and single processor systems are both supported. A minimum of a Pentium 100 with 32MB RAM is recommended for light NFS use, but heavier use requires at least a 266MHz and 128MB RAM. Reflection guesses that for very heavy use, at least 256MB RAM and 100Mbps Ethernet is necessary, along with at least a single 300MHz Pentium. Our test platform, an ALR Revolution 2XL with two 266MHz Pentium IIs and 128MB RAM served requests for our 25-station network without problem over 100Mbps network. All configuration and managing of Reflection NFS Gateway is done through the Administrator login.

Installation is fast, using the familiar Reflection installation routines. In order to install Reflection NFS Gateway any NFS client packages (such as Reflection X with NFS client) must be installed. This proved to be a bit of a bother as we usually run the full Reflection X package (which includes NFS client) and there’s no way to simply uninstall just the NFS client alone. Instead, we had to remove all of Reflection X, install Reflection NFS Gateway, then reinstall Reflection X minus the NFS client. If you are clever and back up all your scripts and automated routines, these can be reused without bother, but a simple component uninstall script, or an option in the Reflection NFS Gateway to remove the client would have been much better.

Once loaded, the NFS mounts can be established. This is made easier by Reflection’s Drive Mapping Wizard. This wizard allows three types of maps: gateway (shared) drives that are shared with all clients, persistent drives which are not shared but are available for some applications like Web servers, and mapped drives which are not shared but are available to the current NT Server user only. All three types are easily established through radio buttons on the Wizard’s interface. You can choose any drive letter to be associated with each mounted NFS directory, as long as it is unused on the server. Management of NFS shares is through a Gateway Manager applet, which makes it almost ridiculously easy to handle complex, multi-machine shares.

We used Reflection NFS Gateway to mount a series of NFS drives from both SCO OpenServer and SCO UnixWare 7 machines, as well as two Sun Solaris 2.5 and one HP-UX 10.2 machines. In every case Reflection NFS Gateway mounted the drive properly, assigned it whatever name we chose, and served that drive up with the proper permissions and access list to the Windows 95 clients on our network. When we failed a mount by unmounting the filesystem at the UNIX end, or by powering down the machine, Reflection NFS Gateway detected the problem and alerted us properly. Changing user and group access to mounts is easy using a User Manager-like pick window.

It may be difficult to get overly excited about NFS software, but in a heterogeneous environment tools like Reflection NFS Gateway simplify UNIX to Windows interactivity enormously. Throughout the month-long testing period Reflection NFS Gateway behaved without a single problem. If you need to offer UNIX NFS drives to Windows clients and want to avoid a lot of individual Windows machine configuration problems, you need this product.