nfs配置失败主因是rpcbind与nfs启动顺序错误、防火墙阻断111/2049等端口、/etc/exports权限写法不规范（如ip段误用*、括号空格、未执行exportfs -r）。
NFS 配置失败，八成卡在 RPC 启动顺序、防火墙端口或 /etc/exports 权限写法上 —— 不是服务没起，而是它根本没注册成功。
rpcbind 和 nfs 服务必须按顺序启动
NFS 依赖 RPC 注册端口，rpcbind 必须先于 nfs 启动，否则 showmount -e 会报 clnt_create: RPC: Program not registered。
- 先停掉两个服务：
systemctl stop nfs rpcbind - 再严格按序启动：
systemctl start rpcbind && systemctl start nfs - 验证注册是否成功：
rpcinfo -p localhost应该能看到nfs、mountd、nlockmgr等条目，且端口非 0 - CentOS 7+ 默认用
systemd管理，但旧脚本（如service nfs restart）可能绕过依赖检查，导致顺序错乱
/etc/exports 的权限写法容易踩坑
看似简单的配置行，实际每个字段都影响挂载成败。常见错误是把 IP 段写成 192.168.1.* 或漏掉括号。
Zynq Linux Hardware Debug
下载
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
- 客户端地址必须是 CIDR（如
192.168.1.0/24）、单 IP（如192.168.1.100）或主机名，不支持通配符*单独使用 - 权限选项必须用小括号包裹，且中间不能有空格：
/home/nfs 192.168.1.0/24(rw,sync,no_subtree_check)✅；/home/nfs 192.168.1.0/24 (rw, sync)❌ -
no_root_squash危险：客户端 root 写入会直接映射为服务端 root，生产环境慎用；默认root_squash更安全 - 改完后必须运行
exportfs -r生效，仅重启服务不够 —— 这步常被跳过
客户端 mount 失败时先查端口连通性
报错 clnt_create: RPC: Port mapper failure - Unable to receive: errno 113 (No route to host)，基本等于“防火墙拦住了”，不是网络不通。
- NFSv4 只需开放 TCP 2049，但 NFSv3 还要放开
rpcbind（111）、mountd、nlockmgr等动态端口 - 最稳妥方式：用
rpcinfo -p 服务器IP查出所有端口，再在服务端防火墙放行；或临时关防火墙验证（systemctl stop firewalld） - 挂载命令别漏协议版本：
mount -t nfs4 服务器:/path /mnt比默认 v3 更简洁、端口更固定 - 加
-o soft,timeo=10,retrans=3避免挂载卡死，尤其跨网段或高延迟链路
/etc/fstab 自动挂载要注意超时和依赖
直接写进 /etc/fstab 的 NFS 条目，系统启动时若网络未就绪或服务未响应，会导致开机卡在挂载阶段。
- 必须加
_netdev选项，告诉 systemd 等网络就绪后再挂载：192.168.1.100:/home/nfs /mnt nfs defaults,_netdev,soft,timeo=10 0 0 - 避免用
defaults—— 它隐含hard模式，一旦服务端宕机，进程会永久阻塞在ls或df - 测试 fstab 条目前，先手动
mount -a，看是否报错；不要等重启才发现挂载失败 - 如果服务端可能离线，建议改用 automount（
autofs），按需挂载，更健壮
真正麻烦的从来不是配置本身，而是 RPC 注册状态看不见、防火墙规则摸不着、fstab 里一个选项就能让系统启动卡住 —— 这些点不提前验，排障时间翻倍。
