NFS 服务如何工作 - 系统管理指南：网络服务

link管理

链接快照平台

输入网页链接，自动生成快照
标签化管理网页链接

NFS 版本 4 的功能

在版本 4 中对 NFS 进行了许多更改。本节介绍这些新功能。

在 NFS 版本 4 中取消共享和重新共享文件系统

NFS 版本 4 中的文件系统名称空间

NFS 版本 4 中的可变文件句柄

NFS 版本 4 中的客户机恢复

NFS 版本 4 中的 OPEN 共享支持

NFS 版本 4 中的委托

NFS 版本 4 中的 ACL 和 nfsmapid

NFS 版本 4 中的客户端故障转移

注 - 从 Solaris 10 发行版开始，NFS 版本 4 不支持 LIPKEY/SPKM 安全风格。另外，NFS 版本 4 也不会使用 mountd 、 nfslogd 和 statd 守护进程。

有关与使用 NFS 版本 4 相关的过程信息，请参阅设置 NFS 服务。

在 NFS 版本 4 中取消共享和重新共享文件系统

如果同时使用 NFS 版本 3 和版本 4，则客户机尝试访问一个已经取消共享的文件系统时，服务器会以错误代码响应。但是，如果使用 NFS 版本 3，则服务器会保留客户机在取消共享文件系统之前所获取的所有锁定。这样，重新共享文件系统时，NFS 版本 3 客户机即可访问此文件系统，就好像从未取消共享此文件系统一样。

如果使用 NFS 版本 4，则取消共享文件系统时，将破坏此文件系统中任何已打开文件或文件锁定的所有状态。如果客户机尝试访问这些文件或锁定，则会收到一条错误消息。通常会将此错误消息作为 I/O 错误报告给应用程序。但是请注意，通过重新共享当前共享的文件系统来更改选项不会破坏服务器上的任何状态。

有关信息，请参阅 NFS 版本 4 中的客户机恢复或参见 unshare_nfs (1M) 手册页。

NFS 版本 4 中的文件系统名称空间

NFS 版本 4 服务器可创建并维护一个伪文件系统，此系统使客户机能够对服务器上所有导出的对象进行无缝访问。在 NFS 版本 4 之前，不存在伪文件系统。客户机会强制挂载每个共享服务器文件系统来进行访问。请参考以下示例。

图 6-2 服务器文件系统和客户机文件系统的视图

请注意，客户机无法看到 payroll 目录和 nfs4x 目录，因为这些目录未被导出，也没有通向导出目录。但是，客户机可以看到 local 目录，因为 local 是一个导出的目录。客户机还可看到 projects 目录，因为 projects 通向导出目录 nfs4 。因此，未显式导出的服务器名称空间的部分内容会与伪文件系统桥接，该文件系统仅显示导出目录和那些通向服务器导出目录的目录。

伪文件系统是服务器创建的仅包含目录的结构。伪文件系统允许客户机浏览已导出文件系统的分层结构。因此，客户机的伪文件系统视图限制为仅显示通向已导出文件系统的路径。

以前的 NFS 版本不允许客户机在未挂载每个文件系统的情况下遍历服务器文件系统。但是，在 NFS 版本 4 中，服务器名称空间可进行以下操作：

将客户机的文件系统视图限制为仅显示通向服务器导出的目录。

使客户机能够对服务器导出目录进行无缝访问，而不要求客户机挂载每个底层文件系统。请参见前面的示例。但是请注意，某些操作系统可能会要求客户机挂载每个服务器文件系统。

由于与 POSIX 相关的原因，Solaris NFS 版本 4 客户机不会跨越服务器的文件系统边界。如果尝试进行这类操作，则客户机会使目录显示为空。要修正这种情况，必须针对服务器的每个文件系统执行挂载。

NFS 版本 4 中的可变文件句柄

文件句柄是在服务器上创建的，其中包含唯一标识文件和目录的信息。在 NFS 版本 2 和 3 中，服务器会返回持久性文件句柄。这样，客户机即可确保服务器会生成始终引用同一文件的文件句柄。例如：

