飞牛 fnOS 上跑 Docker 和虚拟机:从零到能用的实战路径
一句话结论
飞牛的 Docker 是完整引擎 + 图形化界面,不是阉割版,Compose 也支持,进阶玩家的空间是够的。虚拟机基于 KVM,能用但不是强项。家用场景下:常用服务优先用 Docker,只有在必须跑完整操作系统时才开虚拟机。
Docker 在飞牛上的位置
先明确能力边界:
| 能力 | 支持情况 |
|---|---|
| Docker 引擎 | 完整 |
| Docker Compose | 支持 |
| 图形化管理 | 内置,类似 Portainer 的体验 |
| 镜像仓库 | 可配置(含加速源管理) |
| 容器备份 / 恢复 | 支持(2026 年 6 月版本起) |
社区里还有第三方开发的 Docker 管理工具(版本号已经迭代到 v2.0.x),提供了容器备份、加速源管理、仪表盘展示、多仓库配置等能力。这说明飞牛的 Docker 生态是活跃的——官方给了底层,社区在往上长东西。
部署第一个容器
图形化界面的好处是你不用记命令。大致流程:
1. 打开 Docker 应用 2. 找到”容器”或”项目”入口 3. 填镜像名、容器名 4. 配置端口映射、存储卷、环境变量 5. 启动
三个必须理解的概念:
| 概念 | 作用 | 常见坑 |
|---|---|---|
| 端口映射 | 把容器端口映射到主机端口 | 端口冲突是最常见的启动失败原因 |
| 存储卷 | 把容器内的数据目录挂到主机上 | 不挂载的话,容器一删数据就没了 |
| 环境变量 | 传配置给容器 | PUID/PGID、TZ 这类变量配错会导致权限问题 |
存储卷是最容易被忽略、也最致命的一项。容器的文件系统是临时的,你不把数据目录挂出来,重建容器就等于数据清零。
时区一定要设。容器默认 UTC,不设 TZ=Asia/Shanghai 的话日志时间会差 8 小时,排查问题时非常难受。
一份可以抄的 Compose 示例
以部署一个简单服务为例,Compose 的写法大致是这样:
services:
myservice:
image: example/image:latest
container_name: myservice
restart: unless-stopped
environment:
- TZ=Asia/Shanghai
- PUID=1000
- PGID=1000
volumes:
- /vol1/docker/myservice/config:/config
- /vol1/docker/myservice/data:/data
ports:
- "8080:80"
几个要点:
restart: unless-stopped—— 重启 NAS 后容器自动起来TZ=Asia/Shanghai—— 时区PUID/PGID—— 文件权限,按你自己的用户 ID 填volumes—— 路径用绝对路径,指向你的存储池ports—— 左边是主机端口,右边是容器端口
PUID/PGID 怎么看:SSH 进系统,用 id 用户名 查。权限配错的表现是容器能起来但读写不了文件。
值得跑的容器
按实用程度排:
| 用途 | 容器 | 说明 |
|---|---|---|
| 影音 | Jellyfin / Plex | 如果你想要比飞牛影视更可控的方案 |
| 下载 | qBittorrent / Transmission | 注意合规 |
| 密码管理 | Vaultwarden | 自建 Bitwarden 服务端 |
| 笔记 / 看板 | 各类自建服务 | 视需求 |
| 内网工具 | Homepage / Dashy | 导航页 |
| 监控 | Netdata / Uptime Kuma | 服务可用性监控 |
别一上来装一堆。每多一个容器就多一份维护成本:更新、备份、故障排查。先把一两个真正会用的跑稳,再慢慢加。
国内拉取镜像的痛点
这是国内用户跑 Docker 最实际的问题:官方源时不时就拉不动。
解决思路:
1. 配置镜像加速源。飞牛的 Docker 设置和第三方工具都支持加速源管理,可以配置多个并排序。 2. 多仓库配置。社区工具支持配置飞牛容器仓库、多个第三方仓库,拉取失败时换源重试。 3. 离线导入。实在拉不动的时候,在能拉的机器上 docker save 导出,再 docker load 导入。
加速源会失效,这是常态。别指望配一次管一辈子,拉不动了就换。
虚拟机:能用,但别当主力
fnOS 内置基于 KVM 的虚拟机,可以装 Windows 或 Linux。
什么时候用虚拟机:
- 必须跑一个完整的 Windows 环境(比如某个只有 Windows 版的软件)
- 需要隔离的测试环境
- 想跑另一个发行版做实验
什么时候别用:
- 能装进 Docker 的一律用 Docker。虚拟机的资源开销、启动时间、维护成本都高一个量级。
- 机器内存小于 8GB 时基本不用考虑——Windows 虚拟机起步就要 4GB。
性能预期上,KVM 本身的开销不大,瓶颈在于你给它分配了多少资源以及是否直通了硬件。家用 NAS 上跑虚拟机,通常是”能用”而不是”流畅”。
资源规划:Docker 和虚拟机吃多少
| 场景 | 内存建议 |
|---|---|
| 系统 + 基础服务 | 4GB |
| + 少量 Docker 容器(3-5 个) | 8GB |
| + 相册 AI 索引 | 8GB,CPU 更重要 |
| + 一台 Windows 虚拟机 | 16GB |
| 大量容器 / 多虚拟机 | 16GB 以上 |
内存是 NAS 上最容易被低估的资源。8GB 在 2026 年已经是家用 NAS 的舒适起点,4GB 会处处捉襟见肘。
备份:容器也要备份
很多人记得备份数据,忘了备份容器配置。结果 NAS 挂了之后数据还在,但要把十几个容器重新配一遍。
要备份两样东西:
1. 数据卷(volumes)—— 这是真正的业务数据 2. Compose 文件或容器配置 —— 这是”怎么把服务跑起来”的说明书
飞牛和第三方工具都提供了容器备份功能(备份前会自动停止容器保证数据一致性),用起来就行。再不济,把 Compose 文件存进你的备份目录,成本为零。
故障排查速查
| 现象 | 检查点 |
|---|---|
| 容器起不来 | 端口是否被占用;镜像是否拉取成功 |
| 起来就退出 | 看日志(docker logs);多半是配置项错误 |
| 读写不了文件 | PUID/PGID 是否正确;目录权限 |
| 拉不动镜像 | 加速源是否失效;换源或离线导入 |
| 日志时间不对 | 是否设了 TZ |
| 重启后容器没起 | 是否设了 restart 策略 |
最后
Docker 是让 NAS 从”网盘”变成”家庭服务器”的关键一步。飞牛在这块的完成度足够支撑你从零开始折腾,图形化界面降低了入门门槛,Compose 又保留了进阶空间。
建议你从一个真正会用的容器开始,而不是”别人都在装所以我也要装”。跑稳一个,再考虑第二个。

最后更新于 2026年10月4日