Managing NFS and NIS, 2nd Edition - Mike Eisler [132]
If you need to run a PCNFSD daemon on the server, you will want to add it to the rc scripts that get started when the Unix server boots up. For Solaris, you would add a script to /etc/init.d:
#!/bin/sh
PCNFSD_NAME=hclnfsd # in /opt/pcnfs/bin
PATH=/opt/pcnfsd/bin:$PATH
export PATH
case "$1" in
start )
# The named directory is used as a temporary area for print spool files.
$PCNFSD -A /var/run
;;
stop )
pkill $PCNFSD
;;
esac
exit 0
and then link this script to a hard or soft link in /etc/rc3.d to start it before the NFS server.
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.
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.[3] However, if the connection uses NFS/dh (see Section 12.5.4) or Kerberized NFS (see Section 12.5.5.3), then the server performs the authentication without sending a password to the server, encrypted or not.
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, 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.
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