在chroot环境启动nfs-common服务及Debian 9.3 NFS客户端启动失败求助

你在chroot容器里启动NFS客户端遇到的问题，大概率是环境依赖缺失导致的，咱们一步步来排查解决：

1. 先修复/run目录的挂载问题 #

Debian系统默认把/run作为tmpfs挂载，用来存放临时套接字、PID文件这类动态数据，但chroot环境经常会漏掉这个挂载环节——你说df -h | grep run无返回结果，正好印证了这点。

在chroot环境里执行这条命令手动挂载：

mount -t tmpfs tmpfs /run

执行完再跑df -h | grep run，应该就能看到/run被正确挂载为tmpfs了。

2. 确保rpcbind服务正常运行 #

你猜的没错，nfs-common完全依赖rpcbind，没有它根本启动不了。由于chroot里可能没有完整初始化的init系统（比如systemd没正常运行），咱们直接手动启动rpcbind：

/usr/sbin/rpcbind -w

这里的-w参数让rpcbind在前台运行（方便你直观查看是否有报错），如果想让它后台运行，去掉-w再加&即可。

3. 手动启动nfs-common的核心守护进程 #

nfs-common主要包含rpc.statd和rpc.idmapd两个关键进程，咱们挨个启动：

• 启动rpc.statd（加--no-notify避免chroot环境里不必要的网络通知）：

  /usr/sbin/rpc.statd --no-notify
  

• 启动rpc.idmapd：

  /usr/sbin/rpc.idmapd
  

4. 验证服务是否正常运行 #

执行rpcinfo -p命令，你应该能看到rpcbind（端口111）以及nfs相关的服务条目，这就说明启动成功了。

额外排查点：检查/dev设备文件 #

如果上面步骤还不行，看看chroot的/dev目录是不是缺少必要的设备文件（比如/dev/null、/dev/tty），很多守护进程启动依赖这些基础设备。可以通过挂载devtmpfs快速解决：

mount -t devtmpfs devtmpfs /dev

或者如果不想挂载，也可以手动创建关键设备：

mknod /dev/null c 1 3
mknod /dev/tty c 5 0

另外，你可以查看/var/log/syslog里的日志，里面会记录nfs-common启动失败的具体原因，比bash -x调试更直接哦。

内容的提问来源于stack exchange，提问作者Han