 |
» |
|
|
|
An NFS server is a machine that "exports"
its local directories (makes them available for client machines
to mount using NFS) On the NFS client, these mounted files and directories
look to users like part of the client's local file system.
An NFS server can also be an NFS client. Following are the tasks
involved in configuring and administering an NFS server. The first
two tasks are the only ones required to get your server up and running. This section tells you how to perform these tasks, by editing
files and issuing HP-UX commands. However, Hewlett-Packard recommends
that you use SAM to configure and administer NFS. SAM (System Administration
Manager) is Hewlett-Packard's windows-based user interface
for performing system administration tasks. To run SAM, type sam
at the HP-UX prompt. SAM has an extensive online help facility. To Make Directories
Available to NFS Clients (Export Directories) | |
Add a line to the /etc/exports
file for each directory you want to make available to NFS clients,
using a text editor like vi.
If the /etc/exports
file does not exist on your system, you will have to create it.
Following is the syntax of a line in the /etc/exports
file: directory [-option[,option]] |
Type man 4 exports
at the HP-UX prompt for a complete list of the export options. After
adding your exported directories to the /etc/exports
file, you must enable NFS server capability before NFS clients can
mount your exported directories. See “To Enable NFS Server
Capability”. If your system is already running as an NFS server,
issue the following command to add the directory to your server's
internal list of exported directories: /usr/sbin/exportfs directory |
You can issue the exportfs -i
command to add the directory to your server's internal
list of exported directories, without adding the directory to the
/etc/exports
file. However, it will stop being exported when you reboot your
system or restart NFS, unless you also add it to the /etc/exports
file. (Issuing the exportfs
command does not change the contents of the /etc/exports
file.) Type man 1M exportfs
for more information. You cannot export a directory and its ancestor or descendant,
if they are on the same disk or logical volume. For example, if
you are exporting the root directory (/),
you cannot also export /opt,
unless / and
/opt are on different
disks or logical volumes. Likewise, if you are exporting /opt/frame,
you cannot also export /opt
unless /opt/frame
and /opt are
on different disks or logical volumes. However, if a directory and
its ancestor or descendant are on different
disks or logical volumes, and you want to export both of them, you
must export them using two separate entries
in /etc/exports.
Use the bdf(1M)
command to determine whether your file systems are on different
disks or logical volumes. Each line in the bdf
output is a separate disk or volume that requires its own entry
in /etc/exports
if you want to export it. The /etc/exports
file should be owned by root and have mode 644 (-rw-r--r--). The export options that restrict access to an exported directory
are applied in addition to the regular HP-UX permissions already
in place on that directory. For example, if only the owner of a
file has permission to write to it, nobody else can write to the
file, even if it is exported to the world with read/write permission. Access permissions may also be specified on the NFS client
when a directory is mounted. If these permissions are different
from the permissions for the exported directory on the NFS server,
the more restrictive permissions are used. It is not a good idea to export a directory if it contains
a symbolic link that points outside the exported directory. Once
the directory is mounted on an NFS client, the symbolic link will
be resolved locally on the client, so the destination of the symbolic
link must exist on the client as well as the server. If the destination
of the symbolic link does not exist on the client, a No such file or directory
message will be displayed whenever anyone attempts access to it. Figure 2-1 “Symbolic
Links in NFS Mounts” illustrates the
problem of symbolic links in NFS mounts, where the destination of
the symbolic link exists on the NFS server but might not exist on
the NFS client. Examples from /etc/exportsThe following example exports the /usr/bin
directory to NFS clients cabbage,
cauliflower,
and broccoli.
Users on client broccoli
have read/write access to the /usr/bin
directory. Users on cabbage
and cauliflower
have read-only access. In addition to the export options, the HP-UX
permissions for the /usr/bin
directory must be set to allow access to the world or to a group
that includes the users on broccoli,
cabbage and cauliflower. /usr/bin -access=cabbage:cauliflower:broccoli,rw=broccoli |
The following example allows all NFS clients read-only access
to the directory /usr/share/man.
The /usr/share/man
directory must also allow read access to NFS users (for example,
with -r--r--r--
permissions). The following example exports the /var/mail
directory. It allows root access to clients sage,
thyme, and basil.
The root users on all other NFS clients are considered "unknown"
to the NFS server, so they are given the access privileges of user
nobody. Non-root
users on all NFS clients are allowed read/write access to the /var/mail
directory, if the HP-UX permissions on the /var/mail
directory allow them read/write access. /var/mail -root=sage:thyme:basil |
The following example exports the private root directory of
diskless client sage.
It allows root access to the root user on client sage.
All other users on client sage
have read/write access, if they are allowed read/write access through
the regular HP-UX permissions. Users on other NFS clients have read-only
access, if they are allowed read access through the HP-UX permissions. /export/private_roots/sage -rw=sage,root=sage |
In the following example, any user without a valid user ID
who attempts access to client basil's
private root directory will receive an RPC authentication error,
because anonymous access is denied with the anon=65535
option. The root user on client basil
is allowed root access to the directory, but the root users on all
other machines are treated as "unknown" and denied
access. The non-root users on all NFS clients are allowed read/write
access, if the HP-UX permissions on that directory allow them read/write
access. /export/private_roots/basil -root=basil,anon=65535 |
The following example exports the /export/newsletter
directory to all NFS clients. Root users will be given the effective
user ID of 200. Other anonymous users will keep their own user IDs
(even though they do not exist in the NFS server's passwd
database), but they will be given the access permissions associated
with user ID 200. If a root user is allowed to create a file in
this directory, the ls
command will show that it is owned by user ID 200. If an anonymous
user with a non-zero user ID (for example, 840) is allowed to create
a file in this directory, the ls
command will show that it is owned by user ID 840. /export/newsletter -anon=200 |
The following example exports the /opt/frame
directory to all NFS clients. Non-root users have read/write access
(if the regular HP-UX permissions allow it), and root users are
given the access privileges of user nobody.
NFS writes are done asynchronously; that is, when an NFS client
writes data to a mounted directory, the server returns a response
before writing the data to disk. This allows the client to continue
processing without waiting for the write request to complete. To Remove (Unexport)
an Exported Directory | |
On the NFS server, issue the following command for a list
of all the NFS clients that have mounted the directory you want
to unexport: | | | |  | NOTE: The output of the showmount
command is not always complete. If an NFS client mounts a remote
directory twice and unmounts it only once, the remote directory
is still mounted on the client, but the showmount
command does not list that client. Also, clients configured to automount
a directory will not be listed by the showmount
command if the directory is not currently mounted. | | | | |
On every NFS client that has the directory mounted,
issue the following command for a list of the process IDs and user
names of everyone using the mounted directory: /usr/sbin/fuser -u servername:/directory |
Warn any users to cd
out of the directory, and kill any processes that are using the
directory, or wait until the processes terminate. You can use the
following command to kill all processes using the directory: /usr/sbin/fuser -ck local_mount_point |
On every NFS client that has the directory mounted,
issue the following command to unmount the directory: /usr/sbin/umount local_mount_point |
or /usr/sbin/umount servername:/directory |
On every NFS client that had the directory mounted,
use a text editor to comment out or remove the line in the /etc/fstab
file that lists the directory you want to unexport. This prevents
clients from attempting to mount the directory when they reboot. On every client that has the directory configured
to be automounted, edit the /etc/auto_*
files to comment out or remove the directory from the automounter
maps. Clients that automount the directory may not be listed by
the showmount
command. If you are using NIS to manage your automounter maps, edit
the /etc/auto_*
files on the NIS master server, and then issue the following commands
to regenerate the maps and push them to the slave servers: cd /var/yp
/usr/ccs/bin/make auto_mapname auto_mapname ... |
If you modified the automounter master map, or if
you added or deleted an entry in an automounter direct map, issue
the following command, on all clients that use the map, to force
AutFS to reread its maps: On the NFS server, use a text editor to remove the
line in the /etc/exports
file that lists the directory you want to unexport. On the NFS server, issue the following command to
unexport the directory: /usr/sbin/exportfs -u directory |
If you unexport a directory that an NFS client currently has
mounted, the next time someone on that client requests access to
the directory, NFS will return an NFS stale file handle
error message. The client may be able to unmount the directory,
but if that does not work, the client must reboot to recover. For more information, see the following man pages: showmount(1M),
fuser(1M), umount(1M),
and exportfs(1M),
automount(1M), make(1),
and ypmake(1M). To Enable PC NFS Server
Capability | |
If necessary, create a file called /etc/pcnfsd.conf
and add PC NFS configuration information to it. The /etc/pcnfsd.conf
file is not required in order to run pcnfsd.
For more information on the /etc/pcnfsd.conf
file, type man 1M pcnfsd
at the HP-UX prompt. In the /etc/rc.config.d/nfsconf
file, use a text editor to set the PCNFS_SERVER
flag to 1, as follows: Issue the following command to run the NFS startup
script: /sbin/init.d/nfs.server start |
The PCNFS_SERVER
flag causes the NFS startup script to start the PC NFS server daemon,
pcnfsd. As a
PC NFS server, your system can export its directories and files
to PC NFS clients. Following are some reasons why you might want to create an
/etc/pcnfsd.conf
file: If your PC NFS client software is
assigning user IDs smaller than 101 or greater than 60002, set the
uidrange in the
/etc/pcnfsd.conf
file to allow access to a different range of user IDs, as in the
following example: If you want to give PC users a different set of
default print options, the /etc/pcnfsd.conf
file should contain a line similar to the following, which defines
raw as a default
print option for PC users submitting jobs to the printer lj3_2: printer lj3_2 lj3_2 lp -dlj3_2 -oraw |
The /etc/pcnfsd.conf
file is read when the pcnfsd
daemon starts up. If you make any changes to /etc/pcnfsd.conf
while pcnfsd
is running, you must restart pcnfsd
before your changes will take effect. A PC must have NFS client software installed in order to use
your system as a PC NFS server. For more information on pcnfsd,
type man 1M pcnfsd
at the HP-UX prompt. To Disable NFS Server
Capability | |
On the NFS server, issue the following command for a list
of all the NFS clients that have directories mounted from the NFS
server you are planning to disable: | | | | | NOTE: The output of the showmount
command is not always complete. If an NFS client mounts a remote
directory twice and unmounts it only once, the remote directory
is still mounted on the client, but the showmount
command does not list that client. Also, clients that are configured
to automount a directory will not be listed by the showmount
command if the directory is not currently mounted. | | | | |
On every NFS client listed by the showmount
command, issue the following command for each directory that is
mounted from your NFS server: /usr/sbin/fuser -u servername:/directory |
This command lists the process IDs and user names of everyone
using the mounted directory. Warn any users to cd
out of the directory, and kill any processes that are using the
directory, or wait until the processes terminate. You can use the
following command to kill all processes using the directory: /usr/sbin/fuser -ck local_mount_point |
On every client that has directories mounted from
your server, issue the following command: /usr/sbin/umount -h servername |
If your server will be down for a long time, edit
the /etc/fstab
file on each client to comment out or remove any NFS mounts from
the server you are planning to disable. This prevents the clients
from attempting to mount directories from your server when the clients
are rebooted. If your server will be down for a long time, edit
the /etc/auto_*
files on each client to comment out or remove any automounts from
the server you are planning to disable. Clients that automount the
server's directories might not be listed by the showmount
command. If you are using NIS to manage your automounter maps, edit
the /etc/auto_*
files on the NIS master server, and then issue the following commands
to regenerate the maps and push them to the slave servers: cd /var/yp
/usr/ccs/bin/make auto_mapname auto_mapname ... |
If you modified the automounter master map, or if
you added or deleted any entries in an automounter direct map, issue
the following command, on all clients that use the map, to force
AutoFS to reread its maps: Issue the following command on the server to unexport
all exported directories: On the NFS server, edit the /etc/rc.config.d/nfsconf
file to set the NFS_SERVER
variable to 0. This prevents the NFS server daemons
from starting up when your system reboots. If your server will be
down only a short time, this step is unnecessary. Edit the /etc/inetd.conf
file to comment out the line that contains rpc.mountd
(if it exists) and the lines for the other RPC services. Issue the following command to disable NFS server
capability: /sbin/init.d/nfs.server stop |
If your NFS server will be down for only a very short period
of time, this procedure is not necessary. If the server is down
for only a few minutes, and directories are hard-mounted on the
clients, clients attempting access to the server will simply hang
until it comes back up. Then, they will resume access to it as if
nothing had happened. However, if the server will be down for a long time, NFS clients
attempting access to it will have to interrupt their attempts, usually
with [CTRL]-C.
If directories are mounted with the nointr
option, clients must reboot their systems in order to stop trying
to access a down server. See the following man pages for more information: showmount(1M),
fuser(1M), exportfs(1M),
automount(1M), and mountd(1M). |
Printable version
