Common PC/NFS usage issues (Managing NFS and NIS, 2nd Edition)

10.4. Common PC/NFS usage issues

We'll conclude this chapter with a look at a few practical issues that come up in PC/NFS installations.

10.4.1. Mounting filesystems

Some PC/NFS clients will require an explicit step to connect to an NFS server. This step will be performed by a GUI application, where the user identifies the NFS server host and the server's filesystem to mount. The mount occurs on a drive letter rather than an arbitrary mount point.

Other PC/NFS clients will be tightly integrated with the Windows Network Neighborhood. You would then click on the Network Neighborhood icon on the desktop screen, and see a list of hosts advertising filesystems available to NFS or SMB clients.

In either case, to complete the connection to the server, you may be prompted with a password, unless you decide to connect as nobody. As nobody, you'll have access only to files with world read, write, or execute permissions.

If using AUTH_SYS, the client takes your password and sends it to the PCNFSD daemon server, or checks with the NIS or NIS+ server's passwd map to see if you are authorized to assume that AUTH_SYS identity. Thus, it is the client, and not the NFS server, that is performing the authentication.[17] However, if the connection uses NFS/dh (see Section 12.5.4, "AUTH_DH: Diffie-Hellman authentication") or Kerberized NFS (see Section 12.5.5.3, "Enabling Kerberized NFS"), then the server performs the authentication without sending a password to the server, encrypted or not.

[17]The same is true when using a Unix NFS client with AUTH_SYS.

10.4.2. Checking file permissions

Windows/NT and Unix have different file permissions conventions. By default, users on PCs are given the permissions of the anonymous user nobody, which generally means that PC users can access files with the appropriate world permissions. As we'll discuss in Section 12.4.2, "Superuser mapping", being mapped to nobody is very restrictive and may prevent users from accessing their home directories on Unix file servers.

With NFS Version 2, there is no mechanism for Windows or NT to perform Unix file permission checking. File permissions exist only on the Unix server side, not on the PC/NFS side. This problem is solved by calling on the PCNFSD server. The first time the PC/NFS user accesses the server, the PC/NFS client mounts the filesystem and contacts the PCNFSD server to get user identifiers, group identifiers, and supplementary group identifiers for the authenticated user. The PC/NFS client can then compare the identifiers with the attributes (user and group ownership and permissions) of files accessed to see if the user should have access or not.

If the NFS mount uses NFS Version 3, which has an ACCESS procedure, contacting the PCNFSD server for the user's identifiers for the purpose of permission is not necessary. Of course, if AUTH_SYS is being used, the user's identifiers are still necessary.

10.4.3. Unix to Windows/NT text file conversion

Windows/NT and Unix differ in their end-of-line and end-of-file conventions on text files. PC/NFS includes the dos2unix and unix2dos utilities to convert between the two formats (the text editor you use on Windows might have the capability to convert between the two text formats as well). When converting to Windows format, Unix end-of-line characters (\n) are converted to newlines and carriage returns, and an end-of-file character (CTRL-Z) is added. Going the other way, extra carriage returns and the end-of-file marker are stripped out of the file.

If you look at a Unix text file on a PC without doing the end-of-line conversion, you'll find that consecutive lines of text fall into a stepped arrangement instead of starting on the left margin:

C> type h:\test.txt
This is a line 
              of text without carriage returns

In this example, you need to convert file test to Windows format before reading it on the PC/NFS client. The conversion entails the addition of carriage returns (CTRL-M characters) to the end of each line and adding an end-of-file marker (CTRL-Z) to the end of the file.

You can put Windows files of any sort -- executable, binary, or text -- on a Unix fileserver and access them using normal Windows mechanisms. PC/NFS doesn't care about the content of the files. The file format conversion problem exists only for text files that were created on one system that must be read on another. If you put a Windows binary on a Unix NFS server, it will not require any format conversion to be read and executed by the PC/NFS client.

Text file conversion utilities are available on Unix as well. Solaris has unix2dos and dos2unix. Linux has mcopy.