NAS 折腾日记（2）PVE 与 Docker 基础环境部署【我的个人天地】

硬件	配置
CPU	Intel Celeron J4125，4 核 4 线程
内存	16 GB
网口	4 个千兆以太网口
硬盘	约 256 GB NVMe，系统识别容量约 238.5 GiB
当前用途	运行虚拟化平台、应用容器及部分基础服务

这次迁移的目标是把应用负载从 QNAP 分离出来，大容量文件仍然放在 NAS，因此小主机的本地磁盘主要用于系统、容器镜像和应用配置。选择 J4125 的主要原因是已有设备可以复用，也避免了为迁移应用再次购买整套存储硬件。

1.2 存储设备：保留 QNAP

QNAP 配备 2 个千兆以太网口，继续承担下载文件、媒体库等文件存储，通过网络共享提供给应用主机。原有文件保留在 NAS 上，迁移主要涉及应用配置、运行环境和挂载关系。

Nextcloud 继续运行在 QNAP。它与现有存储结合较深，本次先迁出其他应用，保留其原有数据和部署方式。

1.3 网络设备：Panabit SRX 千兆版

网络设备使用 Panabit SRX 安全路由器千兆版。J4125 和 QNAP 都通过链路聚合连接到 SRX，设备之间的存储访问也经过这一网络。其 iWAN 用于多点组网。之前尝试过 OpenWrt，后来重新使用硬路由，J4125 也由网络设备转为应用主机。

设备	承担的任务
Panabit SRX 千兆版	设备互联、链路聚合连接、家庭路由与多点组网
J4125	虚拟化、应用运行
QNAP	文件存储、Nextcloud

二、技术选型

2.1 为什么使用虚拟化

小主机直接安装 Linux，再部署 Docker，也可以运行这些应用。这次采用虚拟化，主要是为了将不同服务的运行环境分开管理。家庭环境中既有 DNS、反向代理等基础服务，也有下载、媒体和导航应用，各自的更新、重启和资源需求不同。

通过虚拟化平台，可以分别创建运行环境，设置 CPU、内存、磁盘和网络，独立启停、备份和恢复。这样维护某个服务时，操作范围落在对应的环境中，软件依赖和系统配置也更容易区分。小主机底层负责管理这些环境，具体服务部署在其上。

2.2 底层平台：PVE、ESXi、TrueNAS 与 Unraid

确定使用虚拟化后，再选择安装在物理机上的底层系统。PVE、ESXi，以及具有虚拟机管理功能的 TrueNAS、Unraid，都可以纳入比较，但它们的主要用途有所区别。

平台	主要定位	与本次需求的关系
PVE	集中管理 KVM 虚拟机、LXC、虚拟网络和存储	适合管理独立的应用运行环境
ESXi	裸机虚拟化平台，承载和管理虚拟机	同样可以作为应用主机的虚拟化底层
TrueNAS	以存储池、文件共享和数据管理为核心，并提供应用与虚拟化功能	适合同时承担 NAS 和应用运行的设备
Unraid	集成存储管理、Docker 和虚拟机的服务器系统	适合在一台设备上组合存储与应用服务

TrueNAS 和 Unraid 都具有虚拟化管理能力，但家里已经有 QNAP 承担存储，小主机的任务是承载应用。因此底层优先选择专注虚拟化管理的平台，文件存储继续交给 QNAP。按这套服务划分，以后如果在小主机上试用存储系统，也将其作为虚拟机部署在虚拟化平台上。

接下来主要比较 PVE 与 ESXi。之前使用过 ESXi，这次选择 PVE，首先是开源免费，其次是个人使用时配置和调整环境更自由。PVE 基于 Debian，提供 Web 界面，也可以通过 Linux 命令和配置文件管理网络、存储及服务，符合我的维护习惯。

PVE 同时管理 KVM 虚拟机和 LXC。选定底层后，就可以进一步比较 Docker 放在虚拟机还是 LXC 中运行。

