UNIX as a DOS File and Print Server
Kim Soques and Bruce Altmann
While NFS is a common method of sharing files between
it is less common as a way to share files between PCs.
Given our exclusively
TCP/IP network, and our users' need to work in cross-functional
using multiple platforms (VAX, UNIX, PC), our company
chose to use
NFS as its enterprise-wide file-sharing method. In addition,
away from using serial connections for our network printers,
of an IP printing strategy. This model not only has
been easy to integrate
into our existing environment, but also has proven able
to scale up
or down as needed.
Since this article is targeted toward UNIX configuration,
we do not
discuss the issues surrounding selecting and configuring
an NFS client
to run on the PC. Given this, you should be aware that
not all PC
network software that delivers TCP/IP services to the
NFS or network printing clients. In many cases these
are add-ons or
an enhanced version of a basic TCP/IP stack. We use
however, all the PC-based NFS products operate the same
for the purposes
of this article. Henceforth, references to the PC software
a product that includes an NFS client and some support
Something to remember when using NFS with PCs is that
"trusting" PCs are directly accessing a multiuser
PCs and, by extension, their users do not inherently
use UNIX permissions.
Many of the lessons we learned stem from that fundamental
rpc.pcnfsd lies at the heart of managing the multiuser
PC contradiction. rpc.pcnfsd provides weak authentication
of user IDs for the PC. An RPC server, it listens at
port 150001 for
authentication requests, returning the UID and all GIDs
for each valid
user name and password passed to it. This occurs during
the PC's boot
cycle, or if the user manually chooses to log out and
log back in.
Authentication allows the user access to the directories
permissions for. If authentication fails, the user ID
"nobody," and the user can only access network
under world permissions. This process is essential for
the PC to be
able to access UNIX resources.
rpc.pcnfsd is freely distributable, and available on
of the ftp sites that keep Sun patches and other information.
most current version we have found is version 2, revision
we found on a SunSoft PC-NFS CD-ROM. If a server is
rpc.pcnfsd, use rpcinfo to determine which version
is installed. To identify the revision number, use the
strings rpc.pcnfsd | grep ver
HP bundles rpc.pcnfsd into its operating system,
but the version tends to run one revision or so behind
the most current
Sun code. In addition, some vendors of PC NFS clients
versions of rpc.pcnfsd. Our tuning recommendations here
to the Sun rpc.pcnfsd.
The essential portion of configuring a UNIX server to
is turning it on. The daemon is enabled in /etc/rc.local
SunOS 4.1.3, in /etc/initd/pcnfs on SunOS 5.4, and in
/etc/netnfsrc under HP-UX 9.3.
For SunOS 4.1.3:
# start up pcnfsd version 2 daemon ("april 02, 93") by: ("altmann")
if [ -f /usr/local/etc/rpc.pcnfsd ] ; then
/usr/local/etc/rpc.pcnfsd ; echo ' rpc.pcnfsd' >/dev/console
for HP-UX 9.3:
# PCNFS_SERVER -- if this node is a server for PC-NFS requests.
# This variable controls the startup of the
# pcnfsd(1M) server. See Also: pcnfsd(1M).
# (the default is 0)
Aside from its crucial role in providing UNIX user IDs,
rpc.pcnfsd plays another part -- that of enabling network
printing. We will discuss that aspect in more detail
in the section
dealing with printing.
Server Setup for File Sharing
General Setup Information
Much of the effort needed to set up a UNIX server for
PC file sharing
is the same as for setting up any NFS/NIS server. There
are many excellent
resources that cover the topic, including Hal Stern's
NIS/NFS, so we do not cover that here. Note that NIS
not strictly necessary when setting a server up to handle
though we cover some ways to broaden their use in supporting
Beyond the basic server setup are customization issues.
Some of these,
such as export restrictions, permissions, and shared
are simply enhancements to the standard configuration.
as rpc.pcnfsd tuning, are specific to the server's new
The exports needed on a PC NFS server are simple. The
file systems the PCs will need to access are the filesystem
user home directories and the /var/spool/pcnfs filesystem
(for pcnfsd printing).
However, to keep from opening the server up to the whole
we use the /etc/netgroup file to restrict access. A
/etc/netgroup resolves individual host names to file
access. (Without NIS, this file is moot.)
The netgroup file allows host names to be added dynamically,
unlike the more static -access flags in the /etc/exports
file. The netgroup format is an alias followed by an
control field, containing any one of the following:
or domain name. (Domain name was never implemented.)
The most secure
method specifies user and hostname. However, we cannot
rely on the
same user always being at the same host, so our netgroup
use the hostname only. These aliases can contain approximately
entries. Several can be combined into still-larger aliases,
highest-level alias used in the exports file itself.
The /etc/netgroup entry controlling access to /var/spool/pcnfs
would look like this:
nova_pc_1 (crawford,,) (flato,,) (pignut,,) (introit,,) (hangnail,,) (sauk,,)\
(cheroot,,) (bibelot,,) (corolla,,) (fauve,,) (organdy,,)\
(adams,,) (philip,,) (peccary,,) (ebony,,) (cherimoya,,)\
######### /var/spool/pcnfs export
nova_pcnfs nova_pc_0 nova_pc_1 nova_pc_2
while the corresponding /etc/exports portion
This, in conjunction with strategic use of UNIX permissions,
keeps unauthorized users from accessing what could be
Permissions, Group Access, and Work Group Directories
Since the NFS mount on the PC is mapped to a drive letter,
think the "virtual drive" is the same as their
To maintain the illusion, we set user directories to
The user then does not receive the sort of surprise
one of our users
did before we adopted this rule. She had been working
in a different department, and called him to discuss
how best to transfer
a mutual file back to him. He, a UNIX user on the same
her not to worry, since he'd already copied it out of
her home directory!
We quickly found out how unamused she was to find out
that the file
she thought was "safe" wasn't. Our policy
In a similar vein, group permissions play a larger role
on the PC-based
NFS server, particularly if many different departments
are using the
same server. To keep confusion to a minimum and ease
we give all members of a particular department a default
to that department.
Finance staff would be in group finance, while
Marketing would go in group mrkt. Even if a user changed
account's permissions to drwxrwx---, Marketing staff
not be able to get into Finance's directories. This
use of group permissions also makes it easy to implement
After users start to use their home directories, they
request a place
to share files with other department members. To do
this, we put a
twist on the basic account, calling it a work group
define a dummy user in the passwd file with the same
group ID as the members of that work group. The account
( a "*" in the password field), but otherwise
set up normally.
wgs:*:5071:6020:WGS Work Grp Dir:/user/wgs:/bin/csh
The permissions on that account's directory are
then set to drwxrwx---, enabling all members of that
to read and write in the directory:
drwxrwx--- 13 wgs wgs 1024 Jun 23 17:02 wgs
With no more effort than creating an account, the group
has a shared space in which to work collaboratively.
Concerning permissions and access, there is one other
item to cover.
We mentioned earlier that rpc.pcnfsd provides "weak
This means that after the server hands over a UID to
the client, no
more checking is done. The client carries that UID to
it accesses, unchallenged.
Weak authentication has caused a problem that we are
with. For example, when juser turns on her PC in the
she authenticates on server A. To access some spreadsheets
in a different
department, she NFS-mounts server B. If the UIDs are
-- that is, if juser is UID 555 on server A but is 556
on server B -- conflicts arise. At minimum, juser will
not be able to access her files. Depending on the PC
NFS client, juser
may have access to all of the files belonging to user
555 as well.
When we first implemented NFS for PCs, we did not worry
this. Most users had only one NFS mount and authenticated
machine. Now, however, use of NFS on PCs has become
and widespread. When we set out to implement a corporate-wide
that relied upon NFS mounts to central servers, we realized
we had in front of us. We have been working to implement
UID registry as a stopgap measure, but at this point
involves lots of rework for all our systems administrators.
they have been slow to adopt this for anything other
than new accounts.
We are eagerly awaiting something like DCE or NIS+ for
since at this time even SunOS 5.4 handles PCs in NIS-compatibility
Tuning for NFS Performance
Optimizing a server for PC file and print services does
not stop with
starting rpc.pcnfsd and adding NIS enhancements. Since
server is no longer a compute box or a major time-sharing
but a file server, it needs to be tuned for NFS performance.
accelerator card is essential -- we use Prestoserve
on our Sun
4.1.3 machines. These cards handle write caching, keeping
from having to wait on a completed disk write on the
NFS accelerator cards do entail some initial cost, they
for themselves in decreased wait time and fewer hostile
Another important item is to enable the UDP checksums.
NFS uses UDP,
a stateless protocol, to transmit packets, and the RFC
for NFS does
not specify that it must do data checking. In Managing
Hal Stern states that "without the checksums, it's
read or write corrupted data" (p. 317). The UDP
this missing data verification step. As Stern notes,
containing UDP checksum errors are rejected on the server,
be re-transmitted by the client" (p. 317).
On by default in SunOS 5.4, UDP checksums are turned
off in Sun
4.1.3 machines. To implement them, edit /usr/kvm/sys/netinet/in_proto.c
and change the udp_cksum line (near the end) from
udp_cksum = 0
Reconfigure the kernel and then reboot.
Another key NFS tuning parameter is to increase the
nfsds running. As more and more users are added, the
nfsds SunOS starts by default become inadequate. A handy
of thumb is to run approximately eight nfsds per every
50 users, up
to the maximum recommended by the OS provider (30 for
Less than this can result in temporarily dropped mounts
with the PC
clients, which is alarming for the end user -- "Not
drive K" generates quite a few support calls!
Our final NFS tuning hint involves adjusting the number
in the kernel. The paper "Sun Performance Tuning
from SMCC Technical Marketing (December 1993), suggests
equal to two times the amount of RAM on the server,
up to the maximum
suggested for the operating system (225 for SunOS 4.1.3).
is twice Sun's recommendation for non-NFS servers. Changing
optimizes the NFS buffer queue sizes, the I/O buffer
sizes, and the
table sizes in the kernel, preventing bottlenecks.
Network Printing Setup
Migration from Serial to IP Printing
Originally, UNIX network printers were made available
on our TCP/IP
network via a serial connection to a terminal server.
Under our old
method, we could trace a printing problem from the client
the job through to the server. Unfortunately, the link
from the server
to the printer was difficult to troubleshoot. As we
PC-NFS enterprise-wide, this level of uncertainty was
We decided to use MiLan's Fastport 3100/3100CX, moving
us from reliance
on serial protocols to TCP/UDP.
The Fastport is a network-aware device that accepts
Berkeley LP protocol
requests and spools them to the attached printer. It
can be monitored
remotely via telnet, thus making printing much easier
With the Fastport handling the connection between the
the server, we can now trace a printing problem almost
to the parallel
cable linking the Fastport and the printer.
MiLan Attachment and Setup
The MiLan Fastport provides a flexible interface between
and printers. It can be set up to perform filtering
or not on the
box itself, with some models supporting autosensing.
also supports many different printer description languages,
we have standardized upon three -- UNIX ASCII, DOS ASCII,
These three we can move through the same queue, since
a Fastport set
up for autosensing can handle the carriage return/line
between UNIX and DOS ASCII. This single-queue approach
matters for our PC users, since they only point to the
one queue name
for all their printing requirements. For printer languages
escape codes, like HPCL and HPGL, we find it easiest
to set up a separate
queue. We try to avoid this, however.
The details of configuring printer setup files vary
so widely from
operating system to operating system -- even from one
to the next -- that we do not have enough column inches
that here. However, with each Fastport MiLan ships software
configuring the various server types, along with good
Choosing and setting up MiLan boxes is only the first
step in our
printing strategy. Once IP printing is enabled, there
are still decisions
to make in how to approach spooling print jobs from
the PC. There
are two options available: pcnfsd printing and Berkeley
rpc.pcnfsd on the server enables what we call "pcnfsd
printing," a method of providing network printing
to the PC without
using the Berkeley LP protocol. Using pcnfsd printing,
will print through an LPT port redirected to an NFS
mount. Once the
print job is copied to the NFS mount (that is, on the
then executes lpr on that spool file. Until recently,
NFS client we used on the PC did not support the Berkeley
protocol, so this was our only network printing option.
is supported in more recent versions of our PC NFS client,
so we are
increasingly using the LP protocol as a more reliable
for reasons outlined below.
rpc.pcnfsd by default has a printing timeout of 50 seconds.
We have found this setting has a tendency to fail on
large files such
as presentations. Not only does the print job stop,
but often rpc.pcnfsd
hangs when this timeout occurs.
To make pcnfsd printing more reliable, we recommend
the changes noted in Listing 1 to the rpc.pcnfsd source
We took these suggestions from SunService, after contacting
our printing timeout problem. These changes do not eliminate
completely, but they do lessen its frequency.
For pcnfsd printing, printcap configuration is no
different from usual. To use Berkeley LP printing, the
daemon must be set up to accept remote requests. This
is no different
from setting it up to accept lp requests from remote
rpc.pcnfsd Monitoring Tools
As we mentioned earlier, we run a perl script called
to help us monitor rpc.pcnfsd (see Listing 2). Run from
cron job, pcnfsdcheck.pl checks the 150001 port to
make sure that rpc.pcnfsd is still responding. If it
the script kills the process and restarts it. It also
contains a syslog
function, return codes, and the option to test remote
hosts. We have
tested it under perl 4.03X and perl 5.001 on HPUX 9.X,
and SunOS 5.4.
will give a list of the options available. Note that
the -f flag only works on a localhost, so do
not use it with the -n option. Used without the -n
<node> option, pcnfsdcheck.pl will poll the localhost.
-s is silent mode, although errors will write to STDOUT.
The -l option will write to syslog. This is most effective
with the -s option. The -f will cause pcnfsdcheck.pl
to try to run ps to get the PID, then kill and restart
(localhost). We recommend using:
pcnfsdcheck.pl -n node_to_check -s -l -f
The script is setup by default to run on SunOS 4.1.3.X,
but you can configure it to run on other operating systems
the LOCAL CUSTOMIZE section to match your OS.
A side note: the syslog function requires the syslog.ph
perl header, so check /usr/local/lib/perl for this file.
the perl installation on the server was questionable,
flag will break the pcnfsdcheck.pl code. If you do not
syslog.ph, check the h2ph ("header to perl header")
man page for how to proceed.
To use pcnfscheck.pl, install it in /usr/local/etc
755 root daemon pcnfsdcheck.VENDOR.OS.pl
-rwxr-xr-x 1 root daemon 7015 May 15 17:04 pcnfsdcheck.Sun.4.X.pl
-rwxr-xr-x 1 root daemon 7015 May 15 17:04 pcnfsdcheck.Hpux.9.X.pl
The crontab entry would be as follows:
# check pcnfsd, fix, and log every 15 min
1,16,31,46 * * * *
/usr/local/etc/pcnfsdcheck.Sun.4.X.pl -s -l -f
This hands-free checking means that we no longer
find out about rpc.pcnfsd dying from our unhappy users,
our support calls are kept for bigger problems. Phasing
printing will reduce our need for pcnfsdcheck.pl, but
eliminate it, since client authentication plays such
a key role in
determining the PC's access to network resources.
At a high level, setting up this environment entails
Select a DOS/Windows PC-based NFS package.
Set up rpc.pcnfsd to handle the single-user
(PC) to multiuser (UNIX) translation.
Set up the user's UNIX account and home directory,
setting permissions to drwx------.
Add the user's hostname to the netgroup
file and push the map (assuming NIS is running).
Export the needed filesystems, using the netgroups to
Set up a work group directory as needed, setting permissions
Set up and export /var/spool/pcnfs.
Install the PC client software, including user
login, password, and directory mounts - H: for home
P: for work group directory.
Install and set up the MiLan Fastport.
Set up the print queue on the UNIX host.
Set up the LPT redirection on the PC, making sure
to choose an appropriate Windows printer driver (if
From a technical standpoint, NFS and Berkeley LP protocols
proven surprisingly easy to integrate into our corporate
and have shown themselves to be highly scalable enterprise-wide.
ability to control security on the server, rather than
has been an added plus, particularly in working with
our PC users.
From a user education standpoint, we have found that
are virtually transparent to our user base on all platforms.
one could say we are now victims of our own success.
has become a hot issue as our users often forget that
on our network has access to Microsoft Word. Our move
to MiLan Fastports
has not only made our UNIX and PC printing more robust,
but it has
had the side benefit of standardizing the setup of all
printing. We even use MiLan boxes for mainframe and
sending print jobs from all platforms over ethernet
to the same printer
-- no more IBM controllers, and our users can save money
a single printer for their workgroup. NFS and LP have
successful protocols for sharing files and handling
across our large, mixed platform network.
Stern, Hal. Managing NFS and NIS. Sebastopol,
CA: OReilly & Associates, April 1992 printing.
About the Authors
Kimbol Soques earned a BA in English Literature from
She works for Advanced Micro Devices as a Systems and
She has been doing systems administration and PC networking
for four years. She can be reached via email at email@example.com.
Bruce Altmann earned a BS in Engineering Technology/Telecommunications
from Texas A&M University. He works for Advanced
Micro Devices doing
Systems and Network Engineering. He has been in the
for four years in the corporate world, and three years
in the academic world. He can be reached via email at