exportfs -r 后客户端看不到共享，根本原因是导出配置未生效或权限不匹配；需确保/etc/exports路径为绝对路径且目录存在、无末尾空格、执行exportfs -ra、rpcbind与nfs-kernel-server均运行。
为什么 exportfs -r 后客户端还是看不到共享？
常见现象是服务端执行了 exportfs -r 或重启了 nfs-kernel-server，但客户端用 showmount -e <server_ip></server_ip> 查不到共享，或者挂载时报 access denied。
根本原因通常是导出配置没生效或权限不匹配。检查点优先级如下：
-
/etc/exports中路径必须是**绝对路径**，且目录实际存在、有读写权限（如/data 192.168.1.0/24(rw,sync,no_root_squash)） - 每行末尾不能有多余空格或注释（
#必须独占一行），否则整行被忽略 - 改完
/etc/exports后，必须运行exportfs -ra（不是-r），-a表示应用全部导出项 - 确认
rpcbind和nfs-kernel-server都在运行：systemctl status rpcbind nfs-kernel-server
客户端挂载时卡住或报 Operation not permitted
这通常不是 NFS 本身的问题，而是客户端环境限制导致的。重点排查以下三点：
- 挂载命令里用了
nfs4协议但服务端没开：默认 Ubuntu/Debian 的nfs-kernel-server支持 v4，但若服务端配置了rpcbind强制降级，客户端需显式指定版本：mount -t nfs4 server:/data /mnt或mount -t nfs -o nfsvers=4 server:/data /mnt - 客户端内核禁用了 NFS 模块（尤其 WSL2 或容器环境）：运行
lsmod | grep nfs，若无输出，先sudo modprobe nfs -
/mnt目录被其他进程占用、或挂载点权限不足（比如挂载到 root-only 目录但用普通用户执行）
/etc/exports 里 no_root_squash 是不是越早加越好？
不是。它让客户端的 root 用户在服务端也拥有 root 权限，本质是信任边界外扩——一旦客户端被入侵，服务端文件系统就直接裸奔。
真实使用中，只在以下场景才考虑启用：
- 客户端和服务端属于同一可信局域网，且双方都是受控服务器（比如 K8s 节点间共享卷）
- 必须由 root 写入服务端（例如某些备份脚本依赖 root UID）
- 替代方案更麻烦（如用
all_squash+ 固定 UID/GID 映射，需同步两端用户 ID）
绝大多数开发/测试共享，用默认的 root_squash 更安全；如果只是想让普通用户能读写，确保服务端目录属组正确、并配 rw,async 就够了。
Ubuntu 22.04 挂载后文件时间戳不准或中文名乱码？
这是 NFS v4 默认 UTF-8 字符集与部分客户端 locale 不一致导致的，不是编码 bug，而是协议协商结果。
解决方法很简单，在客户端挂载时加两个选项：
-
iocharset=utf8：强制字符集为 UTF-8（对 ext4/xfs 有效） -
sec=sys：避免 kerberos 认证干扰（多数局域网不需要） - 完整命令示例：
sudo mount -t nfs4 -o rw,hard,intr,iocharset=utf8,sec=sys 192.168.1.10:/data /mnt/data
注意：该问题在 NFS v3 下不明显，但 v4 是默认协议，别为了绕开而降级——v4 的状态管理、防火墙穿透能力都更好。
NFS 看似简单，但每个环节都依赖两端内核模块、RPC 层、文件系统特性的隐式配合；最常被忽略的是rpcbind 在新内核里的角色变化（v4 可不依赖它，但很多发行版仍默认启用），以及挂载选项里 hard/soft 对程序行为的实质影响。
