使用 NFSNFS 的设置与 Samba 非常类似。在服务器端，定义了要导出（或共享）的文件系统或目录；客户机端要将这些共享的目录挂载到本地系统上。当远程客户机挂载一个使用 NFS 共享的目录时，这个目录的访问方式与其他本地文件系统是完全相同的。在服务器端设置 NFS 是一个相当简单的过程。只需要创建或编辑 /etc/exports 文件，并启动 NFS 守护进程。要设置一个更加安全的 NFS 服务，还需要编辑 /etc/hosts.allow 和 /etc/hosts.deny 。NFS 的客户机端只需要运行 mount 命令。更多信息和选项，请查看 Linux® 手册页。
NFS 服务器/etc/exports 文件中的项的格式相当简单。要共享一个文件系统，只需要编辑 /etc/exports 并使用下面的格式给出这个文件系统（和选项）即可：
1
| directory (or file system) client1 (option1, option2) client2 (option1, option2)
|
常用选项有几个常用的选项可以对 NFS 实现进行定制。这些选项包括：
- secure： 这个选项是缺省选项，它使用了 1024 以下的 TCP/IP 端口实现 NFS 的连接。指定 insecure 可以禁用这个选项。
- rw： 这个选项允许 NFS 客户机进行读/写访问。缺省选项是只读的。
- async： 这个选项可以改进性能，但是如果没有完全关闭 NFS 守护进程就重新启动了 NFS 服务器，这也可能会造成数据丢失。缺省设置为 sync。
- no_wdelay： 这个选项关闭写延时。如果设置了 async，那么 NFS 就会忽略这个选项。
- nohide： 如果将一个目录挂载到另外一个目录之上，那么原来的目录通常就被隐藏起来或看起来像空的一样。要禁用这种行为，需启用 hide 选项。
- no_subtree_check： 这个选项关闭子树检查，子树检查会执行一些不想忽略的安全性检查。缺省选项是启用子树检查。
- no_auth_nlm： 这个选项也可以作为 insecure_locks 指定，它告诉 NFS 守护进程不要对加锁请求进行认证。如果关心安全性问题，就要避免使用这个选项。缺省选项是 auth_nlm 或 secure_locks。
- mp (mountpoint=path)： 通过显式地声明这个选项，NFS 要求挂载所导出的目录。
- fsid=num： 这个选项通常都在 NFS 故障恢复的情况中使用。如果希望实现 NFS 的故障恢复，请参考 NFS 文档。
用户映射通过 NFS 中的用户映射，可以将伪或实际用户和组的标识赋给一个正在对 NFS 卷进行操作的用户。这个 NFS 用户具有映射所允许的用户和组的许可权限。对 NFS 卷使用一个通用的用户/组可以提供一定的安全性和灵活性，而不会带来很多管理负荷。
在使用 NFS 挂载的文件系统上的文件时，用户的访问通常都会受到限制，这就是说用户都是以匿名用户的身份来对文件进行访问的，这些用户缺省情况下对这些文件只有只读权限。这种行为对于 root 用户来说尤其重要。然而，实际上的确存在这种情况：希望用户以 root 用户或所定义的其他用户的身份访问远程文件系统上的文件。NFS 允许指定访问远程文件的用户——通过用户标识号（UID）和组标识号（GID），可以禁用正常的 squash 行为。
用户映射的选项包括：
- root_squash： 这个选项不允许 root 用户访问挂载上来的 NFS 卷。
- no_root_squash： 这个选项允许 root 用户访问挂载上来的 NFS 卷。
- all_squash： 这个选项对于公共访问的 NFS 卷来说非常有用，它会限制所有的 UID 和 GID，只使用匿名用户。缺省设置是 no_all_squash。
- anonuid 和 anongid： 这两个选项将匿名 UID 和 GID 修改成特定用户和组帐号。
清单 1 给出了 /etc/exports 的例子。
清单 1. /etc/exports 的例子1
2
3
4
| /opt/files 192.168.0.*
/opt/files 192.168.0.120
/opt/files 192.168.0.125(rw, all_squash, anonuid=210, anongid=100)
/opt/files *(ro, insecure, all_squash)
|
第一项将 /opt/files 目录导出给 192.168.0 网络中的所有主机。下一项将 /opt/files 导出给一台主机：192.168.0.120。第三项指定了主机 192.168.0.125，并将对文件的读写权限授权给 user id=210 且 group id=100 的用户。最后一项针对一个公共目录，它只有只读权限并只能允许以匿名帐号的身份访问。
NFS 客户机需要注意的问题在使用 NFS 挂载一个远程文件系统之后，这个远程系统就成为了在客户机系统上执行的整体系统备份的一部分。如果没有从备份中排除新挂载上来的目录，那么这种行为可能会造成严重的后果。
要使用 NFS 作为客户机，客户机机器必须要运行 rpc.statd 和 portmap 进程。可以执行一个简单的 ps -ef 命令来检查系统是否运行了这两个守护进程。如果它们正在运行（应该如此），那么就可以使用下面的通用命令来挂载服务器上导出的目录：
1
| mount server:directory local mount point
|
通常来说，必须以 root 用户的身份来挂载文件系统。在远程计算机上，可以使用下面的命令（假设 NFS 服务器的 IP 地址是 192.168.0.100）：
1
| mount 192.168.0.100:/opt/files /mnt
|
您所使用的发行版可能会要求在挂载文件系统时指定文件系统的类型。如果出现这种情况，请执行下面的命令：
1
| mount -t nfs 192.168.0.100:/opt/files /mnt
|
如果服务器端已经正确设置好了，那么远程文件系统应该可以毫无问题地加载。现在，执行 cd 命令切换到 /mnt 目录中，然后执行 ls 命令来查看文件。要永久挂载，必须编辑 /etc/fstab 文件，并创建一个类似于下面的项：
1
| 192.168.0.100:/opt/files /mnt nfs rw 0 0
|
注意： 有关 /etc/fstab 的更多信息，请参考 fstab 的手册页。
对 NFS 的批评批评促使进步对于 NFS 安全性的批评是 NFSv4 很多改进的根源。新版本的设计者采用了一些实际的测试机制来巩固 NFS 客户机-服务器交互之间的安全性。实际上，设计者们决定要设计一个全新的安全模型。
要理解这个安全模型，您应该熟悉所谓的 通用安全服务应用程序编程接口（Generic Security Services application programming interface，GSS-API）版本 2 的更新 1。GSS-API 在 RFC 2743 中进行了完整的描述，不幸的是，它是最难理解的 RFC 之一。
从 NFSv4 的使用经验中我们知道，让网络文件系统与操作系统独立开来是非常困难的。不过要让操作系统的安全性和网络协议完全独立开来却更加困难。我们必须两者都要，因为 NFS 必须要能够处理大量的用户操作，但还不能太多地引入网络协议交互的特有内容。
NFS 客户机和服务器之间的连接通过所谓的“健壮” RPC 安全性进行了增强。NFSv4 使用了在 RFC 1831 中定义的开放网络计算远程过程调用（Open Network Computing Remote Procedure Call，ONCRPC）标准。这个安全模型必须进行增强，而不是依赖于一个简单的认证（称为 AUTH_SYS），有一个称为 RPCSEC_GSS 的基于 GSS-API 的安全模型已经被定义并作为 NFSv4 的一个强制部分实现了。NFSv4 中提供的最重要的安全机制包括 Kerberos 版本 5 和 LIPKEY。
尽管 Kerberos 在 Internet 上使用时有诸多限制，但是 LIPKEY 却有一个令人满意的优点——可以像 Secure Socket Layer（SSL）一样工作，提示用户输入自己的用户名和密码，同时还可以避免 SSL 对 TCP 的依赖性 —— 这是 NFSv4 没有的一种依赖性。如果不要求 RPCSEC_GSS，可以设置 NFS 来对安全性问题进行协商。以前的 NFS 版本都没有这种能力，因此不能对保护的质量、数据的完整性、认证的要求或加密类型进行协商。 |