如果删除某个文件并将其替换为同名文件，则服务器会为新文件生成新的文件句柄。如果客户机使用旧的文件句柄，则服务器会返回一条错误消息，说明此文件句柄已过时。

如果重命名文件，则文件句柄将保持不变。

如果必须重新引导服务器，则文件句柄将保持不变。

因此，当服务器从客户机收到包括文件句柄的请求时，解决方案会非常简单，并且文件句柄会始终引用正确的文件。

这种为 NFS 操作标识文件和目录的方法对大多数基于 UNIX 的服务器都很有效。但是，此方法不能在依赖其他标识方法（如文件的路径名）的服务器上实施。为了解决此问题，NFS 版本 4 协议允许服务器声明其文件句柄为可变句柄。这样，即可更改文件句柄。如果文件句柄确实已更改，则客户机必须找到新的文件句柄。

与 NFS 版本 2 和 3 一样，Solaris NFS 版本 4 服务器始终提供持久性文件句柄。但是，访问非 Solaris NFS 版本 4 服务器的 Solaris NFS 版本 4 客户机必须在服务器使用可变文件句柄时支持这些句柄。具体来说，当服务器通知客户机文件句柄可变时，客户机必须高速缓存路径名和文件句柄之间的映射。客户机会一直使用可变文件句柄，直到句柄过期为止。文件句柄过期后，客户机会执行以下操作：

刷新引用此文件句柄的高速缓存信息

搜索此文件的新文件句柄

重试此操作

注 - 服务器会始终通知客户机哪些文件句柄为持久性句柄，哪些文件句柄为可变句柄。

可变文件句柄可能会由于以下任一原因过期：

迁移文件句柄的文件系统

客户机重命名文件

服务器重新引导

请注意，如果客户机无法找到新的文件句柄，则会在 syslog 文件中放入一条错误消息。进一步尝试访问此文件会失败，并显示 I/O 错误。

NFS 版本 4 中的客户机恢复

NFS 版本 4 协议为有状态协议。如果客户机和服务器都保留有关以下内容的当前信息，协议即为有状态协议。

打开的文件

出现故障（如服务器崩溃）时，客户机和服务器会协同工作，重新建立故障前已存在的打开状态和锁定状态。

服务器崩溃并重新引导时，会丢失其状态。客户机检测到服务器已经重新引导后，将启动帮助服务器重建其状态的进程。此进程称为客户机恢复，因为由客户机引导此进程。

客户机发现服务器已经重新引导后，便会立即暂停其当前活动并启动客户机恢复进程。启动恢复进程时，系统错误日志 /var/adm/messages 中会显示如下消息。

NOTICE: Starting recovery server basil.example.company.com

在恢复进程中，客户机会向服务器发送有关客户机以前状态的信息。但是请注意，在此期间，客户机不会向服务器发送任何新请求。任何打开文件或设置文件锁定的新请求都必须等到服务器完成其恢复期之后才能继续进行。

客户机恢复进程完成时，系统错误日志 /var/adm/messages 中会显示以下消息。

NOTICE: Recovery done for server basil.example.company.com

现在，客户机已经成功地将其状态信息发送给服务器。不过，尽管此客户机已经完成了此进程，但是其他客户机可能尚未完成将其状态信息发送给服务器这一进程。因此，在一段时间内，服务器不会接受任何打开或锁定请求。指定这段时间（称为宽延期）旨在允许所有客户机完成其恢复。

在宽延期内，如果客户机尝试打开任何新文件或建立任何新锁定，服务器都会拒绝请求并显示 GRACE 错误代码。收到此错误后，客户机必须等到宽延期结束，然后才能向服务器重新发送请求。在宽延期内，会显示以下消息。

NFS server recovering

请注意，在宽延期内，可以继续执行不打开文件或不设置文件锁定的命令。例如， ls 和 cd 命令不会打开文件或设置文件锁定。因此，不会暂停执行这些命令。但是， cat 之类可打开文件的命令会暂停执行，直到宽延期结束为止。

宽延期结束后，会显示以下消息。

NFS server recovery ok.

现在，客户机即可向服务器发送新的打开和锁定请求。

