最近 iStoreOS 25.12 尝鲜版放出，社区里又掀起一波刷机热。哔哩哔哩但不管你是守着 24.10.8 稳定版的老用户，还是刚刷完新固件准备大干一场的新用户，大概率都会撞上同一堵墙——系统提示"overlay 空间不足"，插件装不上，Docker 镜像拉不下来。
最让人窝火的是：你的硬盘明明有 64G、128G，系统里能用的却只有 2G 上下。
这不是你配置错了，而是官方固件的"出厂设定"。从酷友社固件服务器上可以看到，x86 稳定版固件（24.10.8-2026073111，EFI 版）压缩包是 230.4MiB。酷友社刷进硬盘后，镜像只占用前面一小段空间。而社区用户报错信息里 resize2fs 显示的"524288 个 4K 块"，算下来正好是 2GiB——这就是默认的 overlay（可写层）文件系统大小，也是 B 站教程标题里常说的"默认 2G"的由来。知乎剩下的磁盘空间，全都躺在分区表外面睡大觉。
先搞清楚：iStoreOS 里有两个"容量池"
这是大多数教程没讲透、也是评论区翻车最集中的地方。iStoreOS 的"空间不足"其实分两种，报错相似，解法完全不同：
第一个是软件包空间，也就是 overlay 分区。你在 iStore 商店或 opkg 装的插件、系统配置，都落在这里，默认就是那 2G。
第二个是 Docker 数据空间。Docker 的镜像、容器、卷，默认同样挤在 overlay 里。Jellyfin 一装、qBittorrent 一开、再来几个 Home Assistant 之类的容器，几个 G 就没了——Docker 才是吃空间的大户。
为什么要分开说？酷友社官方扩容视频的评论区有个很典型的案例：有用户开了官方的沙箱模式（外挂 overlay），结果"安装个 1G 多的 docker 还是提示 overlay 空间不足。但是 ext-overlay 还空着几十 G"。哔哩哔哩原因就是外挂 overlay 主要服务软件包层，Docker 的数据路径并不会自动跟着搬过去。搞不清自己在哪个池子缺水，扩容就是白费功夫。
路线一：parted + resize2fs 扩根分区，x86 用户的正解
这是知乎和 B 站最近几个月出教程最多、也是效果最彻底的方法：把磁盘上未分配的空间，一次性划给系统最后一个分区。
思路只有三步：SSH 进系统，用 parted 的 print 看清分区布局，把最后一个分区扩到磁盘末尾，再用 resize2fs 把文件系统真正撑大。知乎知乎注意是"最后一个分区"，不要背网上教程里的分区号——EFI 镜像比 Legacy 镜像多一个 EFI 分区，编号会整体后移，这也是早期一键脚本在 EFI 固件上翻车的原因之一。
这条路线的坑，社区基本都替你踩过了：
扩容目标必须带单位（写 `6G` 而不是 `6`），有用户因为漏了 G，直接报"The filesystem is already 524288 (4k) blocks long. Nothing to do!"，看起来像没生效，其实是输入没吃进去；
“Can’t have overlapping partitions” 基本是分区起止位置填错，先 print 再动手；
只扩分区不跑 resize2fs，会出现"系统盘很大、overlay 还是 2G"的错觉，评论区好几个人卡在这一步；
有用户提醒：部分第三方脚本明确不支持 EFI 镜像，别混着用。哔哩哔哩
优点也很实在：扩完的空间直接归系统盘，装插件、跑 Docker 都受益；只要不是 dd 整盘重刷镜像，日常用"保留配置"的方式升级固件，扩容成果和已装内容都能保住。代价是纯命令行操作，分区表敲错有翻车风险，所以一定先备份配置再动手。
顺带一个配套技巧：如果你的机器性能一般（比如 N5105、树莓派这类），Docker 里服务又多，扩容之后可以把 Docker 改成延迟 5~10 分钟启动。有知乎用户实测，冷启动瞬间所有容器一起拉起，弱机型会出现 WiFi 起不来这类连锁问题，错开启动明显更稳。知乎
路线二：内置"Docker 目录"迁移，官方 GUI 里藏着的答案
很多人不知道，iStoreOS 后台首页的向导里就有一个"Docker 目录"入口，官方文档对它的描述很直白：显示 Docker 根目录，可快速迁移 Docker 根目录。iStoreOS 官方文档
也就是说，如果你缺空间的本质是 Docker 数据太大，根本不用碰分区表：插一块大容量硬盘或 U 盘，在"磁盘管理"里格式化挂载，然后把 Docker 根目录迁过去，几个图形化点击就完事。这是四条路线里唯一全程不用 SSH 的，对新手最友好。
但要清楚它的边界：迁移只解决 Docker 这个大户，软件包空间依然是 2G。如果你装插件本身就开始告急，这条路治标不治本。另外有用户反馈迁移后部分应用（比如 1Panel）的上传路径会跟着变，迁移完记得检查一遍依赖路径的服务。
路线三：挂载点"作为外部 overlay 使用"，好用但有三个暗坑
这是官方文档里写的"沙箱模式"的底层能力：把一个 ext4 分区（U 盘、移动硬盘都行）在"挂载点"页面配置成"作为外部 overlay 使用"，重启后系统可写层就叠在这个外部分区上。iStoreOS 官方文档官方最初推它的场景是沙箱实验，社区则拿它当扩容用。
它能用，但评论区的翻车记录值得看一遍再动手：
有用户开启后，插件市场安装插件仍然显示系统盘不足，插件实际还是装进了原系统盘——外挂 overlay 对部分安装路径不生效，预期和实际有落差；
“开了沙箱，但是软件包哪里显示空间还是2g”，界面显示和实际可用空间对不上，容易误判；
外置盘变成了系统的一部分，拔掉 U 盘就可能进不了系统，有用户实测插上开启沙箱后重启异常、拔掉才恢复正常。哔哩哔哩
所以这条路线更适合"临时体验、跑实验"，把它当主路由的永久扩容方案，等于给系统加了一个物理单点故障。
路线四：第三方一键脚本，已经 404 了，别找了
B 站有个播放近万、357 收藏的"iStoreOs 系统盘 overlay 扩容"视频，靠一条 curl 命令下载 sostools 脚本实现一键扩容，当年确实救过不少人。哔哩哔哩
但这条路线现在可以直接划掉了：我实测了视频和评论区流传的两个脚本地址，一个返回 HTTP 404，一个彻底无法连接。评论区的反馈也对得上——从 2025 年底到 2026 年 8 月，陆续有用户报告"地址已经不能用了"“网站已经 404 了，失效了”。哔哩哔哩
比脚本失效更值得记住的是一条原则：软路由是你全家网络的总闸，不要在主路由上随手 `curl | sh` 来路不明的脚本。一键工具省的那十分钟，换成分区表备份和手动 parted，更稳。
对号入座：你该选哪条
x86 小主机当主路由/All-in-One：首选路线一，parted + resize2fs 一次扩到位；动手前先做配置备份，且尽量在能物理接触设备的时间段操作。
主要跑 Docker（影音、下载、智能家居）：先走路线二，把 Docker 根目录迁到大盘，80% 的空间焦虑直接消失；插件装不下了再考虑扩根分区。
ARM 盒子、TF/SD 卡设备：优先换更大容量的卡或挂 USB 盘走路线二。TF 卡本身有寿命问题，把它当高强度 Docker 存储盘是另一个坑。
PVE/ESXi 虚拟机用户：先在虚拟化层把虚拟磁盘扩大，再进系统按路线一做 parted + resize2fs，这是评论区最常见的组合场景。
还没刷机的：可以在写盘前把 img 镜像预扩容（dd 扩镜像 + parted 调分区 + 重新压缩再刷），社区有现成思路，适合洁癖党一步到位。哔哩哔哩
其实上面这些操作的入口都不难找：打开 iStoreOS 首页，磁盘信息卡片、Docker 目录向导、磁盘管理和挂载点入口，全都摆在明面上。iStoreOS 官方文档
最后提醒一句：眼下 25.12 还在测试期，设备适配和稳定性都在变。如果你打算尝鲜，建议把本文的存储规划放在刷机之前想好——新装系统按路线一扩好分区再部署服务，比装完一半再回头动分区表要省心得多。
路由器这种设备，稳定压倒一切。扩容这事，选对路线十分钟搞定，选错路线可能是全家断网半晚上。
