外观
在系统盘上建共享文件夹：sharerootfs
完成后，你能在系统盘的根文件系统上建共享文件夹，并且知道它为什么默认被禁止、哪些插件离不开它、为什么不能随手卸载。
适合谁
需要它的情况：
- 你装的某个 omv-extras 插件依赖它（Compose、KVM、scripts、SnapRAID 等）。这时 apt 会自动把它装上，你不用单独操作。
- 机器只有一块盘（小主机、虚拟机），又想建
appdata、scripts这类放配置和脚本的小共享文件夹。
不适合的情况：媒体库、用户数据、备份目标、Docker 数据。这些放系统盘，迟早把它撑满。有数据盘就用数据盘，见创建并挂载文件系统。
为什么默认不允许
OMV 的设计是系统和用户数据分开。官方文档说，系统盘「不能被官方用于共享资源或用户数据盘」，插件的包说明也写着：根文件系统默认被隐藏、不能建共享文件夹，这是有意为之，目的是把操作系统和用户数据隔开。
实际后果比设计理念更要紧：
- 根分区写满时，apt 更新失败、服务异常。官方故障排查还提到，根分区写满会表现为 Web 界面一直拒绝正确的密码。
- 系统盘一旦重装、更换或恢复备份，放在上面的共享文件夹就一起没了或被回滚。
- 用 U 盘、SD 卡做系统盘时，业务数据还会加速闪存磨损，见减少系统盘写入：writecache 插件。
插件信息
| 项 | 内容 |
|---|---|
| 包名 | openmediavault-sharerootfs |
| 来源 | 官方插件，不需要 omv-extras |
| OMV 8 状态 | 截至 2026-10-22 的官方软件源 synchrony 为 8.0.1-1，要求 OMV 8.3.1 或更新 |
| 菜单位置 | 没有菜单，没有设置页 |
| 被谁依赖 | 八个 omv-extras 插件：openmediavault-compose、openmediavault-kvm、openmediavault-microvm、openmediavault-nvmetcp、openmediavault-scripts、openmediavault-snapraid、openmediavault-symlinks、openmediavault-tgt，列表见下文「不要卸载它」。卸载 sharerootfs 会把它们全部连带卸载 |
它做了什么
按插件源码，安装时它在 OMV 的配置数据库里给根文件系统加一条隐藏的挂载点记录，仅此而已：
- 这条记录的 UUID 在所有系统上都是固定的
79684322-3eac-11ea-a974-63a080abab18，源码注释说这是为了排障时能一眼看出你有没有用这个插件。 - 因为是隐藏的，它不会出现在
存储器 → 文件系统（Storage → File Systems）的列表里，但会出现在共享文件夹的设备下拉框里。 - 没有服务、没有设置，也不占资源。
安装与使用
系统 → 插件（System → Plugins）搜索sharerootfs，安装openmediavault-sharerootfs，硬刷新浏览器，见安装、更新与卸载插件。- 进入
存储器 → 共享文件夹（Storage → Shared Folders），点创建。设备（Device）下拉框里会多出系统盘的根文件系统，显示的文字以你界面上看到的为准。 - 选它，填名称和相对路径，保存并应用。权限的设置和别的共享文件夹一样，见共享文件夹。
依赖它的插件，设置页里需要选一个共享文件夹存放数据（Compose 的 Compose 文件目录、scripts 的脚本目录等）。只有一块盘时，选这里建的共享文件夹即可。
用的时候注意
系统盘上的数据和系统共用命运
- 影响范围：放在系统盘上的共享文件夹，和操作系统共用一个文件系统。写满会拖垮整个 OMV；重装、更换系统盘、恢复系统盘备份会清空或回滚它们；卸载本插件会连带卸载八个插件（见下文）。
- 前置条件：系统盘有足够的剩余空间，官方手动安装表格里根分区的最低要求是 4 GiB，最佳是 120 GiB；放进去的数据已经被备份；定期用
df -h /看根分区使用率。 - 怎么回退：把数据复制到数据盘上的共享文件夹，再把依赖旧共享文件夹的服务和插件设置（例如 Compose 的目录）改指向新的，确认没有任何引用之后，再删除旧的共享文件夹。
- 放小文件，不放大数据。 Compose 文件、脚本、
appdata里的小配置可以；媒体、下载、备份不行。 - Docker 数据别放系统盘。 镜像和卷很容易就几十 GB，见Compose 插件设置详解。
- 系统盘备份会包含它们。 用
backup插件备份系统盘时，放在根分区上的共享文件夹内容也在里面，体积和耗时会变大；恢复系统盘备份时，这些内容会回到备份那一刻的状态，见备份系统盘。 - 不要对系统盘上的共享文件夹用「重置权限」做递归修改。
resetperms插件的 wiki 明确警告：不要改系统所在磁盘、Docker 目录和容器持久化目录的权限，用错会弄坏系统。
不要卸载它
卸载按钮执行的是 apt-get --auto-remove --purge remove。依赖它的插件都会被一起卸载，它们在 OMV 里的设置随之被清除，见安装、更新与卸载插件。依赖它的插件有这八个（依据 2026-10-22 的 synchrony 软件包索引）：
| 依赖它的插件 | 用途 |
|---|---|
openmediavault-compose | Docker Compose 管理 |
openmediavault-kvm | KVM 虚拟机 |
openmediavault-microvm | Firecracker microVM |
openmediavault-nvmetcp | NVMe/TCP 目标（实验性） |
openmediavault-scripts | 在界面里管理和计划脚本 |
openmediavault-snapraid | SnapRAID |
openmediavault-symlinks | 符号链接管理 |
openmediavault-tgt | iSCSI 目标 |
卸载 sharerootfs，这八个都会跟着没有；再往后，依赖 compose 的 openmediavault-imagecheck 和依赖 snapraid 的 openmediavault-snapraid-aio 也会被卸载。它没有界面、没有资源开销，装着不花任何代价，所以别卸。
确实要卸，先弄清楚连带范围：
sh
# 在 OMV 的 shell 里，以 root 身份，只读
apt-cache rdepends --installed openmediavault-sharerootfs
apt-get --simulate --auto-remove --purge remove openmediavault-sharerootfs第二条输出里以 Purg 或 Remv 开头的行，就是会被一起移除的包。
反过来，卸载最后一个依赖它的插件时，--auto-remove 也可能把它顺手清掉。purge 时，只有在没有任何共享文件夹引用那条挂载点记录的情况下，插件才会删掉它。
检查结果
存储器 → 共享文件夹 → 创建（Storage → Shared Folders → Create）里，设备下拉框有根文件系统可选。- 在 OMV 的 shell 里确认已安装，并看看哪些插件依赖它：
sh
# 在 OMV 的 shell 里，以 root 身份，只读
dpkg -l openmediavault-sharerootfs
apt-cache rdepends --installed openmediavault-sharerootfs常见问题
装了插件，设备下拉框里还是没有系统盘。 硬刷新浏览器；仍然没有，确认 系统 → 插件 里它显示已安装。它不会出现在 存储器 → 文件系统 里，因为那条记录是隐藏的。
卸载 Compose 以后它还在吗。 取决于有没有别的插件依赖它，以及 apt 是否判定它不再被需要。想确认就用上面的模拟命令。
根分区快满了怎么办。 先用 du -hx --max-depth=1 /（只统计根文件系统，列出一级目录各占多少）找出大头，把大数据搬到数据盘；见系统盘满了。官方故障排查里写的是 df -hx --max-depth=1 /，--max-depth 是 du 的选项，df 不认。
参考资料
- OMV 文档：系统要求中的系统盘说明、故障排查。
- OMV 源码：
deb/openmediavault-sharerootfs（control、postinst、postrm）。 - 依赖关系来自 omv-extras 与官方软件源的
synchrony软件包索引（2026-10-22）。 - omv-extras wiki：Reset Permissions。