2.3 Docker 的运行环境：虚拟机还是 LXC

需要部署的应用较多，且已有不少服务使用 Docker 镜像。继续采用 Docker，可以统一镜像、目录映射、环境变量和更新方式。这里比较的是 Docker 所在的运行环境。

虚拟机通过虚拟硬件运行一套完整操作系统，拥有自己的内核。在 PVE 中创建 KVM 虚拟机、安装 Linux，再安装 Docker，就得到一个独立的 Docker 主机，其系统和内核可以单独维护。

LXC（Linux Containers）是 Linux 系统容器技术。它通过 namespace 隔离进程、网络和挂载等资源，通过 cgroup 管理资源使用。LXC 有自己的根文件系统、用户、软件包和服务管理，与 PVE 宿主共享 Linux 内核。使用 Alpine 模板创建 LXC 后，可以进入控制台，通过 apk 安装 Docker、通过 OpenRC 管理服务。LXC 官方介绍说明了这种系统容器的工作方式。

对比项	虚拟机内安装 Docker	LXC 内安装 Docker
运行层次	PVE → KVM 虚拟机 → Docker → 应用	PVE → LXC → Docker → 应用
系统与内核	完整客户机系统，独立内核	独立用户空间，共享宿主内核
基础资源开销	客户机内核、系统服务与 Docker	LXC 系统服务与 Docker
系统维护	客户机系统和内核单独更新	更新 LXC 用户空间，内核随 PVE 维护
隔离与兼容性	虚拟机提供独立内核边界，Docker 环境接近普通 Linux 主机	需要配置嵌套运行、挂载权限，并处理存储驱动兼容性
文件共享	在客户机内挂载 NAS，再映射给 Docker	在 LXC 内挂载 NAS，再映射给 Docker
应用管理	通过 Docker 管理镜像和应用容器	通过 Docker 管理镜像和应用容器

J4125 的性能和内存都比较有限，多个服务共享这台主机，因此希望尽量减少运行环境本身的资源开销。综合考虑后，选择 Alpine LXC + Docker：用一个 LXC 提供 Docker 运行环境，应用分别部署为 Docker 容器。相应的嵌套功能和 NFS 挂载权限在部署时配置。

对于 Lucky、AdGuard Home 这类独立基础服务，则采用每个 LXC 安装一个服务的方式，各自管理启动和配置。应用数量较多的一组服务集中交给 Docker 管理，具体划分放在下一章。

2.4 容器管理：Portainer

Docker 的日常管理使用 Portainer。之前已经用了一段时间，对界面和操作比较熟悉，查看日志、修改挂载、调整环境变量和重建容器都比较顺手，因此继续使用。

Portainer 自身以 Docker 容器运行，通过 socket 连接同一 LXC 中的 Docker daemon。PVE 管理 LXC 的系统资源，Portainer 管理其中的应用容器。应用自己的配置文件通过 FileBrowser 编辑，形成容器参数与配置文件分别管理的方式。

2.5 反向代理：Lucky

应用部署后各有自己的地址和端口，使用反向代理可以按域名统一访问入口，并集中配置 HTTPS 证书。客户端连接代理，由代理将请求转发给对应的内部服务，后续调整应用位置时也可以保留访问域名。

方案	配置方式与特点	使用侧重点
Nginx	通过配置文件定义站点、上游和代理规则	适合细致控制转发参数、统一维护配置文件
Caddy	Caddyfile 配置简洁，集成自动 HTTPS	适合以文件维护代理，并自动管理证书
Nginx Proxy Manager	用 Web 界面管理 Nginx 代理主机和证书	适合可视化配置 Web 服务入口
Lucky	Web 界面集成反代、证书管理、动态域名和端口转发等功能	适合在同一界面维护家庭网络入口

选择 Lucky 主要是已有使用经验。从 OpenWrt 时期就开始使用，对配置方式已经熟悉；它的界面功能比较齐全，反代规则和证书配置都方便，因此这次继续保留。部署位置改到独立 LXC 后，仍沿用这套入口管理方式。

