Windows Services For UNIX 3.0 includes support for NFS, which is the basic file system of UNIX. However, you may not want to natively support NFS on your server. If you need to access UNIX servers on your network but you don’t want to install NFS on your Windows 2000 server, you’re in luck: You can configure one of your Windows 2000 servers as an NFS gateway.

The Gateway For NFS component of Windows Services For UNIX lets Windows clients access data stored on the NFS file systems via the Windows 2000 server. The Windows 2000 server acts as an NFS client, making requests to the UNIX server on behalf of the Windows client. Once the request has been fulfilled, the Windows 2000 server passes the data to the Windows client that originally requested it. In this Daily Drill Down, I’ll show you how to install and configure Gateway For NFS.

Windows Services For UNIX 3.0

Microsoft’s Windows Services For UNIX 3.0 allows Windows 2000 to coexist with UNIX servers on your network. The three NFS components of Windows Services For UNIX are Client For NFS, Server For NFS, and Gateway For NFS. For more information about Windows Services For UNIX, see the Daily Drill Down “Integrate UNIX and Windows 2000 using Windows Services For UNIX 3.0.”

Installing Gateway For NFS
Begin the process of installing Gateway For NFS by inserting your Windows Services For UNIX 3.0 CD and double-clicking the Setup icon to launch the Setup wizard. After clicking Next to clear the welcome screen, you’ll see a screen that asks for your name and the name of your organization. After that, the next screen you’ll encounter is the End User License Agreement. After accepting the licensing agreement and clicking Next, Setup will ask whether you want to perform a standard installation or a custom installation. Select the option for a custom installation and click Next.

At this point, you’ll see a screen that contains a list of all of the available components that you can install. Since this Daily Drill Down focuses on the NFS gateway, I’ll only discuss how to install the NFS components. If you expand the NFS options, you’ll see a choice of three different NFS components: Client For NFS, Server For NFS, and Gateway For NFS. Select the Gateway For NFS option.

Installing other Windows Services For UNIX components

While I’m focusing on Gateway For NFS, you may want to install other Windows Services For UNIX components. Feel free to load other components at will, with one notable exception: You can’t install Client For NFS and Gateway For NFS onto the same machine. The reason for this is that the gateway is already acting as a client, and installing an additional client would be redundant.

When you click Next, the Setup wizard will ask you for the name of the user name-mapping server. If you don’t know the name of the server, you can enter it later on using the Windows Services For UNIX Administration program.

The next screen will ask you for the name of the folder in which to install Windows Services For UNIX. While it’s a common practice to install applications into the Program Files folder, you can’t do that with Windows Services For UNIX because the words “Program” and “Files” are separated by a space. The UNIX file system doesn’t support spaces in the folder names on the Windows server.

Whatever folder you select, you must exercise caution because Setup will delete all of the folder’s contents prior to beginning the installation process. Therefore, if you select a pre-existing folder, make sure that there isn’t anything important in it.

Setup will copy all of the necessary files and then start the newly installed services. Click Finish to complete the Setup process. After completing the Setup process, you’ll need to reboot the server.

Configuring the NFS gateway
When the server reboots, the NFS gateway installation is complete. Next you must configure the gateway. The first step is to set up authentication using user name-mapping. A name-mapping server matches user accounts on the Windows Server with user accounts on the UNIX server. Hopefully, you’ve already specified a name-mapping server during the installation process.

If you haven’t specified a name-mapping server yet, you can do so by opening the Services For UNIX Administration program found on the Start | Programs | Windows Services For UNIX menu. When the Services For UNIX Administration console loads, select Services For UNIX from the console tree on the left, and then select the Settings tab from the column on the right. When you do, you’ll be prompted for the name of the user name-mapping server. If you don’t yet have a user name-mapping server, one is included with version 3.0 of Services For UNIX.

Once you’ve linked to a user name-mapping server, it’s time to create your first NFS share point. The idea behind a Gateway For NFS share point is that you’ll be selecting a specific location on the UNIX server that Windows users need to access. You’ll then create a Windows share point that links to the location you’ve chosen. After doing so, Windows users will be able to access data from the designated location on the UNIX server by using the Windows share point that you’ve created.

Begin the configuration process by opening the Gateway For NFS Configuration tool found on the Start | Programs | Windows Services For UNIX menu. When the console opens, enter a name into the Share Name text box. The Share Name is the name by which Windows clients will reference the UNIX share. For example, suppose that you named the share DATA. Windows users would be able to access the share by using \\server_name\DATA UNC.

Next, you must select a drive letter to associate with the location on the UNIX server. Only the server that you’re configuring will use the drive letter—not the other Windows clients. Keep in mind that creating a normal share in a Windows environment involves associating a share name with a location on one of the server’s local drives. When creating a gateway for NFS, the data that you’re sharing doesn’t exist on a local drive. Therefore, it’s necessary to map a logical drive to the data, and then assign the share name to that logical drive.

