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.
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.
 |  |  |
| 10.3. Configuring PC/NFS |  | 10.5. Printer services |