2.6 DNS 与广告过滤：AdGuard Home

反向代理解决域名请求转发到哪个服务，DNS 则负责让客户端找到这个域名对应的地址。家庭环境需要统一解析入口、配置内部域名，同时对广告和追踪域名进行过滤。

方案	主要能力	维护方式
AdGuard Home	DNS 转发、域名过滤、查询日志、客户端设置与 DNS 重写	通过 Web 界面管理上游、过滤规则和内网解析
Pi-hole	网络级 DNS 广告过滤、查询统计与本地域名管理	通过 Web 界面管理过滤列表、客户端和解析配置

这两种方案都可以承担家庭 DNS 过滤。我的浏览器和手机一直使用 AdGuard 的广告拦截产品，AdGuard Home 也从 OpenWrt 时期开始使用。经过这段时间的实际使用，过滤和管理体验都比较符合需求，因此继续使用 AdGuard Home。

在本方案中，AdGuard Home 负责家庭 DNS 查询，并将内部服务域名解析到反向代理入口。DNS 层按域名过滤，浏览器和手机端继续使用各自的 AdGuard 产品处理客户端侧的过滤需求。

2.7 服务导航：Homepage

域名和代理配置完成后，还需要一个页面汇总服务入口，便于从同一位置打开管理工具和应用。导航页面主要考虑链接分组、配置维护方式，以及是否需要展示服务状态。

方案	配置方式	特点
Homer	YAML 配置	静态导航页面，适合整理链接和分组
Homarr	可视化配置与布局	适合通过界面组织仪表盘和服务组件
Homepage	YAML 文件，也支持 Docker 标签发现	以配置文件组织导航，并提供服务状态集成

选择 Homepage，主要是配置逻辑比较简单。服务、书签和页面设置分别放在 YAML 文件中，修改文件即可维护导航，不需要进入一套配置管理后台。它本身仍以服务形式运行，并可代理状态组件的请求。

这也与 FileBrowser 的使用方式衔接：Homepage 的配置目录挂载到 LXC 本地，FileBrowser 打开同一目录，直接编辑 services.yaml、bookmarks.yaml 和 settings.yaml。配置文件和图标可以一起备份，新增服务时按已有条目补充即可。

三、架构设计

3.1 服务划分

按前面的选型，在 PVE 中创建 Alpine LXC 运行 Docker，通过 Portainer 管理容器、FileBrowser 编辑配置、Homepage 汇总入口。Lucky 和 AdGuard Home 分别使用独立 LXC，提供反向代理与 DNS。QNAP 提供共享存储，挂载到 Docker 所在的 LXC。

text
1
2
3
4
5
6
7
8
9
J4125
└─ PVE
   ├─ LXC：Lucky
   ├─ LXC：AdGuard Home
   └─ LXC：Alpine Linux
      └─ Docker
         ├─ Portainer
         ├─ FileBrowser
         └─ Homepage

PVE 管理上述 LXC，Docker 管理其中的基础服务容器；QNAP 的共享目录通过 NFS 接入 Alpine LXC。

3.2 存储架构：本地配置 + NAS 共享

存储分为应用状态和共享文件两部分。应用配置、部分数据库、缓存及 Docker volumes 放在小主机本地；下载文件和媒体库保留在 QNAP。

数据类型	存储位置	处理方式
系统、镜像、容器可写层	小主机本地磁盘	由 PVE 和 Docker 管理
配置、应用数据库、缓存	LXC 本地目录或 Docker volume	按应用持久化
下载文件、媒体库	QNAP	挂载到 LXC 后提供给容器

网络共享最初使用 SMB/CIFS，后来遇到软链接在不同客户端中表现不一致的问题，改为 NFS。目前使用 NFSv4，直接在 Alpine LXC 内挂载 QNAP 共享，再通过 Docker bind mount 映射到应用容器。

