📚 课程目录第3章 NFS协议接入准备

3. NFS协议接入准备

NFS 是 Linux/Unix 客户端访问 ONTAP 文件系统最常用的协议。要让一台客户端成功挂载 ONTAP 上的卷，需要同时满足四层条件：协议版本匹配、ONTAP 侧 NFS 服务器已启用、导出策略允许该客户端访问、以及客户端与存储之间的身份映射和网络可达。任何一层不满足，挂载都会失败。本节按“版本 → 服务 → 导出 → 权限 → 客户端前置”的顺序，把这条链路拆开讲清楚。

一、NFS 版本演进与选型

NFS 从 v3 到 v4.1 的演进，核心变化在于“状态”和“安全”。NFSv3 是无状态协议，服务端不记录客户端打开文件的状态，锁由独立的 NLM 协议处理，端口分散（portmapper、mountd、nfsd、lockd 等），穿越防火墙麻烦。NFSv4 把 mount、锁、状态都合并进单一端口 2049，并引入租约（lease）机制；NFSv4.1 进一步支持会话（session）、并行 NFS（pNFS）和多路径，更适合大规模虚拟化场景。

ONTAP 对版本的支持情况：NFSv3、NFSv4.0、NFSv4.1 均可启用，NFSv4.2 在较新版本中支持。选型建议：传统 Linux 应用、需要简单兼容性时用 NFSv3；需要 Kerberos 认证、ACL 语义、跨防火墙单端口时用 NFSv4.1。注意 NFSv4 的“伪文件系统”概念——客户端看到的是一棵以 / 为根的树，ONTAP 通过 vserver nfs 的 v4-id-domain 和导出路径映射来组织。

二、ONTAP NFS 服务器配置

在 SVM（Storage Virtual Machine）上启用 NFS 是第一步。典型命令如下：

# 在 SVM 上启用 NFS
vserver nfs create -vserver svm_nfs -v3 enabled -v4.0 enabled -v4.1 enabled

# 查看 NFS 服务状态
vserver nfs status -vserver svm_nfs

# 确认 LIF 已承载 NFS 协议
network interface show -vserver svm_nfs -fields address,data-protocols

启用后，ONTAP 会在该 SVM 上启动 NFS 服务，并监听 2049 端口。此时还需要确认数据 LIF 的 data-protocols 中包含 nfs。如果 LIF 只配了 CIFS 或 iSCSI，NFS 请求不会到达。此外，NFSv4 需要 DNS 正反向解析正常，因为 ONTAP 用域名做 ID 映射；NFSv3 对 DNS 依赖较弱，但建议同样配置。

启用 NFS 前先确认 SVM 的根卷已创建、LIF 已 up、DNS 已配置。这三项是 NFS 服务能正常响应的基础。

三、导出策略：控制“谁能访问”

导出策略（export policy）是 ONTAP 的访问控制核心。它由一组规则（rule）组成，每条规则包含：客户端匹配（clientmatch）、只读/读写（ro/rw）、允许的协议、以及是否启用 superuser 和 root 映射。规则按顺序匹配，命中即停。

创建导出策略并绑定到卷的示例：

# 创建导出策略
vserver export-policy create -vserver svm_nfs -policyname pol_app

# 添加规则：允许 10.10.20.0/24 读写，root 映射为匿名
vserver export-policy rule create -vserver svm_nfs -policyname pol_app \
  -clientmatch 10.10.20.0/24 -rorule any -rwrule any \
  -superuser sys -allow-suid true -protocol nfs3,nfs4

# 将策略绑定到卷
volume modify -vserver svm_nfs -volume vol_app -policy pol_app

关键参数说明：-rorule 和 -rwrule 可取 any、none、krb5、krb5i、krb5p。any 表示不校验身份，适合内网可信环境；krb5 系列要求 Kerberos 认证。-superuser sys 表示客户端 root 映射为 ONTAP 的 root 用户，拥有完整权限；若设为 none，客户端 root 会被压缩为匿名用户 nobody，这是更安全的默认做法。

四、权限模型：UNIX 权限与 ACL

ONTAP 卷默认使用 UNIX 权限位（owner/group/other 的 rwx）。当 NFSv4 或 CIFS 同时访问同一卷时，会涉及 NTFS ACL 与 UNIX 权限的映射。ONTAP 提供三种安全模式：unix、ntfs、mixed。纯 NFS 环境用 unix 即可；若同一份数据既要 NFS 又要 CIFS 访问，建议用 mixed 并规划好 UID/GID 与 Windows SID 的映射。

权限判断的实际路径是：客户端 UID/GID → ONTAP 名称服务（LDAP/NIS/本地文件）解析 → 匹配文件属主/属组/other → 决定 rwx。因此，客户端和服务端的 UID/GID 必须一致，否则会出现“文件明明有权限却打不开”的情况。这是 NFS 接入中最常见的坑。

五、客户端挂载前置条件

客户端侧需要满足：已安装 nfs-utils（或 nfs-common）；rpcbind 服务运行（NFSv3 必需）；能解析 ONTAP SVM 的 DNS 名称或直接使用数据 LIF IP；防火墙放行 2049（NFSv4）或 111/2049/相关端口（NFSv3）。挂载命令示例：

# NFSv3 挂载
mount -t nfs -o vers=3,rsize=65536,wsize=65536 10.10.20.11:/vol_app /mnt/app

# NFSv4.1 挂载
mount -t nfs -o vers=4.1 10.10.20.11:/vol_app /mnt/app

# 验证挂载与读写
df -h /mnt/app
touch /mnt/app/testfile && ls -l /mnt/app/testfile

挂载失败时，按“网络 → 服务 → 导出 → 权限”顺序排查：先 ping 和 showmount -e 确认可达与导出可见；再检查 ONTAP 侧 vserver nfs status 和 export-policy rule show；最后核对 UID/GID 与文件权限。ONTAP 侧可用 event log show 查看 NFS 相关拒绝日志。

把上面这张图当作挂载前的检查清单：从左到右四层条件逐项确认，再执行挂载命令。成功时用 df -h 和 touch 验证；失败时按图中红色分支的顺序排查，通常能在几分钟内定位到是网络、服务、导出还是权限问题。

NFSv3 依赖 rpcbind 和多个动态端口，跨防火墙时建议固定端口或直接使用 NFSv4.1。NFSv4 的 ID 映射依赖 DNS，若 DNS 不稳定，会出现文件属主显示为 nobody 的现象。

最后强调一个易被忽略的点：导出策略绑定在卷上，而不是在 SVM 全局生效。同一个 SVM 下不同卷可以有不同的导出策略。修改策略后无需重启 NFS 服务，新规则对后续挂载立即生效，但已挂载的客户端可能仍持有旧的文件句柄，必要时重新挂载以刷新。