ACC SHELL
<html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>Chapter 26. Sharing File Systems with NFS</title><link rel="stylesheet" href="susebooks.css" type="text/css"><meta name="generator" content="DocBook XSL Stylesheets V1.75.2"><link rel="home" href="index.html" title="Documentation"><link rel="up" href="part.reference.services.html" title="Part V. Services"><link rel="prev" href="cha.netz.xntp.html" title="Chapter 25. Time Synchronization with NTP"><link rel="next" href="cha.samba.html" title="Chapter 27. Samba"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="navheader"><table width="100%" summary="Navigation header" border="0" class="bctable"><tr><td width="80%"><div class="breadcrumbs"><p><a href="index.html"> Documentation</a><span class="breadcrumbs-sep"> > </span><a href="book.opensuse.reference.html">Reference</a><span class="breadcrumbs-sep"> > </span><a href="part.reference.services.html">Services</a><span class="breadcrumbs-sep"> > </span><strong><a accesskey="p" title="Chapter 25. Time Synchronization with NTP" href="cha.netz.xntp.html"><span>◀</span></a> <a accesskey="n" title="Chapter 27. Samba" href="cha.samba.html"><span>▶</span></a></strong></p></div></td></tr></table></div><div class="chapter" title="Chapter 26. Sharing File Systems with NFS"><div class="titlepage"><div><div><h2 class="title"><a name="cha.nfs"></a>Chapter 26. Sharing File Systems with NFS<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#cha.nfs">¶</a></span></h2></div></div></div><div class="toc"><p><b>Contents</b></p><dl><dt><span class="sect1"><a href="cha.nfs.html#sec.nfs.installation">26.1. Installing the Required Software</a></span></dt><dt><span class="sect1"><a href="cha.nfs.html#sec.nfs.import-yast2">26.2. Importing File Systems with YaST</a></span></dt><dt><span class="sect1"><a href="cha.nfs.html#sec.nfs.import">26.3. Importing File Systems Manually</a></span></dt><dt><span class="sect1"><a href="cha.nfs.html#sec.nfs.export-yast2">26.4. Exporting File Systems with YaST</a></span></dt><dt><span class="sect1"><a href="cha.nfs.html#sec.nfs.export.manual">26.5. Exporting File Systems Manually</a></span></dt><dt><span class="sect1"><a href="cha.nfs.html#sec.nfs.kerberos">26.6. NFS with Kerberos</a></span></dt><dt><span class="sect1"><a href="cha.nfs.html#sec.nfs.info">26.7. For More Information</a></span></dt></dl></div><a class="indexterm" name="id490287"></a><a class="indexterm" name="id490292"></a><p>
Distributing and sharing file systems over a network is a common task in
corporate environments. The proven <code class="systemitem">NFS</code> system
works together with <code class="systemitem">NIS</code>, the yellow pages
protocol. For a more secure protocol that works together with
<code class="systemitem">LDAP</code> and may also be kerberized, check
<code class="systemitem">NFSv4</code>.
</p><p>
NFS with NIS makes a network transparent to the user. With NFS, it is
possible to distribute arbitrary file systems over the network. With an
appropriate setup, users always find themselves in the same environment
regardless of the terminal they currently use.
</p><p>
Like NIS, NFS is a client/server system. However, a machine can be
both—it can supply file systems over the network (export) and mount
file systems from other hosts (import).
</p><div class="important"><table border="0" cellpadding="3" cellspacing="0" width="100%" summary="Important: Need for DNS"><tr class="head"><td width="32"><img alt="[Important]" src="admon/important.png"></td><th align="left">Need for DNS</th></tr><tr><td colspan="2" align="left" valign="top"><p>
In principle, all exports can be made using IP addresses only. To avoid
time-outs, you need a working DNS system. DNS is necessary at least for
logging purposes, because the mountd daemon does reverse lookups.
</p></td></tr></table></div><div class="sect1" title="26.1. Installing the Required Software"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="sec.nfs.installation"></a>26.1. Installing the Required Software<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.nfs.installation">¶</a></span></h2></div></div></div><p>
To configure your host as an NFS client, you do not need to install
additional software. All needed packages are installed by default.
</p><p>
NFS server software is not part of the default installation. To install
the NFS server software, start YaST and select
<span class="guimenu">Software</span>+<span class="guimenu">Software
Management</span>. Now choose
<span class="guimenu">Filter</span>+<span class="guimenu">Patterns</span> and select <span class="guimenu">File
Server</span> or use the <span class="guimenu">Search</span> option and search
for <code class="literal">NFS Server</code>. Confirm the installation of the
packages to finish the installation process.
</p></div><div class="sect1" title="26.2. Importing File Systems with YaST"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="sec.nfs.import-yast2"></a>26.2. Importing File Systems with YaST<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.nfs.import-yast2">¶</a></span></h2></div></div></div><a class="indexterm" name="id490411"></a><p>
Authorized users can mount NFS directories from an NFS server into the
local file tree using the YaST NFS client module. Click on
<span class="guimenu">Add</span> and enter the hostname of the NFS server, the
directory to import, and the mount point at which to mount this directory
locally. The changes will take effect after <span class="guimenu">Finish</span> is
clicked in the first dialog.
</p><p>
In the <span class="guimenu">NFS Settings</span> tab, enable <span class="guimenu">Open Port in
Firewall</span> to allow access to the service from remote computers.
The firewall status is displayed next to the check box. When using NFSv4,
make sure that the checkbox <span class="guimenu">Enable NFSv4</span> is enabled,
and that the <span class="guimenu">NFSv4 Domain Name</span> contains the same value
as used by the NFSv4 server. The default domain is
<code class="literal">localdomain</code>.
</p><p>
Click <span class="guimenu">OK</span> to save your changes. See
<a class="xref" href="cha.nfs.html#fig.yast2.nfs.client" title="Figure 26.1. NFS Client Configuration with YaST">Figure 26.1, “NFS Client Configuration with YaST”</a>.
</p><p>
The configuration is written to <code class="filename">/etc/fstab</code> and the
specified file systems are mounted. When you start the YaST
configuration client at a later time, it also reads the existing
configuration from this file.
</p><div class="figure"><a name="fig.yast2.nfs.client"></a><p class="title"><b>Figure 26.1. NFS Client Configuration with YaST</b><span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#fig.yast2.nfs.client">¶</a></span></p><div class="figure-contents"><div class="mediaobject"><table border="0" summary="manufactured viewport for HTML img" cellspacing="0" cellpadding="0" width="75%"><tr><td><img src="images/yast2_nfsclient.png" width="100%" alt="NFS Client Configuration with YaST"></td></tr></table></div></div></div><br class="figure-break"></div><div class="sect1" title="26.3. Importing File Systems Manually"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="sec.nfs.import"></a>26.3. Importing File Systems Manually<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.nfs.import">¶</a></span></h2></div></div></div><a class="indexterm" name="id490537"></a><a class="indexterm" name="id490546"></a><p>
The prerequisite for importing file systems manually from an NFS server
is a running RPC port mapper. Start it by entering <span class="command"><strong>rcrpcbind
<code class="option">start</code></strong></span> as
<code class="systemitem">root</code>. Then remote file
systems can be mounted in the file system like local partitions using
<span class="command"><strong>mount</strong></span>:
</p><pre class="screen">mount <em class="replaceable"><code>host</code></em>:<em class="replaceable"><code>remote-path</code></em> <em class="replaceable"><code>local-path</code></em>
</pre><p>
To import user directories from the <code class="systemitem">nfs.example.com</code>
machine, for example, use:
</p><pre class="screen">mount nfs.example.com:/home /home
</pre><div class="sect2" title="26.3.1. Using the Automount Service"><div class="titlepage"><div><div><h3 class="title"><a name="sec.nfs.automount"></a>26.3.1. Using the Automount Service<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.nfs.automount">¶</a></span></h3></div></div></div><p>
The autofs daemon can be used to mount remote file systems
automatically. Add the following entry in the your
<code class="filename">/etc/auto.master</code> file:
</p><pre class="screen">/nfsmounts /etc/auto.nfs</pre><p>
Now the <code class="filename">/nfsmounts</code> directory acts as the root for
all the NFS mounts on the client if the <code class="filename">auto.nfs</code>
file is filled appropriately. The name <code class="filename">auto.nfs</code> is
chosen for the sake of convenience—you can choose any name. In
<code class="filename">auto.nfs</code> add entries for all the NFS mounts as
follows:
</p><pre class="screen">localdata -fstype=nfs server1:/data
nfs4mount -fstype=nfs4 server2:/</pre><p>
Activate the settings with <span class="command"><strong>rcautofs start</strong></span> as
<code class="systemitem">root</code>. In this example, <code class="filename">/nfsmounts/localdata</code>,
the <code class="filename">/data</code> directory of
<code class="systemitem">server1</code>, is mounted with NFS and
<code class="filename">/nfsmounts/nfs4mount</code> from
<code class="systemitem">server2</code> is mounted with NFSv4.
</p><p>
If the <code class="filename">/etc/auto.master</code> file is edited while the
service autofs is running, the automounter must be restarted for the
changes to take effect with <span class="command"><strong>rcautofs restart</strong></span>.
</p></div><div class="sect2" title="26.3.2. Manually Editing /etc/fstab"><div class="titlepage"><div><div><h3 class="title"><a name="sec.nfs.fstab"></a>26.3.2. Manually Editing <code class="filename">/etc/fstab</code><span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.nfs.fstab">¶</a></span></h3></div></div></div><p>
A typical NFSv3 mount entry in <code class="filename">/etc/fstab</code> looks
like this:
</p><pre class="screen">nfs.example.com:/data /local/path nfs rw,noauto 0 0</pre><p>
NFSv4 mounts may also be added to the <code class="filename">/etc/fstab</code>
file. For these mounts, use <code class="literal">nfs4</code> instead of
<code class="literal">nfs</code> in the third column and make sure that the remote
file system is given as <code class="filename">/</code> after the
<em class="replaceable"><code>nfs.example.com:</code></em> in the first column. A sample line
for an NFSv4 mount in <code class="filename">/etc/fstab</code> looks like this:
</p><pre class="screen">nfs.example.com:/ /local/pathv4 nfs4 rw,noauto 0 0</pre><p>
The <code class="literal">noauto</code> option prevents the file system from being
mounted automatically at start up. If you want to mount the respective
file system manually, it is possible to shorten the mount command
specifying the mount point only:
</p><pre class="screen">mount /local/path</pre><p>
Note, that if you do not enter the <code class="literal">noauto</code> option, the
initialization scripts of the system will handle the mount of those file
systems at start up.
</p></div></div><div class="sect1" title="26.4. Exporting File Systems with YaST"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="sec.nfs.export-yast2"></a>26.4. Exporting File Systems with YaST<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.nfs.export-yast2">¶</a></span></h2></div></div></div><a class="indexterm" name="id490786"></a><p>
With YaST, turn a host in your network into an NFS server—a
server that exports directories and files to all hosts granted access to
it. This could be done to provide applications to all members of a group
without installing the applications locally on each and every host. To
install such a server, start YaST and select <span class="guimenu">Network Services</span>+<span class="guimenu">NFS
Server</span>; see
<a class="xref" href="cha.nfs.html#fig.inst.nfsserver1" title="Figure 26.2. NFS Server Configuration Tool">Figure 26.2, “NFS Server Configuration Tool”</a>.
</p><div class="figure"><a name="fig.inst.nfsserver1"></a><p class="title"><b>Figure 26.2. NFS Server Configuration Tool</b><span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#fig.inst.nfsserver1">¶</a></span></p><div class="figure-contents"><div class="mediaobject"><table border="0" summary="manufactured viewport for HTML img" cellspacing="0" cellpadding="0" width="75%"><tr><td><img src="images/yast2_inst_nfsserver1.png" width="100%" alt="NFS Server Configuration Tool"></td></tr></table></div></div></div><br class="figure-break"><p>
Then activate <span class="guimenu">Start</span> and enter the <span class="guimenu">NFSv4
Domain Name</span>.
</p><p>
Click <span class="guimenu">Enable GSS Security</span> if you need secure access to
the server. A prerequisite for this is to have Kerberos installed on your
domain and to have both the server and the clients kerberized. Click
<span class="guimenu">Next</span>.
</p><p>
In the upper text field, enter the directories to export. Below, enter
the hosts that should have access to them. This dialog is shown in
<a class="xref" href="cha.nfs.html#fig.inst.nfsserver2" title="Figure 26.3. Configuring an NFS Server with YaST">Figure 26.3, “Configuring an NFS Server with YaST”</a>. The
figure shows the scenario where NFSv4 is enabled in the previous dialog.
<code class="literal">Bindmount Targets</code> is shown in the right pane. For more
details, click <span class="guimenu">Help</span>. In the lower half of the dialog,
there are four options that can be set for each host: <code class="option">single
host</code>, <code class="option">netgroups</code>, <code class="option">wildcards</code>,
and <code class="option">IP networks</code>. For a more thorough explanation of
these options, refer to the <code class="option">exports</code> man page. Click
<span class="guimenu">Finish</span> to complete the configuration.
</p><div class="figure"><a name="fig.inst.nfsserver2"></a><p class="title"><b>Figure 26.3. Configuring an NFS Server with YaST</b><span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#fig.inst.nfsserver2">¶</a></span></p><div class="figure-contents"><div class="mediaobject"><table border="0" summary="manufactured viewport for HTML img" cellspacing="0" cellpadding="0" width="75%"><tr><td><img src="images/yast2_inst_nfsserver2.png" width="100%" alt="Configuring an NFS Server with YaST"></td></tr></table></div></div></div><br class="figure-break"><div class="important"><table border="0" cellpadding="3" cellspacing="0" width="100%" summary="Important: Automatic Firewall Configuration"><tr class="head"><td width="32"><img alt="[Important]" src="admon/important.png"></td><th align="left">Automatic Firewall Configuration</th></tr><tr><td colspan="2" align="left" valign="top"><p>
If a firewall is active on your system (SuSEfirewall2), YaST adapts
its configuration for the NFS server by enabling the
<code class="literal">nfs</code> service when <span class="guimenu">Open Ports in
Firewall</span> is selected.
</p></td></tr></table></div><div class="sect2" title="26.4.1. Exporting for NFSv4 Clients"><div class="titlepage"><div><div><h3 class="title"><a name="sec.nfs.exportv4"></a>26.4.1. Exporting for NFSv4 Clients<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.nfs.exportv4">¶</a></span></h3></div></div></div><p>
Activate <span class="guimenu">Enable NFSv4</span> to support NFSv4 clients.
Clients with NFSv3 can still access the server's exported directories if
they are exported appropriately. This is explained in detail in
<a class="xref" href="cha.nfs.html#sec.nfs.export.coexisting" title="26.4.3. Coexisting v3 and v4 Exports">Section 26.4.3, “Coexisting v3 and v4 Exports”</a>.
</p><p>
After activating NFSv4, enter an appropriate domain name. Make sure the
name is the same as the one in the <code class="filename">
/etc/idmapd.conf</code> file of any NFSv4 client that accesses this
particular server. This parameter is for the idmapd service that is
required for NFSv4 support (on both server and client). Leave it as
<code class="literal">localdomain</code> (the default) if you do not have special
requirements. For more information, see the links in
<a class="xref" href="cha.nfs.html#sec.nfs.info" title="26.7. For More Information">Section 26.7, “For More Information”</a>.
</p><p>
Click <span class="guimenu">Next</span>. The dialog that follows has two sections.
The upper half consists of two columns named
<span class="guimenu">Directories</span> and <span class="guimenu">Bind Mount Targets</span>
. <span class="guimenu">Directories</span> is a directly editable column that
lists the directories to export.
</p><p>
For a fixed set of clients, there are two types of directories that can
be exported—directories that act as pseudo root file systems and
those that are bound to some subdirectory of the pseudo file system.
This pseudo file system acts as a base point under which all file
systems exported for the same client set take their place. For a client
or set of clients, only one directory on the server can be configured as
pseudo root for export. For this client, export multiple directories by
binding them to some existing subdirectory in the pseudo root.
</p><div class="figure"><a name="id491071"></a><p class="title"><b>Figure 26.4. Exporting Directories with NFSv4</b></p><div class="figure-contents"><div class="mediaobject"><table border="0" summary="manufactured viewport for HTML img" cellspacing="0" cellpadding="0" width="75%"><tr><td><img src="images/nfs_001a.png" width="100%" alt="Exporting Directories with NFSv4"></td></tr></table></div></div></div><br class="figure-break"><p>
In the lower half of the dialog, enter the client (wild card) and export
options for a particular directory. After adding a directory in the
upper half, another dialog for entering the client and option
information pops up automatically. After that, to add a new client
(client set), click <span class="guimenu">Add Host</span>.
</p><p>
In the small dialog that opens, enter the host wild card. There are four
possible types of host wild cards that can be set for each host: a
single host (name or IP address), netgroups, wild cards (such as
<code class="literal">*</code> indicating all machines can access the server), and
IP networks. Then, in <span class="guimenu">Options</span>, include
<code class="literal">fsid=0</code> in the comma-separated list of options to
configure the directory as pseudo root. If this directory needs to be
bound to another directory under an already configured pseudo root, make
sure that a target bind path is given in the option list with
<code class="literal">bind=/target/path</code>.
</p><p>
For example, suppose that the directory <code class="filename">/exports</code> is
chosen as the pseudo root directory for all the clients that can access
the server. Then add this in the upper half and make sure that the
options entered for this directory include <code class="literal">fsid=0</code>. If
there is another directory, <code class="filename">/data</code>, that also needs
to be NFSv4 exported, add this directory to the upper half. While
entering options for this, make sure that
<code class="literal">bind=/exports/data</code> is in the list and that
<code class="filename">/exports/data</code> is an already existing subdirectory
of <code class="filename">/exports</code>. Any change in the option
<code class="systemitem">bind=/target/path</code>, whether addition, deletion,
or change in value, is reflected in <span class="guimenu">Bindmount
Targets</span>. This column is not a directly editable column, but
instead summarizes directories and their nature. After all information
is provided, click <span class="guimenu">Finish</span> to complete the
configuration. The service will become available immediately.
</p></div><div class="sect2" title="26.4.2. NFSv3 and NFSv2 Exports"><div class="titlepage"><div><div><h3 class="title"><a name="sec.nfs.exportv23"></a>26.4.2. NFSv3 and NFSv2 Exports<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.nfs.exportv23">¶</a></span></h3></div></div></div><p>
Make sure that <span class="guimenu">Enable NFSv4</span> is not checked in the
initial dialog before clicking <span class="guimenu">Next</span>.
</p><p>
The next dialog has two parts. In the upper text field, enter the
directories to export. Below, enter the hosts that should have access to
them. There are four types of host wild cards that can be set for each
host: a single host (name or IP address), netgroups, wild cards (such as
<code class="literal">*</code> indicating all machines can access the server), and
IP networks.
</p><p>
This dialog is shown in
<a class="xref" href="cha.nfs.html#fig.nfs.export23" title="Figure 26.5. Exporting Directories with NFSv2 and v3">Figure 26.5, “Exporting Directories with NFSv2 and v3”</a>. Find a more
thorough explanation of these options in <span class="command"><strong>man exports</strong></span>.
Click <span class="guimenu">Finish</span> to complete the configuration.
</p><div class="figure"><a name="fig.nfs.export23"></a><p class="title"><b>Figure 26.5. Exporting Directories with NFSv2 and v3</b><span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#fig.nfs.export23">¶</a></span></p><div class="figure-contents"><div class="mediaobject"><table border="0" summary="manufactured viewport for HTML img" cellspacing="0" cellpadding="0" width="75%"><tr><td><img src="images/nfs_002a.png" width="100%" alt="Exporting Directories with NFSv2 and v3"></td></tr></table></div></div></div><br class="figure-break"></div><div class="sect2" title="26.4.3. Coexisting v3 and v4 Exports"><div class="titlepage"><div><div><h3 class="title"><a name="sec.nfs.export.coexisting"></a>26.4.3. Coexisting v3 and v4 Exports<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.nfs.export.coexisting">¶</a></span></h3></div></div></div><p>
Both, NFSv3 and NFSv4 exports can coexist on a server. After enabling
the support for NFSv4 in the initial configuration dialog, those exports
for which <code class="systemitem">fsid=0</code> and
<code class="systemitem">bind=/target/path</code> are not included in the
option list are considered v3 exports. Consider the example in
<a class="xref" href="cha.nfs.html#fig.inst.nfsserver2" title="Figure 26.3. Configuring an NFS Server with YaST">Figure 26.3, “Configuring an NFS Server with YaST”</a>. If you
add another directory, such as <code class="filename">/data2</code>, using
<span class="guimenu">Add Directory</span> then in the corresponding options list
do not mention either <code class="systemitem">fsid=0</code> or
<code class="systemitem">bind=/target/path</code>, this export acts as a v3
export.
</p><div class="important"><table border="0" cellpadding="3" cellspacing="0" width="100%" summary="Important"><tr class="head"><td width="32"><img alt="[Important]" src="admon/important.png"></td><th align="left"></th></tr><tr><td colspan="2" align="left" valign="top"><p>
Automatic Firewall Configuration
</p><p>
If SuSEfirewall2 is active on your system, YaST adapts its
configuration for the NFS server by enabling the <code class="literal">nfs</code>
service when <span class="guimenu">Open Ports in Firewall</span> is selected.
</p></td></tr></table></div></div></div><div class="sect1" title="26.5. Exporting File Systems Manually"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="sec.nfs.export.manual"></a>26.5. Exporting File Systems Manually<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.nfs.export.manual">¶</a></span></h2></div></div></div><a class="indexterm" name="id491371"></a><p>
The configuration files for the NFS export service are
<code class="filename">/etc/exports</code> and
<code class="filename">/etc/sysconfig/nfs</code>. In addition to these files,
<code class="filename">/etc/idmapd.conf</code> is needed for the NFSv4 server
configuration. To start or restart the services, run the command
<span class="command"><strong>rcnfsserver restart</strong></span>. This also starts the
<code class="literal">rpc.idmapd</code> if NFSv4 is configured in
<code class="filename">/etc/sysconfig/nfs</code>. The NFS server depends on a
running RPC portmapper. Therefore, also start or restart the portmapper
service with <span class="command"><strong>rcrpcbind restart</strong></span>.
</p><div class="sect2" title="26.5.1. Exporting File Systems with NFSv4"><div class="titlepage"><div><div><h3 class="title"><a name="sec.nfs.manexportv4"></a>26.5.1. Exporting File Systems with NFSv4<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.nfs.manexportv4">¶</a></span></h3></div></div></div><p>
NFSv4 is the latest version of NFS protocol available on openSUSE.
Configuring directories for export with NFSv4 differs slightly from
previous NFS versions.
</p><div class="sect3" title="26.5.1.1. /etc/exports"><div class="titlepage"><div><div><h4 class="title"><a name="sec.nfs.exports"></a>26.5.1.1. /etc/exports<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.nfs.exports">¶</a></span></h4></div></div></div><p>
The <code class="filename">/etc/exports</code> file contains a list of entries.
Each entry indicates a directory that is shared and how it is shared. A
typical entry in <code class="filename">/etc/exports</code> consists of:
</p><pre class="screen">/shared/directory host(option_list)</pre><p>
For example:
</p><pre class="screen">/export 192.168.1.2(rw,fsid=0,sync,crossmnt)
/export/data 192.168.1.2(rw,bind=/data,sync)
</pre><p>
Here the IP address <code class="literal">192.168.1.2</code> is used to identify
the allowed client. You can also use the name of the host, a wild card
indicating a set of hosts (<code class="literal">*.abc.com</code>,
<code class="literal">*</code>, etc.), or netgroups
(<code class="literal">@my-hosts</code>).
</p><p>
The directory which specifies <code class="literal">fsid=0</code> is special in
that it is the root of the filesystem that is exported, sometime
referred to as the pseudo root filesystem. This directory must also
have the <code class="literal">crossmnt</code> for correct operation with NFSv4.
All other directories exported via NFSv4 must be mounted below this
point. If you want to export a directory that is not within the
exported root, it needs to be bound into the exported tree. This can be
done using the <code class="literal">bind=</code> syntax.
</p><p>
In the example above, <code class="filename">/data</code> is not within
<code class="filename">/export</code>, so we export
<code class="filename">/export/data</code>, and specify that the
<code class="filename">/data</code> directory should be bound to that name. The
directory <code class="filename">/export/data</code> must exist and should
normally be empty.
</p><p>
When clients mount from this server, they just mount
<code class="literal">servername:/</code> rather than
<code class="literal">servername:/export</code>. It is not necessary to mount
<code class="literal">servername:/data</code>, because it will automatically
appear beneath wherever <code class="literal">servername:/</code> was mounted.
</p></div><div class="sect3" title="26.5.1.2. /etc/sysconfig/nfs"><div class="titlepage"><div><div><h4 class="title"><a name="sec.nfs.sysconfig"></a>26.5.1.2. /etc/sysconfig/nfs<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.nfs.sysconfig">¶</a></span></h4></div></div></div><p>
The <code class="filename">/etc/sysconfig/nfs</code> file contains a few
parameters that determine NFSv4 server daemon behavior. Importantly,
the parameter <code class="systemitem">NFS4_SUPPORT</code> must be set to
<code class="literal">yes</code>. <code class="systemitem">NFS4_SUPPORT</code>
determines whether the NFS server supports NFSv4 exports and clients.
</p></div><div class="sect3" title="26.5.1.3. /etc/idmapd.conf"><div class="titlepage"><div><div><h4 class="title"><a name="sec.nfs.idmapd"></a>26.5.1.3. /etc/idmapd.conf<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.nfs.idmapd">¶</a></span></h4></div></div></div><p>
Every user on a Linux machine has a name and ID. idmapd does the
name-to-ID mapping for NFSv4 requests to the server and replies to the
client. It must be running on both server and client for NFSv4, because
NFSv4 uses only names for its communication.
</p><p>
Make sure that there is a uniform way in which usernames and IDs (uid)
are assigned to users across machines that might probably be sharing
file systems using NFS. This can be achieved by using NIS, LDAP, or any
uniform domain authentication mechanism in your domain.
</p><p>
The parameter <code class="literal">Domain</code> must be set the same for both,
client and server in the <code class="filename">/etc/idmapd.conf</code> file. If
you are not sure, leave the domain as <code class="literal">localdomain</code> in
the server and client files. A sample configuration file looks like the
following:
</p><pre class="screen">[General]
Verbosity = 0
Pipefs-Directory = /var/lib/nfs/rpc_pipefs
Domain = localdomain
[Mapping]
Nobody-User = nobody
Nobody-Group = nobody
</pre><p>
For further reference, read the man page of <code class="literal">idmapd</code>
and <code class="literal">idmapd.conf</code>; <code class="literal">man idmapd</code>,
<code class="literal">man idmapd.conf</code>.
</p></div><div class="sect3" title="26.5.1.4. Starting and Stopping Services"><div class="titlepage"><div><div><h4 class="title"><a name="sec.nfs.services"></a>26.5.1.4. Starting and Stopping Services<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.nfs.services">¶</a></span></h4></div></div></div><p>
After changing <code class="filename">/etc/exports</code> or
<code class="filename">/etc/sysconfig/nfs</code>, start or restart the NFS
server service with <span class="command"><strong>rcnfsserver restart</strong></span>. After
changing <code class="filename">/etc/idmapd.conf</code>, reload the
configuration file with the command <span class="command"><strong>killall -HUP
rpc.idmapd</strong></span>.
</p><p>
If the NFS service needs to start at boot time, run the command
<span class="command"><strong>chkconfig nfsserver on</strong></span>.
</p></div></div><div class="sect2" title="26.5.2. Exporting File Systems with NFSv2 and NFSv3"><div class="titlepage"><div><div><h3 class="title"><a name="sec.nfs.manualexportv23"></a>26.5.2. Exporting File Systems with NFSv2 and NFSv3<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.nfs.manualexportv23">¶</a></span></h3></div></div></div><p>
This section is specific to NFSv3 and NFSv2 exports. Refer to
<a class="xref" href="cha.nfs.html#sec.nfs.exportv4" title="26.4.1. Exporting for NFSv4 Clients">Section 26.4.1, “Exporting for NFSv4 Clients”</a> for
exporting with NFSv4.
</p><p>
Exporting file systems with NFS involves two configuration files:
<code class="filename">/etc/exports</code> and
<code class="filename">/etc/sysconfig/nfs</code>. A typical
<code class="filename">/etc/exports</code> file entry is in the format:
</p><pre class="screen">/shared/directory host(list_of_options)</pre><p>
For example:
</p><pre class="screen">/export 192.168.1.2(rw,sync)</pre><p>
Here, the directory <code class="filename">/export</code> is shared with the host
<code class="literal">192.168.1.2</code> with the option list
<code class="systemitem">rw,sync</code>. This IP address can be replaced with a
client name or set of clients using a wild card (such as
<code class="literal">*.abc.com</code>) or even netgroups.
</p><p>
For a detailed explanation of all options and their meaning, refer to
the man page of <span class="command"><strong>exports</strong></span> (<span class="command"><strong>man
exports</strong></span>).
</p><p>
After changing <code class="filename">/etc/exports</code> or
<code class="filename">/etc/sysconfig/nfs</code>, start or restart the NFS server
using the command <span class="command"><strong>rcnfsserver restart</strong></span>.
</p></div></div><div class="sect1" title="26.6. NFS with Kerberos"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="sec.nfs.kerberos"></a>26.6. NFS with Kerberos<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.nfs.kerberos">¶</a></span></h2></div></div></div><p>
To use Kerberos authentication for NFS, GSS security must be enabled. To
do so, select <span class="guimenu">Enable GSS Security</span> in the initial
YaST NFS Server dialog. You must have a working Kerberos server to use
this feature. YaST does not set up the server but just uses the
provided functionality. If you want to use Kerberos authentication in
addition to the YaST configuration, complete at least the following
steps before running the NFS configuration:
</p><div class="procedure"><ol class="procedure" type="1"><li><p>
Make sure that both the server and the client are in the same Kerberos
domain. They must access the same KDC (Key Distribution Center) server
and share their <code class="filename">krb5.keytab</code> file (the default
location on any machine is <code class="filename">/etc/krb5.keytab</code>). For
more information about Kerberos, see
Chapter <i>Network Authentication with Kerberos</i> (↑Security Guide).
</p></li><li><p>
Start the gssd service on the client with <span class="command"><strong>rcgssd
start</strong></span>.
</p></li><li><p>
Start the svcgssd service on the server with <span class="command"><strong>rcsvcgssd
start</strong></span>.
</p></li></ol></div><p>
For more information about configuring kerberized NFS, refer to the links
in <a class="xref" href="cha.nfs.html#sec.nfs.info" title="26.7. For More Information">Section 26.7, “For More Information”</a>.
</p></div><div class="sect1" title="26.7. For More Information"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="sec.nfs.info"></a>26.7. For More Information<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.nfs.info">¶</a></span></h2></div></div></div><p>
As well as the man pages of <span class="command"><strong>exports</strong></span>,
<span class="command"><strong>nfs</strong></span>, and <span class="command"><strong>mount</strong></span>, information about
configuring an NFS server and client is available in
<code class="filename">/usr/share/doc/packages/nfsidmap/README</code>. Online
documentation can be found at the following Web documents:
</p><div class="itemizedlist"><ul class="itemizedlist" type="bullet"><li class="listitem" style="list-style-type: disc"><p>
Find the detailed technical documentation online at
<a class="ulink" href="http://nfs.sourceforge.net/" target="_top">SourceForge</a>.
</p></li><li class="listitem" style="list-style-type: disc"><p>
For instructions for setting up kerberized NFS, refer to
<a class="ulink" href="http://www.citi.umich.edu/projects/nfsv4/linux/krb5-setup.html" target="_top">NFS
Version 4 Open Source Reference Implementation</a>.
</p></li><li class="listitem" style="list-style-type: disc"><p>
If you have questions on NFSv4, refer to the
<a class="ulink" href="http://www.citi.umich.edu/projects/nfsv4/linux/faq/" target="_top">Linux
NFSv4 FAQ</a>.
</p></li></ul></div></div></div><div class="navfooter"><table width="100%" summary="Navigation footer" border="0" class="bctable"><tr><td width="80%"><div class="breadcrumbs"><p><a href="index.html"> Documentation</a><span class="breadcrumbs-sep"> > </span><a href="book.opensuse.reference.html">Reference</a><span class="breadcrumbs-sep"> > </span><a href="part.reference.services.html">Services</a><span class="breadcrumbs-sep"> > </span><strong><a accesskey="p" title="Chapter 25. Time Synchronization with NTP" href="cha.netz.xntp.html"><span>◀</span></a> <a accesskey="n" title="Chapter 27. Samba" href="cha.samba.html"><span>▶</span></a></strong></p></div></td></tr></table></div></body></html>
ACC SHELL 2018