本地配置与 NAS 共享分别保存。配置目录位于小主机，下载目录和媒体库位于 QNAP；在 LXC 内挂载后，可以按需要映射给容器使用。

3.3 网络架构：千兆链路与链路聚合

应用从 QNAP 搬到 J4125 后，下载、媒体读取等操作需要经过网络访问 NAS。网络连接因此成为存储方案的一部分：应用主机负责运行服务，NAS 提供文件，两者之间的数据传输依赖网口、聚合配置和实际流量分配。

设备	物理接口	连接方式
J4125	4 个千兆网口	通过链路聚合连接 Panabit SRX
QNAP	2 个千兆网口	通过链路聚合连接 Panabit SRX
Panabit SRX 安全路由器千兆版	千兆网络	承接应用主机与 NAS 的聚合连接

text
1
2
3
4
J4125（四口千兆）                 QNAP（双口千兆）
       │                              │
   链路聚合连接                    链路聚合连接
       └──── Panabit SRX 千兆版 ────────┘

检查两端的 /proc/net/bonding/bond0，实际运行配置如下：

项目	PVE / J4125	QNAP
Bond 模式	`balance-xor`	`balance-xor`
发送哈希策略	`layer3+4`	`layer2`
聚合成员	4 个千兆网口全部加入 bond0	2 个千兆网口加入聚合
实际接线	接入 2 根网线	接入 2 根网线
有效端口速率	每口 1000 Mbps，全双工	每口 1000 Mbps，全双工
链路检查间隔	100 ms	100 ms

J4125 的四个千兆网口全部加入 bond0，当前接入两根网线；QNAP 的两个千兆网口组成聚合并接入两根网线。两台设备分别通过 XOR 静态聚合连接 SRX。应用主机和 NAS 均采用双链路连接，为多个服务的并发访问提供网络基础。

PVE 的 layer3+4 根据 IP 地址和传输层端口等信息分配发送流量，多条连接有机会分布到不同成员口。QNAP 的 layer2 主要根据源、目的 MAC 等二层信息选择出口，同一对 MAC 的同类流量会落到同一成员口。这套配置下，多连接的分流取决于各端使用的哈希策略，具体机制见 Linux bonding 文档。

PVE 和 QNAP 各自负责本端发送流量的选路，SRX 负责向聚合成员口分配转发流量。单条 TCP 连接使用一条成员链路，多条流量按哈希结果分配。

多个容器同时下载、整理媒体和播放文件时，共享访问会集中到 NAS 的网络连接上。将应用迁出 QNAP 可以分离计算负载，但文件读写仍然受 NAS 磁盘和网络吞吐限制。因此本地保留应用配置与缓存，大文件通过共享访问，网络与存储需要一起规划。

3.4 反向代理、DNS 与服务导航

服务入口采用 Lucky、AdGuard Home 和 Homepage，分别承担反向代理、DNS 和导航功能。

组件	用途	部署方式
Lucky	Web 服务反向代理	独立 LXC
AdGuard Home	DNS 服务与过滤	独立 LXC
Homepage	汇总服务入口	Docker 容器，由 Portainer 管理
FileBrowser	网页编辑本地应用配置	Docker 容器，由 Portainer 管理

Lucky用于配置服务转发，AdGuard Home处理 DNS 与过滤，Homepage将分散的服务入口汇总到一个页面。对于这套家庭环境，可视化管理和集中访问是采用这些组件的直接用途。

Homepage 汇总服务链接；访问时由 DNS 解析对应域名，再按反向代理配置转发至应用。

四、部署操作

下面按新建环境的顺序整理部署步骤。示例中的地址、容器编号和目录统一使用下表，部署时替换为自己的规划；网络参数与路径已经脱敏。

对象	示例配置
局域网 / 网关	`192.168.20.0/24` / `192.168.20.1`
PVE	`192.168.20.10`
QNAP	`192.168.20.20`
Docker LXC	CT `200`，`192.168.20.30`
Lucky LXC	CT `201`，`192.168.20.31`
AdGuard Home LXC	CT `202`，`192.168.20.32`
本地配置目录	`/srv/appdata`
NAS 挂载目录	`/mnt/nas/downloads`、`/mnt/nas/media`
导航域名	`home.example.com`，替换为自己持有的域名

