Editorial review of NFS chapter.
Divide config section into server stuff and client stuff. Sponsored by: iXsystems
This commit is contained in:
Dru Lavigne
parent
5fbf39a916
commit
816cfb90a8
Notes:
svn2git
2020-12-08 03:00:23 +00:00
svn path=/head/; revision=44430
1 changed files with 153 additions and 188 deletions
|
|
@ -472,25 +472,28 @@ server-program-arguments</programlisting>
|
|||
</sect1>
|
||||
|
||||
<sect1 xml:id="network-nfs">
|
||||
<!--
|
||||
<sect1info>
|
||||
<info>
|
||||
<title>Network File System (NFS)</title>
|
||||
|
||||
<authorgroup>
|
||||
<author>
|
||||
<personname>
|
||||
<firstname>Tom</firstname>
|
||||
<surname>Rhodes</surname>
|
||||
</personname>
|
||||
<contrib>Reorganized and enhanced by </contrib>
|
||||
</author>
|
||||
</authorgroup>
|
||||
<authorgroup>
|
||||
<author>
|
||||
<personname>
|
||||
<firstname>Bill</firstname>
|
||||
<surname>Swingle</surname>
|
||||
</personname>
|
||||
<contrib>Written by </contrib>
|
||||
</author>
|
||||
</authorgroup>
|
||||
</sect1info>
|
||||
-->
|
||||
<title>Network File System (NFS)</title>
|
||||
</info>
|
||||
|
||||
<indexterm><primary>NFS</primary></indexterm>
|
||||
<para>&os; supports the Network File System
|
||||
|
|
@ -499,8 +502,8 @@ server-program-arguments</programlisting>
|
|||
<acronym>NFS</acronym>, users and programs can access files on
|
||||
remote systems as if they were stored locally.</para>
|
||||
|
||||
<para>The most notable benefits that
|
||||
<acronym>NFS</acronym> provides are:</para>
|
||||
<para><acronym>NFS</acronym> has many practical uses. Some of
|
||||
the more common uses include:</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
|
|
@ -510,13 +513,24 @@ server-program-arguments</programlisting>
|
|||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>User home directories can be stored in one location
|
||||
and accessed by their owners over the network.</para>
|
||||
<para>Several clients may need access to the
|
||||
<filename>/usr/ports/distfiles</filename> directory.
|
||||
Sharing that directory allows for quick access to the
|
||||
source files without having to download them to each
|
||||
client.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>On large networks, it is often more convenient to
|
||||
configure a central <acronym>NFS</acronym> server on which
|
||||
all user home directories are stored. Users can log into
|
||||
a client anywhere on the network and have access to their
|
||||
home directories.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Administration of <acronym>NFS</acronym> exports is
|
||||
also simplified. For example, there is only one file
|
||||
simplified. For example, there is only one file
|
||||
system where security or backup policies must be
|
||||
set.</para>
|
||||
</listitem>
|
||||
|
|
@ -525,14 +539,16 @@ server-program-arguments</programlisting>
|
|||
<para>Removable media storage devices can be used by other
|
||||
machines on the network. This reduces the number of devices
|
||||
throughout the network and provides a centralized location
|
||||
to manage their security.</para>
|
||||
to manage their security. It is often more convenient to
|
||||
install software on multiple machines from a centralized
|
||||
installation media.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<para><acronym>NFS</acronym> consists of at least two main
|
||||
parts: a server and one or more clients. The client
|
||||
<para><acronym>NFS</acronym> consists of
|
||||
a server and one or more clients. The client
|
||||
remotely accesses the data that is stored on the server
|
||||
machine. In order for this to function properly a few
|
||||
machine. In order for this to function properly, a few
|
||||
processes have to be configured and running.</para>
|
||||
|
||||
<para>These daemons must be running on the server:</para>
|
||||
|
|
@ -571,15 +587,14 @@ server-program-arguments</programlisting>
|
|||
<row>
|
||||
<entry><application>nfsd</application></entry>
|
||||
<entry>The <acronym>NFS</acronym> daemon which services
|
||||
requests from the <acronym>NFS</acronym>
|
||||
requests from <acronym>NFS</acronym>
|
||||
clients.</entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry><application>mountd</application></entry>
|
||||
<entry>The <acronym>NFS</acronym> mount daemon which
|
||||
carries out the requests that &man.nfsd.8; passes on
|
||||
to it.</entry>
|
||||
carries out requests received from <application>nfsd</application>.</entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
|
|
@ -592,120 +607,98 @@ server-program-arguments</programlisting>
|
|||
</tgroup>
|
||||
</informaltable>
|
||||
|
||||
<para>Running &man.nfsiod.8; can improve performance on the
|
||||
client, but is not required.</para>
|
||||
<para>Running &man.nfsiod.8; on the
|
||||
client can improve performance, but is not required.</para>
|
||||
|
||||
<sect2 xml:id="network-configuring-nfs">
|
||||
<title>Configuring <acronym>NFS</acronym></title>
|
||||
<title>Configuring the Server</title>
|
||||
|
||||
<indexterm>
|
||||
<primary>NFS</primary>
|
||||
<secondary>configuration</secondary>
|
||||
</indexterm>
|
||||
|
||||
<para>Enabling the <acronym>NFS</acronym> server
|
||||
is straightforward. The required processes
|
||||
can be set to start at boot time by adding
|
||||
these options to
|
||||
<filename>/etc/rc.conf</filename>:</para>
|
||||
|
||||
<programlisting>rpcbind_enable="YES"
|
||||
nfs_server_enable="YES"
|
||||
mountd_flags="-r"</programlisting>
|
||||
|
||||
<para><application>mountd</application> runs automatically
|
||||
whenever the <acronym>NFS</acronym> server is enabled.</para>
|
||||
|
||||
<para>To enable the client, set this option in
|
||||
<filename>/etc/rc.conf</filename>:</para>
|
||||
|
||||
<programlisting>nfs_client_enable="YES"</programlisting>
|
||||
|
||||
<para><filename>/etc/exports</filename> specifies which file
|
||||
systems the <acronym>NFS</acronym> server will export. Each
|
||||
line in <filename>/etc/exports</filename> specifies a file
|
||||
system to be exported and which clients have access to that
|
||||
file system, as well as any access options. There are many
|
||||
such options that can be used in this file, but only a few
|
||||
will be mentioned here. See &man.exports.5; for the full list
|
||||
of options.</para>
|
||||
<para>The file systems which the <acronym>NFS</acronym> server will
|
||||
share are specified in <filename>/etc/exports</filename>. Each
|
||||
line in this file specifies a file
|
||||
system to be exported, which clients have access to that
|
||||
file system, and any access options. When adding entries to this file,
|
||||
each exported file system, its properties, and allowed
|
||||
hosts must occur on a single line. If no clients are listed in the entry,
|
||||
then any client on the network can mount that file
|
||||
system.</para>
|
||||
|
||||
<indexterm>
|
||||
<primary>NFS</primary>
|
||||
<secondary>export examples</secondary>
|
||||
</indexterm>
|
||||
|
||||
<para>These examples give an idea of how to export file systems.
|
||||
Minor modifications may be required for the examples to work
|
||||
on the reader's network.</para>
|
||||
<para>The following <filename>/etc/exports</filename> entries
|
||||
demonstrate how to export file systems.
|
||||
The examples can be modified to match the file systems
|
||||
and client names on the reader's network. There are many
|
||||
options that can be used in this file, but only a few
|
||||
will be mentioned here. See &man.exports.5; for the full list
|
||||
of options.</para>
|
||||
|
||||
<para>This example shows how to export the
|
||||
<filename>/cdrom</filename> directory to
|
||||
three clients called <replaceable>alpha</replaceable>,
|
||||
<para>This example shows how to export
|
||||
<filename>/cdrom</filename> to
|
||||
three hosts named <replaceable>alpha</replaceable>,
|
||||
<replaceable>bravo</replaceable>, and
|
||||
<replaceable>charlie</replaceable>:</para>
|
||||
|
||||
<programlisting>/cdrom -ro <replaceable>alpha</replaceable> <replaceable>bravo</replaceable> <replaceable>charlie</replaceable></programlisting>
|
||||
|
||||
<para>The <literal>-ro</literal> flag makes the file systems
|
||||
<para>The <literal>-ro</literal> flag makes the file system
|
||||
read-only, preventing clients from making any changes to
|
||||
those exported file systems.</para>
|
||||
the exported file system. This example assumes that the host
|
||||
names are either in <acronym>DNS</acronym> or in
|
||||
<filename>/etc/hosts</filename>. Refer to &man.hosts.5; if
|
||||
the network does not have a <acronym>DNS</acronym>
|
||||
server.</para>
|
||||
|
||||
<para>The next example exports <filename>/home</filename> to
|
||||
three clients by <acronym>IP</acronym> address. This can be
|
||||
useful for networks without <acronym>DNS</acronym>.
|
||||
Optionally, <filename>/etc/hosts</filename> could be
|
||||
configured for internal hostnames; please review &man.hosts.5;
|
||||
for more information. The <literal>-alldirs</literal> flag
|
||||
useful for networks without <acronym>DNS</acronym> or
|
||||
<filename>/etc/hosts</filename> entries.
|
||||
The <literal>-alldirs</literal> flag
|
||||
allows subdirectories to be mount points. In other words, it
|
||||
will not mount the subdirectories but permit the client to
|
||||
mount only the directories that are required or needed.</para>
|
||||
will not automaticaly mount the subdirectories, but will permit the client to
|
||||
mount the directories that are required as needed.</para>
|
||||
|
||||
<programlisting>/home -alldirs 10.0.0.2 10.0.0.3 10.0.0.4</programlisting>
|
||||
|
||||
<para>This next line exports <filename>/a</filename> so that two
|
||||
clients from different domains may access the file system.
|
||||
The <option>-maproot=root</option> flag allows the
|
||||
<systemitem class="username">root</systemitem> user on the
|
||||
<para>This next example exports <filename>/a</filename> so that two
|
||||
clients from different domains may access that file system.
|
||||
The <option>-maproot=root</option> allows
|
||||
<systemitem class="username">root</systemitem> on the
|
||||
remote system to write data on the exported file system as
|
||||
<systemitem class="username">root</systemitem>. If the
|
||||
<literal>-maproot=root</literal> flag is not specified, the
|
||||
<systemitem class="username">root</systemitem>. If
|
||||
<literal>-maproot=root</literal> is not specified, the
|
||||
client's <systemitem class="username">root</systemitem> user
|
||||
will be mapped to the server's <systemitem
|
||||
class="username">nobody</systemitem> account and will be
|
||||
subject to the access limitations defined for user,
|
||||
subject to the access limitations defined for
|
||||
<systemitem class="username">nobody</systemitem>.</para>
|
||||
|
||||
<programlisting>/a -maproot=root host.example.com box.example.org</programlisting>
|
||||
|
||||
<para>For a client to have access to an exported file system,
|
||||
the client must be listed in
|
||||
<filename>/etc/exports</filename>.</para>
|
||||
|
||||
<para>In <filename>/etc/exports</filename>, each line defines
|
||||
the export information for one file system to one or more
|
||||
clients. A remote host can only be specified once per file
|
||||
system. For example, assume that
|
||||
<filename>/usr</filename> is a single file system. This
|
||||
entry, in <filename>/etc/exports</filename>, would be
|
||||
invalid:</para>
|
||||
<para>A client can only be specified once per file
|
||||
system. For example, if
|
||||
<filename>/usr</filename> is a single file system, these
|
||||
entries would be
|
||||
invalid as both entries
|
||||
specify the same host:</para>
|
||||
|
||||
<programlisting># Invalid when /usr is one file system
|
||||
/usr/src client
|
||||
/usr/ports client</programlisting>
|
||||
|
||||
<para>The <filename>/usr</filename> file system has two lines
|
||||
specifying exports to the same host,
|
||||
<systemitem>client</systemitem>. The correct format for this
|
||||
situation is:</para>
|
||||
<para>The correct format for this
|
||||
situation is to use one entry:</para>
|
||||
|
||||
<programlisting>/usr/src /usr/ports client</programlisting>
|
||||
|
||||
<para>The exported file system, its properties, and allowed
|
||||
hosts must occur on a single line. If no clients are listed,
|
||||
then any client on the network may mount the exported file
|
||||
system.</para>
|
||||
|
||||
<para>The following is an example of a valid export list, where
|
||||
<filename>/usr</filename> and <filename>/exports</filename>
|
||||
are local file systems:</para>
|
||||
|
|
@ -719,35 +712,50 @@ mountd_flags="-r"</programlisting>
|
|||
/exports -alldirs -maproot=root client01 client02
|
||||
/exports/obj -ro</programlisting>
|
||||
|
||||
<para>The <application>mountd</application> daemon reads
|
||||
<filename>/etc/exports</filename> when started. To make
|
||||
<acronym>NFS</acronym> server changes take effect immediately,
|
||||
force <application>mountd</application> to reread
|
||||
<filename>/etc/exports</filename>:</para>
|
||||
<para>To enable the processes required by the <acronym>NFS</acronym> server
|
||||
at boot time, add
|
||||
these options to
|
||||
<filename>/etc/rc.conf</filename>:</para>
|
||||
|
||||
<screen>&prompt.root; <userinput>service mountd reload</userinput></screen>
|
||||
<programlisting>rpcbind_enable="YES"
|
||||
nfs_server_enable="YES"
|
||||
mountd_flags="-r"</programlisting>
|
||||
|
||||
<para>Please refer to <xref linkend="configtuning-rcd"/> for
|
||||
more information about using rc scripts.</para>
|
||||
|
||||
<para>On a new server being configured with
|
||||
<acronym>NFS</acronym> services, the server can be started by
|
||||
running this command as <systemitem
|
||||
class="username">root</systemitem>:</para>
|
||||
<para>The server can be started now by
|
||||
running this command:</para>
|
||||
|
||||
<screen>&prompt.root; <userinput>service nfsd start</userinput></screen>
|
||||
|
||||
<para>On the <acronym>NFS</acronym> client:</para>
|
||||
<para>Whenever the <acronym>NFS</acronym> server is started,
|
||||
<application>mountd</application> also starts automatically.
|
||||
However, <application>mountd</application> only reads
|
||||
<filename>/etc/exports</filename> when it is started. To make subsequent
|
||||
<filename>/etc/exports</filename> edits take effect immediately,
|
||||
force <application>mountd</application> to reread it:</para>
|
||||
|
||||
<screen>&prompt.root; <userinput>service nfsclient restart</userinput></screen>
|
||||
<screen>&prompt.root; <userinput>service mountd reload</userinput></screen>
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>Configuring the Client</title>
|
||||
|
||||
<para>To enable <acronym>NFS</acronym> clients, set this option in each client's
|
||||
<filename>/etc/rc.conf</filename>:</para>
|
||||
|
||||
<programlisting>nfs_client_enable="YES"</programlisting>
|
||||
|
||||
<para>Then, run this command on each <acronym>NFS</acronym>
|
||||
client:</para>
|
||||
|
||||
<screen>&prompt.root; <userinput>service nfsclient start</userinput></screen>
|
||||
|
||||
<para>The client now has everything it needs to mount a remote
|
||||
file system. In these examples, the server's name is
|
||||
<systemitem>server</systemitem> and the client's name is
|
||||
<systemitem>client</systemitem>. For testing or to
|
||||
temporarily mount a remote file system, execute
|
||||
<application>mount</application> as <systemitem
|
||||
class="username">root</systemitem> on
|
||||
<systemitem>client</systemitem>. To
|
||||
mount the <filename>/home</filename> file system on
|
||||
<systemitem>server</systemitem> to the
|
||||
<filename>/mnt</filename> mount point on
|
||||
<systemitem>client</systemitem>:</para>
|
||||
|
||||
<indexterm>
|
||||
|
|
@ -756,12 +764,9 @@ mountd_flags="-r"</programlisting>
|
|||
</indexterm>
|
||||
<screen>&prompt.root; <userinput>mount server:/home /mnt</userinput></screen>
|
||||
|
||||
<para>This mounts the <systemitem>server</systemitem>:
|
||||
<filename>/home</filename> file system to the
|
||||
<systemitem>client</systemitem>:
|
||||
<filename>/mnt</filename> mount point. The files and
|
||||
directories in the <systemitem>server</systemitem>
|
||||
<filename>/home</filename> file system will now be available
|
||||
<para>The files and
|
||||
directories in
|
||||
<filename>/home</filename> will now be available
|
||||
on <systemitem>client</systemitem>, in the
|
||||
<filename>/mnt</filename> directory.</para>
|
||||
|
||||
|
|
@ -777,117 +782,75 @@ mountd_flags="-r"</programlisting>
|
|||
<sect2>
|
||||
<title>Locking</title>
|
||||
|
||||
<para>Some applications (e.g., <application>mutt</application>)
|
||||
require file locking to operate correctly. In the case of
|
||||
<acronym>NFS</acronym>, <application>rpc.lockd</application>
|
||||
can be used for file locking. To enable it, add this line to
|
||||
<filename>/etc/rc.conf</filename> on both client and
|
||||
<para>Some applications
|
||||
require file locking to operate correctly. To enable locking, add these lines to
|
||||
<filename>/etc/rc.conf</filename> on both the client and
|
||||
server:</para>
|
||||
|
||||
<programlisting>rpc_lockd_enable="YES"
|
||||
rpc_statd_enable="YES"</programlisting>
|
||||
|
||||
<para>Please note that this assumes that both
|
||||
<acronym>NFS</acronym> client and server are already
|
||||
configured.</para>
|
||||
|
||||
<para>Start the application, as <systemitem
|
||||
class="username">root</systemitem>, with:</para>
|
||||
<para>Then start the applications:</para>
|
||||
|
||||
<screen>&prompt.root; <userinput>service lockd start</userinput>
|
||||
&prompt.root; <userinput>service statd start</userinput></screen>
|
||||
|
||||
<para>If locking is not required on the server, the
|
||||
<acronym>NFS</acronym> client can be configured to lock
|
||||
locally by passing <option>-L</option> to &man.mount.nfs.8;.
|
||||
locally by including <option>-L</option> when running <application>mount</application>.
|
||||
Refer to &man.mount.nfs.8; for further details.</para>
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>Practical Uses</title>
|
||||
|
||||
<para><acronym>NFS</acronym> has many practical uses. Some of
|
||||
the more common uses:</para>
|
||||
|
||||
<indexterm>
|
||||
<primary>NFS</primary>
|
||||
<secondary>uses</secondary>
|
||||
</indexterm>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>Share a <acronym>CD-ROM</acronym> or other media with
|
||||
any number of clients. It is often more convenient to
|
||||
install software on multiple machines from a single
|
||||
location.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>On large networks, it is often more convenient to
|
||||
configure a central <acronym>NFS</acronym> server on which
|
||||
all user home directories are stored. Users can log into
|
||||
a client anywhere on the network and have access to their
|
||||
home directories.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Several clients may need access to the
|
||||
<filename>/usr/ports/distfiles</filename> directory.
|
||||
Sharing that directory allows for quick access to the
|
||||
source files without having to download them to each
|
||||
client.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</sect2>
|
||||
|
||||
<sect2 xml:id="network-amd">
|
||||
<!--
|
||||
<sect2info>
|
||||
<info>
|
||||
<title>Automating Mounts</title>
|
||||
|
||||
<authorgroup>
|
||||
<author>
|
||||
<personname>
|
||||
<firstname>Wylie</firstname>
|
||||
<surname>Stilwell</surname>
|
||||
</personname>
|
||||
<contrib>Contributed by </contrib>
|
||||
</author>
|
||||
</authorgroup>
|
||||
<authorgroup>
|
||||
<author>
|
||||
<personname>
|
||||
<firstname>Chern</firstname>
|
||||
<surname>Lee</surname>
|
||||
</personname>
|
||||
<contrib>Rewritten by </contrib>
|
||||
</author>
|
||||
</authorgroup>
|
||||
</sect2info>
|
||||
-->
|
||||
<title>Automatic Mounts with
|
||||
<application>amd</application></title>
|
||||
</info>
|
||||
|
||||
<indexterm><primary>amd</primary></indexterm>
|
||||
<indexterm>
|
||||
<primary>automatic mounter daemon</primary>
|
||||
</indexterm>
|
||||
|
||||
<para>&man.amd.8; (the automatic mounter daemon) automatically
|
||||
<para>The automatic mounter daemon,
|
||||
<application>amd</application>, automatically
|
||||
mounts a remote file system whenever a file or directory
|
||||
within that file system is accessed. Filesystems that are
|
||||
inactive for a period of time will also be automatically
|
||||
unmounted by <application>amd</application>.
|
||||
<application>amd</application> provides an alternative to
|
||||
modifying <filename>/etc/fstab</filename> to list every
|
||||
client.</para>
|
||||
within that file system is accessed. File systems that are
|
||||
inactive for a period of time will be automatically
|
||||
unmounted by <application>amd</application>.</para>
|
||||
|
||||
|
||||
<para><application>amd</application> operates by attaching
|
||||
itself as an NFS server to the
|
||||
<para>This daemon provides an alternative to
|
||||
modifying <filename>/etc/fstab</filename> to list every
|
||||
client. It operates by attaching
|
||||
itself as an <acronym>NFS</acronym> server to the
|
||||
<filename>/host</filename> and
|
||||
<filename>/net</filename> directories. When
|
||||
a file is accessed within one of these directories,
|
||||
<application>amd</application> looks up the corresponding
|
||||
remote mount and automatically mounts it.
|
||||
<filename>/net</filename> is used to mount an exported file
|
||||
system from an <acronym>IP</acronym> address, while
|
||||
system from an <acronym>IP</acronym> address while
|
||||
<filename>/host</filename> is used to mount an export from a
|
||||
remote hostname.</para>
|
||||
|
||||
<para>For instance, an attempt to access a file within
|
||||
remote hostname. For instance, an attempt to access a file within
|
||||
<filename>/host/foobar/usr</filename> would tell
|
||||
<application>amd</application> to mount the
|
||||
<filename>/usr</filename> export on the host
|
||||
|
|
@ -897,7 +860,7 @@ rpc_statd_enable="YES"</programlisting>
|
|||
<title>Mounting an Export with
|
||||
<application>amd</application></title>
|
||||
|
||||
<para><command>showmount -e</command> shows the exported file
|
||||
<para>In this example, <command>showmount -e</command> shows the exported file
|
||||
systems that can be mounted from the <acronym>NFS</acronym>
|
||||
server, <systemitem>foobar</systemitem>:</para>
|
||||
|
||||
|
|
@ -917,14 +880,15 @@ Exports list on foobar:
|
|||
<application>amd</application> automatically mounts the
|
||||
desired export.</para>
|
||||
|
||||
<para><application>amd</application> is enabled by placing
|
||||
this line in <filename>/etc/rc.conf</filename>:</para>
|
||||
<para>To enable <application>amd</application> at boot time, add
|
||||
this line to <filename>/etc/rc.conf</filename>:</para>
|
||||
|
||||
<programlisting>amd_enable="YES"</programlisting>
|
||||
|
||||
<para>It can then be started using the &os; &man.rc.8; scripts
|
||||
or by using the &man.service.8; command.</para>
|
||||
<para>To start <application>amd</application> now:</para>
|
||||
|
||||
<screen>&prompt.root; <userinput>service amd start</userinput></screen>
|
||||
|
||||
<para>Custom flags can be passed to
|
||||
<application>amd</application> from the
|
||||
<varname>amd_flags</varname> environment variable. By
|
||||
|
|
@ -932,10 +896,11 @@ Exports list on foobar:
|
|||
|
||||
<programlisting>amd_flags="-a /.amd_mnt -l syslog /host /etc/amd.map /net /etc/amd.map"</programlisting>
|
||||
|
||||
<para><filename>/etc/amd.map</filename> defines the default
|
||||
options with which exports are mounted.
|
||||
<filename>/etc/amd.conf</filename> defines some of the more
|
||||
advanced features of <application>amd</application>.</para>
|
||||
<para>The default options with which exports are mounted are
|
||||
defined in <filename>/etc/amd.map</filename>.
|
||||
Some of the more
|
||||
advanced features of <application>amd</application> are
|
||||
defined in <filename>/etc/amd.conf</filename>.</para>
|
||||
|
||||
<para>Consult &man.amd.8; and &man.amd.conf.5; for more
|
||||
information.</para>
|
||||
|
|
|
|||
Loading…
Reference in a new issue