外观
插件还是容器：怎么选
完成后，遇到「既能装插件、也能用容器跑」的功能，你能很快选定一种，并说得出理由。
先看这张表
| 你要的是 | 选 | 原因 |
|---|---|---|
| OMV 自己的能力：磁盘、文件系统、RAID、ZFS、SnapRAID、mergerfs、SMB、NFS、UPS、登录认证 | 插件 | 它们要管磁盘、内核和系统服务，容器做不了，或做不好 |
| 有自己 Web 界面的独立应用：影音、相册、下载、网盘、密码管理 | 容器 | 升级、备份、迁移都独立，不和 OMV 或 Debian 的版本绑在一起 |
| 想最快用上一个简单工具，不想写 compose 文件 | 官方的容器类插件（FileBrowser、WeTTY、PhotoPrism） | 一个开关加几个字段，配置由官方维护；代价是可调的地方少 |
| VPN、封禁暴力破解这类要和系统网络打交道的功能 | 两者都行 | 想在 OMV 界面里管理就用插件，想自己掌控版本和配置就用容器 |
| 想跑完整的虚拟机 | KVM 插件，或在 PVE 上另开虚拟机 | 见 KVM 插件 |
没有特别的理由时，应用用容器，插件只用来扩展 OMV 自己。官方文档也是这个态度，见插件体系。
容器的好处和代价
好处：
- 依赖都在镜像里，不会和 OMV 的 Debian 软件包冲突。官方文档提到，正是软件包版本更新带来的依赖冲突，曾让 OMV 或其他软件无法使用。
- 升级和回滚只动一个容器。OMV 大版本升级时，容器和 OMV 的版本基本解耦。
- 出问题时删掉容器即可，不碰系统包。
代价：
- 要先装好 Docker 和 Compose 插件，并学会写 compose 文件、处理端口与权限。
- 每个容器是独立的进程，带数据库的应用还要再起数据库容器，比插件吃资源。
- omv-extras wiki 的观察：大多数「Docker 不工作」的问题和 OMV、Compose 插件无关，而是架构、网络模式、80 端口冲突和权限。
同一个功能的两种做法
| 功能 | 插件 | Compose 容器 | 要注意 |
|---|---|---|---|
| 网页文件管理 | 官方 openmediavault-filebrowser：Podman 运行 FileBrowser Quantum（镜像 gtstef/filebrowser:stable），前面带一个 Caddy 反代，默认端口 3670，首次登录账号是 admin:admin，要立刻改 | Compose 示例 filebrowser：上游的 filebrowser/filebrowser:latest，端口 8080，以 1000:100 用户运行 | 这是两个不同的项目（Quantum 是分支），界面和功能不同 |
| 照片管理 | 官方 openmediavault-photoprism：Podman 运行，另带 mariadb:11 容器，端口 2342，首次登录 admin:admin，在表单里选原图目录 | Compose 示例 photoprism：上游镜像，端口也是 2342，管理员密码写在环境变量里，示例里是占位值，必须改掉 | 两边默认端口相同，同时装会冲突 |
| 浏览器终端、杀毒、VPN、封禁 | 官方 wetty、clamav，omv-extras 的 wireguard、fail2ban | Compose 示例里也有 wetty、clamav、wireguard、fail2ban、tailscale | 见下表 |
容器示例会随 omv-extras 更新，以 Compose 插件里 从示例添加 能看到的为准。示例里常用 latest 标签，方便，但会在你不知情时换版本，认真使用时固定版本号。
从五个角度比较
| 角度 | 插件 | 容器 |
|---|---|---|
| 装起来 | 点一下，依赖自动处理 | 写或选 compose 文件，建共享文件夹和用户，处理端口与权限 |
| 升级 | 跟系统更新走，版本由维护者定。官方插件的容器镜像可以在 服务 → Podman（Services → Podman）里拉取，是否自动更新本站未核实 | 自己控制。Compose 的计划任务可以先备份、再拉新镜像并重建 |
| 备份 | 插件的设置在 OMV 配置里，数据在你指定的共享文件夹，走常规备份。官方插件的 Podman 容器不在 Compose 的备份范围内 | Compose 的计划备份覆盖通过它管理的容器，默认只带不超过 1 GB 的卷，rsync 后端每次覆盖上一份，详见更新与备份容器 |
| OMV 大版本升级 | 需要这个插件有对应的新版本 | 只要 Docker 引擎能用就行 |
| 卸载和出问题 | 卸载会清除配置，并连带卸载依赖它的插件，见安装、更新与卸载插件 | 删容器即可，数据在你自己的目录里 |
另外，Compose 插件只完整管理通过它的界面创建的容器；在命令行里手动创建的容器，插件里看不全，见Docker 与应用。
两者并存时要注意
- Podman 和 Docker 是两套环境。 官方容器类插件跑在 Podman 里，Compose 插件用的是 Docker，镜像、容器、网络互相看不到。它们共享的是宿主机的端口和资源。
- 端口冲突。 官方插件的默认端口：FileBrowser 3670、PhotoPrism 2342、WeTTY 2222、OwnTone 3689。Compose 示例里的端口可能撞上，装之前在 Compose 的端口页和
ss -tlnp里看一眼。 - 不要两边各装一份指向同一个数据目录。 数据库和索引会被两个版本同时写。
- 官方的 Podman 管理界面和 K3s，见官方容器方案：Podman 与 Kubernetes 插件。
检查结果
选定之后自查三件事：
- 端口没有冲突：
sh
# 在 OMV 的 shell 里，以 root 身份，只读
ss -tlnp常见问题
已经装了插件，想换成容器版。 先备份插件的数据目录，在容器里把数据目录指向它（要先确认两个版本的数据格式兼容），确认能用之后，再卸载插件。两边的数据能否互通因应用而异，不保证。
为什么官方插件和 Compose 里有重名的应用。 官方的容器类插件是为了让你不写 compose 也能一键用上，Compose 示例是社区给想要更多控制的人准备的，它们是各自独立的两份配置，甚至是不同的上游项目。
没有理由选插件，怎么办。 选容器。
参考资料
- OMV 文档：插件。
- omv-extras wiki：Docker in OMV 8、Compose 插件手册。
- OMV 源码：官方容器类插件（
deb/openmediavault-filebrowser、-photoprism、-wetty、-owntone）的表单和 Salt 状态。 - omv-extras 的
packages仓库：compose-files里的示例。