4.1 安装 PVE

从 PVE 下载页下载安装 ISO，将镜像写入启动 U 盘。
在 J4125 的 BIOS 中开启 Intel 虚拟化支持，选择 U 盘启动。
进入 PVE 安装程序，选择本地 NVMe 作为系统盘。安装会重新分区，应先转移该盘原有文件。
本机使用 ZFS。单块 NVMe 在安装选项中选择单盘 ZFS（界面通常标为 RAID0），系统和 LXC 根盘都放在本地存储中。
设置地区、时区、管理员密码和邮箱。
网络配置先选一个已连接的物理网口，填写主机名，例如 pve.example.com；地址填写 192.168.20.10/24，网关 192.168.20.1。DNS 先使用现有可用的解析服务器，后续再接入 AdGuard Home。
安装完成后移除 U 盘并重启，在管理电脑访问 https://192.168.20.10:8006，使用 root 和安装时的密码登录，认证域选择 Linux PAM。

进入节点的 Disks / ZFS 检查本地存储，再查看 local 和 local-zfs。前者用于模板等文件，后者用于虚拟机和容器磁盘。本文后续以这两个存储名称为例。

在 PVE Shell 中查看安装结果：

bash
1
2
3
4
pveversion
zpool status
pvesm status
ip -br address

整理本文时，实际环境为 PVE 9.2.4。软件源沿用安装版本对应的仓库；在节点 Updates → Repositories 中，根据是否持有订阅选择相应仓库，再通过 Updates 刷新并更新。

4.2 配置 SRX、PVE 与 QNAP 链路聚合

PVE 将 J4125 的四个网口全部配置为 bond0 成员，实际使用两根网线连接 SRX；QNAP 的两个网口都加入聚合，并使用两根网线连接 SRX。先标记两组网线对应的 SRX 端口，应用主机和 NAS 各自组成一个独立的聚合组。

在 SRX 上，将连接 J4125 的两个端口归入一组静态聚合，将连接 QNAP 的两个端口归入另一组，两组都接入存储所在的 LAN。主机侧使用 balance-xor，对端应采用匹配的静态聚合方式。SRX 的菜单名称随固件变化，这里按配置对象记录：

配置对象	成员	工作方式
应用主机聚合组	连接 J4125 的两个 SRX 端口	静态聚合，接入 LAN
NAS 聚合组	连接 QNAP 的两个 SRX 端口	静态聚合，接入同一 LAN

配置 PVE 时，先在节点 System → Network 确认网口名称。本机四个成员接口为 enp2s0、enp3s0、enp4s0、enp5s0；配置时按自己设备上的接口名称填写：

打开当前 Linux Bridge vmbr0，记录管理 IP、网关和已有 Bridge ports。
创建 Linux Bond，名称 bond0，Slaves 填入全部四个物理口，Mode 选择 balance-xor，Transmit Hash Policy 选择 layer3+4。
将 vmbr0 的 Bridge ports 改为 bond0，管理 IP 和网关继续配置在 vmbr0 上。
确认物理口和 bond 上没有重复的管理地址，再应用网络配置。操作期间保留本机显示器或控制台，便于恢复连接。

四口聚合配置对应的 /etc/network/interfaces 如下。界面配置完成后可以用它核对字段：

conf
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
auto lo
iface lo inet loopback

iface enp2s0 inet manual
iface enp3s0 inet manual
iface enp4s0 inet manual
iface enp5s0 inet manual

auto bond0
iface bond0 inet manual
    bond-slaves enp2s0 enp3s0 enp4s0 enp5s0
    bond-miimon 100
    bond-mode balance-xor
    bond-xmit-hash-policy layer3+4