客户机恢复会因为各种原因而失败。例如，如果服务器重新引导后存在网络分区，则客户机可能无法在宽延期结束之前与服务器重新建立其状态。宽延期结束后，服务器不允许客户机重新建立其状态，因为新的状态操作可能会产生冲突。例如，新的文件锁定可能会与客户机尝试恢复的旧的文件锁定发生冲突。发生这种情况时，服务器会将 NO_GRACE 错误代码返回到客户机。

如果恢复某个特定文件的打开操作失败，客户机会将此文件标记为不可用，并显示以下消息。

WARNING: The following NFS file could not be recovered and was marked dead 
(can't reopen:  NFS status 70):  file :  filename

请注意，数字 70 仅是一个示例。

如果在恢复过程中重新建立文件锁定失败，则会显示以下错误消息。

NOTICE: nfs4_send_siglost:  pid PROCESS-ID lost
lock on server SERVER-NAME

在这种情况下，会向进程发送 SIGLOST 信号。 SIGLOST 信号的缺省操作是终止此进程。

要从此状态恢复，必须重新启动所有在失败时打开文件的应用程序。请注意，可能会出现以下情况。

一些没有重新打开文件的进程可能会收到 I/O 错误消息。

在恢复失败之后已重新打开文件或执行打开操作的其他进程可顺利访问文件。

因此，一些进程可以访问其他进程无法访问的特定文件。

NFS 版本 4 中的 `OPEN` 共享支持

NFS 版本 4 协议提供了几种文件共享模式，客户机可以使用这些模式控制其他客户机对文件的访问。客户机可以指定以下内容：

DENY_NONE 模式，用于允许其他客户机对文件进行读写访问。

DENY_READ 模式，用于拒绝其他客户机对文件进行读取访问。

DENY_WRITE 模式，用于拒绝其他客户机对文件进行写入访问。

DENY_BOTH 模式，用于拒绝其他客户机对文件进行读写访问。

Solaris NFS 版本 4 服务器完全实现了这些文件共享模式。因此，如果客户机尝试打开文件的方式与当前共享模式冲突，则服务器会通过使操作失败来拒绝此尝试。如果这类尝试在打开或创建操作开始时失败，则 NFS 版本 4 客户机会收到一条协议错误消息。此错误会映射为应用程序错误 EACCES 。

尽管此协议提供了几种共享模式，但目前 Solaris 中的打开操作不提供多种共享模式。打开文件时，Solaris NFS 版本 4 客户机只能使用 DENY_NONE 模式。

另外，尽管 fcntl 系统调用使用 F_SHARE 命令来控制文件共享，但是 fcntl 命令无法在 NFS 版本 4 中正常实现。如果在 NFS 版本 4 客户机上使用这些 fcntl 命令，则客户机会向应用程序返回一条 EAGAIN 错误消息。

NFS 版本 4 中的委托

NFS 版本 4 为委托同时提供客户机支持和服务器支持。委托是服务器用于将文件管理委托给客户机的一种技术。例如，服务器可以授予客户机读取委托或写入委托。读取委托可以同时授予多台客户机，因为这些读取委托不会彼此冲突。写入委托只能授予一台客户机，因为写入委托会与其他任何客户机进行的任何文件访问相冲突。虽然客户机拥有写入委托，但是它不会向服务器发送各种操作，因为客户机保证具有对文件的独占访问权限。同样，客户机在拥有读取委托时也不会向服务器发送各种操作。这是因为服务器保证任何客户机都不能以写入模式打开文件。通过委托，可显著减少服务器和客户机之间针对被委托文件的交互。因此，可降低网络通信流量，并且提高客户机和服务器的性能。但是请注意，性能提高的程度取决于应用程序使用的文件交互的类型以及网络和服务器的拥塞量。

是否授予委托完全由服务器决定。客户机不会请求委托。服务器可根据文件的访问模式来决定是否授予委托。如果几台不同的客户机最近以写入模式访问了文件，则服务器可能不会授予委托。原因是此访问模式表明将来可能会发生冲突。

当客户机访问文件的方式与当前授予此文件的委托不一致时，便会发生冲突。例如，如果一台客户机拥有对文件的写入委托，同时另一台客户机打开此文件来进行读取或写入访问，则服务器会撤销第一台客户机的写入委托。同样，如果一台客户机拥有读取委托，同时另一台客户机打开同一个文件进行写入，则服务器会撤销读取委托。请注意，在这两种情况下都不会将委托授予第二台客户机，因为此时存在冲突。发生冲突时，服务器会使用回调机制来联系当前拥有委托的客户机。收到此回调后，客户机会向服务器发送文件的更新状态并返回委托。如果客户机无法对重新调用做出响应，则服务器会撤销委托。在此类情况下，服务器会拒绝客户机对此文件进行的所有操作，客户机将已请求的操作报告为失败。通常，这些失败会作为 I/O 错误报告给应用程序。要从这些错误中恢复，必须关闭文件，然后再重新打开。当客户机和服务器之间存在网络分区并且客户机拥有委托时，撤销委托会失败。

请注意，一台服务器不能解决对其他服务器上存储的文件的访问冲突。因此，NFS 服务器仅解决它自己存储的文件的冲突。此外，要响应由运行各种 NFS 版本的客户机导致的冲突，NFS 服务器只能对运行 NFS 版本 4 的客户机启动重新调用。NFS 服务器不能对运行早期 NFS 版本的客户机启动重新调用。

检测冲突的进程会有所变化。例如，与 NFS 版本 4 不同，因为版本 2 和版本 3 不包括打开过程，所以仅会在客户机尝试读取、写入或锁定文件之后检测冲突。服务器对这些冲突的响应也会有所不同。例如：

对于 NFS 版本 3，服务器会返回 JUKEBOX 错误消息，这会导致客户机停止访问请求并稍后重试。客户机会输出消息 File unavailable 。

对于 NFS 版本 2，因为不存在与 JUKEBOX 错误消息等效的消息，所以服务器不做任何响应，这会导致客户机等待然后再重试。客户机会输出消息 NFS server not responding 。

解决了委托冲突之后，便不会存在这些情况。

缺省情况下，会启用服务器委托。可以通过修改 /etc/default/nfs 文件来禁用委托。有关过程信息，请参阅如何在服务器上选择不同版本的 NFS 。

客户机委托不需要任何关键字。NFS 版本 4 回调守护进程 nfs4cbd 在客户机上提供回调服务。只要启用对 NFS 版本 4 的挂载，此守护进程就会自动启动。缺省情况下，客户机会针对 /etc/netconfig 系统文件中列出的所有 Internet 传输向服务器提供必需的回调信息。请注意，如果在客户机上启用了 IPv6 并且可以确定客户机名称的 IPv6 地址，则回调守护进程可接受 IPv6 连接。

回调守护进程使用临时的程序编号以及动态指定的端口号。此信息提供给服务器，服务器会在授予任何委托之前测试回调路径。如果回调路径测试不成功，则服务器不会授予委托，这是唯一可从外部看到的行为。

请注意，因为回调信息嵌在 NFS 版本 4 请求中，所以服务器不能通过使用网络地址转换 (Network Address Translation, NAT) 的设备来联系客户机。另外，回调守护进程还会使用动态端口号。因此，即使防火墙在端口 2049 上启用了正常的 NFS 流量，服务器可能仍然无法遍历防火墙。在此类情况下，服务器不会授予委托。

NFS 版本 4 中的 ACL 和 `nfsmapid`

访问控制列表 (access control list, ACL) 通过使文件的所有者可以为文件所有者、组以及其他特定用户和组定义文件权限来提供更好的文件安全性。ACL 是使用 setfacl 命令在服务器和客户机上设置的。有关更多信息，请参见 setfacl (1) 手册页。在 NFS 版本 4 中，ID 映射器 nfsmapid 用于将服务器上的 ACL 项中的用户 ID 或组 ID 映射为客户机上的 ACL 项中的用户 ID 或组 ID。相反的映射也能实现。ACL 项中的用户 ID 和组 ID 必须同时存在于客户机和服务器上。

ID 映射失败的原因

以下情况可能导致 ID 映射失败：

如果存在于服务器上 ACL 项中的用户或组不能映射为客户机上的有效用户或组，则不允许该用户读取客户机上的 ACL。

例如，对于服务器上其用户 ID 或组 ID ACL 项不能映射为客户机上的用户 ID 或组 ID 的文件，在发出 ls -lv 或 ls -lV 命令时，会收到 Permission denied 错误消息。ID 映射器无法映射 ACL 中的用户或组。如果 ID 映射器能够映射该用户或组，则在通过 ls -l 生成的文件列表中，权限后面会显示一个加号 (+)。例如：

% ls -l
-rw-r--rw-+   1 luis    staff      11968 Aug 12  2005 foobar

同样， getfacl 命令也会因为同样的原因返回 Permission denied 错误消息。有关此命令的更多信息，请参见 getfacl (1) 手册页。

如果不能将客户机上设置的任何 ACL 项中的用户 ID 或组 ID 映射为服务器上的有效用户 ID 或组 ID，则 setfacl 或 chmod 命令可能会失败，并返回 Permission denied 错误消息。

如果客户机和服务机的 NFSMAPID_DOMAIN 值不匹配，则 ID 映射将失败。有关更多信息，请参见 /etc/default/nfs 文件的关键字。

启动过程中，还会协商传输协议。缺省情况下，将选择客户机和服务器同时支持的第一个面向连接的传输。如果此选择未成功，则使用第一个可用的无连接传输协议。 /etc/netconfig 中列出了系统支持的传输协议。TCP 是该发行版支持的面向连接的传输协议。UDP 是无连接传输协议。

如果 NFS 协议版本和传输协议都是通过协商确定的，则 NFS 协议版本优先于传输协议。使用 UDP 的 NFS 版本 3 协议比使用 TCP 的 NFS 版本 2 协议具有更高的优先级。可以使用 mount 命令手动选择 NFS 协议版本和传输协议。请参见 mount_nfs (1M) 手册页。在大多数情况下，允许协商选择最佳选项。

文件传输大小协商

文件传输大小确定在客户机与服务器之间传输数据时使用的缓冲区的大小。一般情况下，最好使用较大的传输大小。NFS 版本 3 协议的传输大小没有限制。但是，从 Solaris 2.6 发行版开始，软件规定缺省缓冲区大小为 32 KB。如果需要，客户机可以在挂载时规定较小的传输大小，但是在大多数情况下，此规定是没有必要的。

系统不会与使用 NFS 版本 2 协议的系统协商传输大小。在这种情况下，最大的传输大小将设置为 8 KB。

可以在 mount 命令中使用 -rsize 和 -wsize 选项来手动设置传输大小。对于某些 PC 客户机，可能需要减小传输大小。另外，如果将 NFS 服务器配置为使用较大的传输大小，则还可以增加传输大小。

注 - 从 Solaris 10 发行版开始，放宽了对线路传输大小的限制。传输大小取决于底层传输的能力。例如，对于 UDP，NFS 的传输限制仍然是 32 KB。但是，因为 TCP 是流协议，不受 UDP 的数据报限制，因此通过 TCP 的最大传输大小已经增加到 1 MB。

以下说明适用于 NFS 版本 3 挂载。NFS 版本 4 挂载过程既不包括端口映射服务，也不包括 MOUNT 协议。

客户机需要从服务器挂载文件系统时，客户机必须从服务器获取文件句柄。文件句柄必须与文件系统对应。此过程需要在客户机与服务器之间处理多项事务。在本示例中，客户机正在尝试从服务器挂载 /home/terry 。此事务的 snoop 跟踪如下。

client -> server PORTMAP C GETPORT prog=100005 (MOUNT) vers=3 proto=UDP
server -> client PORTMAP R GETPORT port=33492
client -> server MOUNT3 C Null
server -> client MOUNT3 R Null 
client -> server MOUNT3 C Mount /export/home9/terry
server -> client MOUNT3 R Mount OK FH=9000 Auth=unix
client -> server PORTMAP C GETPORT prog=100003 (NFS) vers=3 proto=TCP
server -> client PORTMAP R GETPORT port=2049
client -> server NFS C NULL3
server -> client NFS R NULL3 
client -> server NFS C FSINFO3 FH=9000
server -> client NFS R FSINFO3 OK
client -> server NFS C GETATTR3 FH=9000
server -> client NFS R GETATTR3 OK

在此跟踪中，客户机首先从 NFS 服务器上的端口映射服务请求挂载端口号。客户机收到挂载端口号 ( 33492 ) 后，会使用该端口号测试服务器上服务的可用性。客户机确定服务正在该端口号上运行后，便会请求挂载。服务器对此请求做出响应时，服务器中会包含正在挂载的文件系统 ( 9000 ) 的文件句柄。随后，客户机将针对 NFS 端口号发送请求。客户机收到来自服务器的端口号后，客户机便会测试 NFS 服务 ( nfsd ) 的可用性。此外，客户机还会请求有关使用该文件句柄的文件系统的 NFS 信息。

在以下跟踪中，客户机正在使用 public 选项挂载文件系统。

client -> server NFS C LOOKUP3 FH=0000 /export/home9/terry
server -> client NFS R LOOKUP3 OK FH=9000
client -> server NFS C FSINFO3 FH=9000
server -> client NFS R FSINFO3 OK
client -> server NFS C GETATTR3 FH=9000
server -> client NFS R GETATTR3 OK

通过使用缺省的公共文件句柄（即 0000 ），系统将跳过所有要从端口映射服务获取信息并要确定 NFS 端口号的事务。

注 - NFS 版本 4 提供对可变文件句柄的支持。有关更多信息，请参阅 NFS 版本 4 中的可变文件句柄。

在上述情况下执行的故障转移通常对用户是透明的。因此，故障转移可以随时进行，而不会中断客户机上正在运行的进程。

故障转移要求采用只读方式挂载文件系统。文件系统必须相同，故障转移才能成功进行。有关使文件系统相同的原因说明，请参见什么是复制的文件系统？。静态文件系统或不常更改的文件系统是故障转移的最佳候选系统。

您不能对同一 NFS 挂载同时使用 CacheFS 和客户端故障转移。系统针对每个 CacheFS 文件系统存储了额外信息。故障转移期间不能更新此信息，因此挂载文件系统时只能使用这两个功能之一。

需要为每个文件系统建立的副本数目取决于许多因素。理想的情况是，应该至少具有两台服务器。每台服务器都应该支持多个子网。此设置比每个子网中具有唯一一台服务器更好。该过程要求检查列出的每台服务器。因此，列出的服务器越多，每个挂载的速度就越慢。

故障转移术语

要完全领会该过程，需要了解两个术语。

故障转移 －从支持复制的文件系统的服务器列表中选择服务器的过程。通常，使用已排序列表中的下一台服务器，除非该服务器无法做出响应。

重映射 －使用新的服务器。在正常使用中，客户机在远程文件系统上存储每个活动文件的路径名。在重映射期间，系统将评估这些路径名以在新的服务器上找到这些文件。

为了实现故障转移，当其中每个文件大小都相同且文件大小或文件类型与原始文件系统相同时，可以将这样的文件系统称为副本。不考虑权限、创建日期和其他文件属性。如果文件大小或文件类型不同，则重映射将失败，且该过程将挂起，直到旧的服务器可用为止。在 NFS 版本 4 中，该行为是不同的。请参见 NFS 版本 4 中的客户端故障转移。

可以使用 rdist 、 cpio 或其他文件传输机制来维护复制的文件系统。由于更新复制的文件系统会导致不一致，因此为实现最佳效果，应考虑以下预防措施：

在安装新版本的文件之前，先重命名旧版本的文件

在夜间运行更新，此时客户机使用率较低

使更新始终很小

将副本数目降到最少

操作系统支持大于 2 GB 的文件。缺省情况下，UFS 文件系统是使用 -largefiles 选项挂载的，以便支持此新功能。如有需要，请参见如何在 NFS 服务器上禁用大文件以获取说明。

如果服务器的文件系统是使用 -largefiles 选项挂载的，则 Solaris 2.6 NFS 客户机可以访问大文件，而不需要进行更改。但是，并不是所有的 Solaris 2.6 命令都可以处理这些大文件。有关可处理大文件的命令的列表，请参见 largefile (5) 。不能支持具有大文件扩展的 NFS 版本 3 协议的客户机不能访问任何大文件。尽管运行 Solaris 2.5 发行版的客户机可以使用 NFS 版本 3 协议，但是该发行版不提供大文件支持。

NFS 服务器日志记录如何工作

NFS 服务器日志记录提供 NFS 读写记录，以及修改文件系统的操作记录。此数据可用于跟踪对信息的访问。此外，记录可以提供用于度量信息重要性的定量方法。

访问启用了日志记录的文件系统时，内核会将原始数据写入缓冲区文件。此数据包括以下内容：

客户机 IP 地址

申请者的 UID

正在访问的文件或目录对象的文件句柄

已执行操作的类型

nfslogd 守护进程会将此原始数据转换为日志文件中存储的 ASCII 记录。转换期间，IP 地址将被修改为主机名，UID 将被修改为登录名（如果已启用的名称服务可以找到匹配项）。文件句柄也被转换为路径名。为了完成转换，该守护进程将跟踪文件句柄并在单独的文件句柄到路径表中存储信息。这样，每次访问文件句柄时，就不必再次识别路径了。由于在 nfslogd 关闭时不会在文件句柄到路径表中对映射进行任何更改，因此必须始终使该守护进程保持运行状态。

注 - NFS 版本 4 不支持服务器日志记录。

WebNFS 服务通过使用公共文件句柄使目录中的文件可用于客户机。文件句柄是内核生成的地址，可标识 NFS 客户机的文件。 公共文件句柄 具有预定义的值，因此服务器不需要为客户机生成文件句柄。通过删除 MOUNT 协议，可以使用此预定义文件句柄来减少网络通信流量。此功能还会加速客户机的进程处理。

缺省情况下，系统将在根文件系统上建立 NFS 服务器上的公共文件句柄。此缺省设置为 WebNFS 提供了对已在服务器上具有挂载权限的任何客户机的访问权限。通过使用 share 命令，可以更改公共文件句柄以指向任意文件系统。

当客户机具有与文件系统对应的文件句柄时，将会运行 LOOKUP ，以确定要访问的文件的文件句柄。NFS 协议一次只允许评估一个路径名组件。目录分层结构的每个附加层都需要运行一次 LOOKUP 。当 LOOKUP 与公共文件句柄有关时，WebNFS 服务器可以使用单个多组件查找事务来评估整个路径名。多组件查找使 WebNFS 服务器可以将该文件句柄传送到所需的文件，而不针对路径名中的每一目录层交换文件句柄。

此外，NFS 客户机还可以通过单一 TCP 连接启动并发下载。此连接提供快速访问，而不会在服务器上产生因设置多个连接而导致的负载增加。尽管 Web 浏览器应用程序支持件并发下载多个文件，但每个文件都有各自的连接。通过使用某个连接，WebNFS 软件可以减少服务器上的开销。

如果路径名中的最终组件是指向其他文件系统的符号链接，则客户机可以访问文件（如果客户机已具备通过正常的 NFS 活动进行访问的权限）。

通常，NFS URL 是相对于公共文件句柄进行评估的。通过在路径的开始位置添加一个附加的斜杠，可以更改评估，使其与服务器的根文件系统有关。在本示例中，如果已在 /export/ftp 文件系统上建立了公共文件句柄，则这两个 NFS URL 是等效的。

nfs://server/junk
nfs://server//export/ftp/junk

注 - NFS 版本 4 协议优先于 WebNFS 服务。NFS 版本 4 完全集成了已添加到 MOUNT 协议和 WebNFS 服务中的所有安全协商。

NFS 服务包括一个协议，该协议使 WebNFS 客户机可以与 WebNFS 服务器协商选定的安全机制。新协议使用安全协商多组件查找功能，该功能是对早期版本的 WebNFS 协议中使用的多组件查找功能的扩展。

WebNFS 客户机通过使用公共文件句柄来发出常规多组件查找请求，进而启动进程。由于客户机不知道服务器保护路径的方式，因此将使用缺省的安全机制。如果缺省的安全机制不够，则服务器将回复 AUTH_TOOWEAK 错误。此回复表明缺省机制无效。客户机需要使用更强大的缺省机制。

客户机收到 AUTH_TOOWEAK 错误后，会向服务器发送请求，以确定需要哪种安全机制。如果请求成功，则服务器将使用指定路径所需的安全机制数组进行响应。根据安全机制数组的大小，客户机可能必须发出更多请求才能获取完整的数组。如果服务器不支持 WebNFS 安全协商，则请求将失败。

请求成功后，WebNFS 客户机将从其支持的数组中选择第一个安全机制。然后，该客户机将使用选定的安全机制发出常规多组件查找请求，以获取文件句柄。所有后续的 NFS 请求都是使用选定安全机制和文件句柄发出的。

注 - NFS 版本 4 协议优先于 WebNFS 服务。NFS 版本 4 完全集成了已添加到 MOUNT 协议和 WebNFS 服务中的所有安全协商。

Web 浏览器使用的 WebNFS 限制

使用 HTTP 的 Web 站点可以提供的多项功能不受 WebNFS 软件的支持。这些差异源自 NFS 服务器仅发送文件这一事实，因此必须在客户机上执行所有的特殊处理。如果需要为 WebNFS 和 HTTP 访问配置一个 Web 站点，则应考虑以下问题：

NFS 浏览不运行 CGI 脚本。因此，带有活动 Web 站点（该站点使用许多 CGI 脚本）的文件系统可能不适用于 NFS 浏览。

浏览器可能会启动不同查看器来处理不同文件格式的文件。如果可以通过文件名来确定文件类型，则通过 NFS URL 访问这些文件便可启动外部查看器。使用 NFS URL 时，浏览器应该识别标准 MIME 类型的任何文件扩展名。WebNFS 软件不会为了确定文件类型而在文件内部进行检查。因此，确定文件类型的唯一方法就是通过文件扩展名。

NFS 浏览不能利用服务器端图像映射（可单击的图像）。但是，NFS 浏览可以利用客户端图像映射（可单击的图像），因为 URL 是使用位置定义的。不需要来自文档服务器的任何其他响应。

NFS 环境是用于在具有不同计算机体系结构和操作系统的网络中共享文件系统的一种强大而便捷的方式。但是，这些通过 NFS 操作使文件系统共享变得非常便利的功能同时还会造成一些安全问题。以前，大多数 NFS 实现使用 UNIX（或 AUTH_SYS）验证，但是也可以使用更强大的验证方法（如 AUTH_DH）。使用 UNIX 验证时，NFS 服务器通过验证发出请求的计算机（而不是用户）来验证文件请求。因此，客户机用户可以运行 su 并模仿文件的所有者。如果使用 DH 验证，则 NFS 服务器将验证用户，这使得此类模仿非常困难。

凭借超级用户访问权限和对网络编程的了解，任何人都可以将任意数据引入网络，并从网络中提取任何数据。最危险的攻击就是涉及数据引入的攻击。例如，通过生成适当的包或通过记录“会话”并稍后重放来模仿用户。这些攻击将影响数据的完整性。涉及被动窃听（仅侦听网络通信流量，而不模仿任何人）的攻击不是很危险，因为不会损害数据完整性。用户可通过对通过网络发送的数据进行加密来保护敏感信息的保密性。

解决网络安全问题的常见方法是针对每个应用程序都单独制定解决方案。更好的方法是在涉及所有应用程序的级别上实现标准验证系统。

Solaris 操作系统包括位于远程过程调用 (remote procedure call, RPC) 级别的验证系统（NFS 操作所依赖的机制）。此系统（称为安全 RPC）可以大大提高网络环境的安全性，并能为 NFS 系统等服务提供附加安全性。当 NFS 系统使用由安全 RPC 提供的功能时，该系统称为安全 NFS 系统。