Next you must specify the UNIX resource that the logical drive will link to. There are a couple of ways to do this. One way is to go to the Network Resources window and double-click the Default LAN, and then double-click the name of the server containing the resource that you want to link to, followed by the resource itself.

Another method of specifying the UNIX resource is to enter the name of the resource directly. In addition to the Network Resources window, there’s also a text box called Network Resource. Simply enter the resource name into this text box directly. You can enter the name of the UNIX server containing the resource in either the \\servername or servername: format.

The next step in the process is to select the type of encoding that you want Windows to use when mounting the specified resources. Normally, you’ll want to use ANSI encoding (which should be the default choice). The biggest exception to this would be situations that require you to link to resources on servers that use languages other than English. For example, you might use BIG5 encryption for Chinese or EUC-JP for Japanese servers.

The last text box that you have to fill in is the Comment box. Although entering a comment isn’t really mandatory, I strongly recommend entering one. Entering a comment will help you and other future administrators to figure out what the share point is for.

At this point, you’ve entered enough information to establish a connection to the UNIX server using the gateway. However, there are a few other things that you might want to consider before clicking the Connect button to establish the connection.

If you look in the Users section in the bottom of the window, you’ll see that the default choice is to permit the maximum allowed number of users, as shown in Figure A.

Figure A
By default, the share is set to permit the maximum number of allowed users to access the gateway.

However, there are times when you may not want to permit the maximum number of users; for example, when you have more client access licenses to the Windows server than you have for the UNIX server. Technically speaking, you’re only using one UNIX client access license because the server is the only machine making a connection to the UNIX Server. However, you can set the maximum number of users to the number of licenses that you have for the UNIX Server, if you prefer.

Bandwidth limitations might also prompt you to limit the number of users. For example, if the UNIX server and the Windows server are separated by a low-bandwidth connection, you might want to limit simultaneous user access to a number that can be comfortably handled by the available bandwidth.

Allow Unmapped Users
Another area of the Users section that deserves closer inspection is the Allow Unmapped Users check box. You might have noticed in Figure A that this check box is selected by default, but you might not really understand the implications of the default selection.

As I mentioned earlier, the name-mapping server matches up Windows usernames and group names with UNIX usernames and group names. Having the Allow Unmapped Users box selected means that Windows users who don’t have a corresponding account on the UNIX server receive access to the UNIX share point.

Think about that for a second: Selecting the check box is essentially like saying, “You don’t have permission to access this resource. You don’t even have an account on this server, but I’m going to give you access anyway.” Sure, there are situations in which this type of access may be appropriate—although I can’t seem to think of any at the moment—but I strongly recommend using the Allow Unmapped Users check box sparingly.

Of course, this raises the question of what level of access to give unmapped users. If a user doesn’t have an entry in a name-mapping server, then that user is given the same level of privileges on the UNIX server as a UNIX anonymous user.

What about users who do have an entry in the name-mapping server? Those users’ access levels are dictated by combining the permissions found on the UNIX server and the Windows share point’s permissions

Any time you create a normal share point to a resource that exists locally on a Windows 2000 Server, the server’s NTFS permissions apply to the resource, but you can also specify share-level permissions to the resource that only apply to users who try to access the resource through the share point. The NFS gateway works in a similar fashion.

Permissions
You might have noticed the Permissions button in Figure A. You can use the Permissions button to set the share-level permissions. Those permissions are then combined with the NFS permissions to determine the overall permissions to the resource. For example, if a user has full NFS permissions to a resource but the Windows share point gives that user read-only permissions, then the read-only permissions would take precedence because they are the more restrictive of the two permissions.

Troubleshooting
Any server component that you load on top of Windows 2000 has the potential to cause problems, and Gateway For NFS is no exception. In this section, I’ll review the causes of several common problems with Gateway For NFS.

User requests made anonymously
If all requests coming into the UNIX server through the gateway appear to be from anonymous users, the problem is usually related to the name-mapping server. To fix the problem, you should verify that the gateway server is set to use the correct name-mapping server and that the name-mapping server is configured correctly.

Errors trying to communicate with the gateway
The most common cause of gateway communications problems is that the Gateway for NFS service isn’t started. When this is the case, you may also notice an error 1722 in the System event log along with a message stating that the RPC (Remote Procedure Call) server is unavailable.

Network error 53 or 67
If when trying to mount a shared location on the NFS server you receive a network error 53 or 67 error, it’s usually because the resources that you’re trying to mount aren’t actually shared. Another possible cause of the problem is that the system is having trouble resolving the client name. Keep in mind that you can’t share the root directory of the NFS drive.

Get to work
Gateway for NFS provides an easy way for you to make NFS-based resources available to Windows clients. You can use it to give Windows users transparent access data stored on UNIX servers without having to teach them any new tricks. If you have UNIX servers on your network, it’s well worth the investment.