auto vmbr0
iface vmbr0 inet static
    address 192.168.20.10/24
    gateway 192.168.20.1
    bridge-ports bond0
    bridge-stp off
    bridge-fd 0

source /etc/network/interfaces.d/*

QNAP 在 网络与虚拟交换机 → 网络 → 接口 中配置端口聚合，选择两个物理网口，使用 Balance XOR，给聚合后的网络接口设置固定地址 192.168.20.20/24 和网关 192.168.20.1。这个配置页面在选择 Balance-xor 后，没有提供单独的发送哈希策略选项，页面说明采用目的 MAC 地址选择传输连接，因此这里沿用界面的配置。通过 /proc/net/bonding/bond0 检查，对应的实际发送策略为 layer2；PVE 的配置页面则可以单独选择 layer3+4。

两台机器分别执行：

bash
1
cat /proc/net/bonding/bond0

检查两条成员链路均为 MII Status: up、Speed: 1000 Mbps、Duplex: full。PVE 再检查网桥和 NAS 连通性：

bash
1
2
bridge link show master vmbr0
ping -c 3 192.168.20.20

4.3 创建 Alpine LXC

在 PVE 的 local → CT Templates → Templates 中下载 Alpine 3.22 的 amd64 模板，然后点击 Create CT。

创建页面	Docker LXC 示例值
General	CT ID `200`，Hostname `docker`，设置 root 密码
Unprivileged container	取消勾选，本方案在 LXC 内直接挂载 NFS
Template	下载的 Alpine 3.22 模板
Root Disk	`local-zfs`，80 GB
CPU	4 核
Memory	8192 MB；swap 按宿主实际配置设置，本例为 0
Network	`eth0`，Bridge `vmbr0`，静态地址 `192.168.20.30/24`
Gateway	`192.168.20.1`
DNS	当前可用的 DNS，避免依赖尚未安装的 AdGuard Home

创建后先保持容器停止，在 Options → Features 中启用 Nesting。网络文件系统挂载选项也可以在 PVE Shell 设置：

bash
1
2
3
4
5
# 在 PVE 执行；200 是本例的新建 Docker LXC
pct set 200 -features nesting=1,mount=nfs
pct set 200 -onboot 1
pct start 200
pct enter 200

特权 LXC 内的 root 与宿主权限关系较强，这里用它承载自己管理的应用和 NFS 挂载。上面的功能配置用于本篇基础部署；实际机器上为其他服务增加的设备映射不纳入这一步。

进入 LXC 后确认系统与网络：

bash
1
2
3
4
cat /etc/alpine-release
ip address show eth0
ip route
ping -c 3 192.168.20.20

4.4 安装 Docker 与准备目录

以下命令在 Docker LXC 内执行。先编辑 /etc/apk/repositories，确保同一版本的 main 和 community 都启用。Alpine 3.22 的示例：

text
1
2
https://dl-cdn.alpinelinux.org/alpine/v3.22/main
https://dl-cdn.alpinelinux.org/alpine/v3.22/community

安装 Docker、NFS 客户端及基本工具：

bash
1
2
3
4
5
6
7
8
apk update
apk add docker docker-cli-compose nfs-utils curl ca-certificates
rc-update add docker boot
rc-service docker start

docker version
docker info
docker run --rm hello-world

docker version 应同时显示 Client 和 Server，hello-world 应成功运行。实际机器整理时使用 Docker 28.3.3，存储驱动为 overlay2，Docker 数据目录为 /var/lib/docker。

建立基础目录：

bash
1
mkdir -p /srv/appdata /mnt/nas/downloads /mnt/nas/media

具体应用的子目录和属主在相应部署文章中设置。

4.5 在 QNAP 开启 NFS 并挂载

QNAP 控制面板中进入文件服务设置，启用 NFS，并启用 NFSv4。
打开共享文件夹权限，分别为下载目录和媒体目录配置 NFS 主机访问。
允许主机填写 Docker LXC 的 IP 192.168.20.30，读写共享选择读写权限。挂载请求来自 LXC，因此这里填 LXC 地址。
记录 QNAP 显示的共享导出路径。下面以 /Downloads、/Media 为例，实际应以 NAS 设置为准。
保留现有文件属主；根据服务运行的 UID/GID 设置共享访问权限及用户映射。需要写文件的应用，必须能够以其运行身份写入共享。

回到 Docker LXC，先手动挂载：

bash
1
2
3
4
5
6
mount -t nfs -o vers=4 192.168.20.20:/Downloads /mnt/nas/downloads
mount -t nfs -o vers=4 192.168.20.20:/Media /mnt/nas/media

mount | grep ' /mnt/nas/'
ls -ln /mnt/nas/downloads
ls -ln /mnt/nas/media

应能看到 nfs4 类型和 NAS 上已有的文件。若提示 access denied by server，回到 QNAP 检查允许的客户端 IP、导出路径和共享权限；若为 Operation not permitted，检查 PVE 上该 LXC 的 NFS 挂载功能是否启用。

挂载成功后，将以下两行加入 LXC 的 /etc/fstab：

fstab
1
2
192.168.20.20:/Downloads /mnt/nas/downloads nfs vers=4,_netdev 0 0
192.168.20.20:/Media     /mnt/nas/media     nfs vers=4,_netdev 0 0

启用 Alpine 的网络挂载服务：

bash
1
2
rc-update add netmount default
rc-service netmount start

接下来让 Docker 等待网络挂载。前面 Docker 加入了 boot，这里将它移到 default，与 netmount 建立明确依赖：

bash
1
2
rc-update del docker boot
rc-update add docker default

编辑 /etc/conf.d/docker，添加以下配置；已有 rc_need 时在原值中追加 netmount，不要覆盖其他依赖：

sh
1
rc_need="netmount"

这是 OpenRC 支持的服务依赖配置。启动时先完成 /etc/fstab 中的网络挂载，再启动 Docker。这里选择让整个 Docker 服务等待 NAS，因此 NAS 不可用时，本地导航等容器也可能无法随开机启动。AdGuard Home 和 Lucky 放在独立 LXC 中，不受这项 Docker 依赖影响。

这项配置解决启动顺序；运行中 NAS 掉线后的恢复仍要检查挂载。仅能 ping 通 NAS 不代表 NFS 已就绪。若 Docker 已把未挂载的空目录绑定进应用，需要在挂载恢复后重启相关容器，具体见 qBittorrent 篇。

实际迁移经历过 SMB 到 NFS 的调整，原因是软链接在不同客户端的识别问题。使用 NFS 后，仍应保持链接目标在容器内部可访问，媒体库和下载目录的容器路径也要相互对应。

4.6 验证基础环境

在 Docker LXC 中检查：

bash
1
2
3
4
5
docker version
docker run --rm hello-world
mount | grep ' /mnt/nas/'
ls -ln /mnt/nas/downloads
ls -ln /mnt/nas/media

Docker 能正常运行，LXC 能通过 NFS 读取 QNAP 的共享目录和文件后，PVE 与存储的整合完成。

后续独立服务沿用相同网桥与网关，示例编号统一如下。CT ID 先在 PVE 中确认没有占用，实际使用其他编号时，同步修改 Homepage 的关联配置。

LXC	示例 CT ID	地址	用途
docker	200	`192.168.20.30`	Docker 与 NFS 挂载
lucky	201	`192.168.20.31`	反向代理
adguard	202	`192.168.20.32`	DNS

Lucky 和 AdGuard Home 使用普通非特权 LXC 即可，不需要照搬 Docker LXC 的特权、nesting 和 NFS 挂载设置。

系列阅读

本篇完成 PVE、Docker 运行环境与 QNAP 共享存储的连接。基于这套环境，容器管理、配置编辑、导航与域名访问分别在以下文章中展开：

参考

手机扫码阅读

本文作者: 有次元袋的 tiger

本文链接: https://www.superheaoz.top/2026/09/46627/