[BUG] [25.12.5]路由器如果smb挂载有其他外部存储，外部存储失效会导致管理页面无法打开。

我在easepi-r1上安装了最新的25.12.5版本，我网络环境为R1为主路由器，后面连接有NAS，我在R1上将nas通过SMB挂载为一个目录，由于NAS出现故障下线，之后发现R1的服务菜单dockerman js管理页面打不开，提示“XHR request timed out”，多次尝试后，R1的整个管理页面崩溃无法打开,利用AI进行分析原因，直接原因是rpcd堵塞挂掉，AI对原因分析如下： ① 真正的 bug 在 LuCI 上游代码里（luci-base 提供的 rpcd 插件）

路由器上 /usr/share/rpcd/ucode/luci（由 luci-base 提供，不是 iStoreOS 自研）第 536 行起： getMountPoints: { call: function() { const fd = open('/proc/mounts', 'r'); ... for (...每一条挂载...) { const stat = statvfs(mount); // ← 对每个挂载点无条件 statvfs，没有超时、没有跳过、没有容错 if (stat?.blocks > 0) { push(result, {...}); } } 遍历 /proc/mounts 里每一个挂载点做 statvfs()。CIFS 服务端没了时，这个系统调用会在内核里等 CIFS 自己的超时（soft 挂载也会卡几十秒），于是这个 RPC 就"钉"住了。NFS、FUSE、任何失联的网络文件系统都一样中招。

② 放大器是架构：rpcd 同步执行插件调用，没有看门狗

getMountPoints 是跑在 rpcd 进程里的 ucode 插件，同步阻塞。它一卡，rpcd 后面排队的 session（登录/菜单）、uci、file、docker.* 全部排队 → 浏览器那边就是"整站打不开"、"XHR request timed out"。而 uhttpd 的静态资源照样 200，所以看起来像"页面加载不出来"。

③ 应用的调用面很广（这是最容易触发的部分）

这台机器上申请 luci.getMountPoints 权限的 ACL 有 5 个，全都是常用页面：

luci-mod-status-index 状态总览的"存储"卡片（默认首页就渲染） luci-mod-system 系统 → 挂载点 luci-app-package-manager 软件包页 luci-app-dockerman 就是 Dockerman JS 页（为显示 docker 根目录剩余空间） luci-app-mergerfs 磁盘合并 所以只要有一个僵尸挂载，这些页面点谁谁挂——这也解释了为什么"打开 Dockerman 就整站死"。

④ 触发条件是你的环境（这部分不是 bug）

路由器上挂 5 个 NAS SMB 共享这件事，加上我们之前为"NAS 掉线自动重挂"加的护栏（/root/check_nasmount.sh 每 5 分钟 + 自定义 /etc/init.d/nasmount，不是 iStoreOS 自带），会让僵尸挂载被反复重建。如果路由器根本不挂 NAS，这个 bug 你一辈子也碰不到。

结论 是 bug：上游 LuCI 对可能失联的文件系统做 statvfs() 不做超时/跳过，rpcd 又没有防卡死机制——这是上游 OpenWrt/LuCI 的健壮性缺陷，同一份代码在原生 OpenWrt 上也一样（社区的 "LuCi hangs and spins" 就是这一类）。 iStoreOS 不制造它，但更容易撞上：它把这些页面（首页存储卡片 + dockerman）堆在一起，且家用场景常挂 NAS。 你的 NAS 掉线是扳机，不是代码问题；反过来 Also 可以说：这也是个"设计不设防"的典型。