Homelab 服务器配置与演进

当前架构概览

• 宿主系统：Debian 13 netinst
• 网络管理：Netplan + systemd-networkd
• 虚拟化/容器：Incus
• 主路由：Incus VM 运行 OpenWrt
• 业务容器：Debian container，运行文件共享、Jellyfin、Docker 服务等
• Home Assistant：Incus VM，挂载 HAOS raw 磁盘
• 网络：
• 光猫 → enp1s2 → br-wan → OpenWrt WAN
• OpenWrt LAN → br-lan → enp0s1 + 宿主机 + Wi-Fi AP + 业务容器/虚拟机

光猫
  │
enp1s2 ── br-wan ── OpenWrt VM (WAN)
                         │
                    OpenWrt LAN
                         │
                 enp0s1 ── br-lan
                         |
    宿主机 / Wi-Fi AP / production container / HAOS VM

---

一、搭建教程

1. 基础系统安装

使用 Debian 13 netinst 镜像。

分区建议使用 LVM。预置分区方案下不方便先选方案再调整大小，且缩小 root/home 不能在线操作；如果不想手工逐项分区，可以接受预置方案，后续再规划。

桌面环境选择 XFCE：目前实验下来稳定、省资源。安装时开启 SSH 服务器。

root 密码设置界面可以留空。界面会提示：无 root 密码相当于禁用 root 登录，安全性更高；日常使用普通用户 + sudo。

2. 网络配置：Netplan + networkd

Debian 安装完成后通常已能通过光猫 DHCP 获取地址并访问网络。安装 Netplan：

sudo apt install netplan.io

查看网卡：

ip link

服务器至少两个网卡时，先都设为 DHCP，保证后续安装软件有网可用：

# /etc/netplan/xxx.yaml
network:
  version: 2
  renderer: networkd
  ethernets:
    enp0s1:
      dhcp4: true
      dhcp6: true
    enp1s2:
      dhcp4: true
      dhcp6: true

应用配置：

sudo netplan apply

netplan apply 可以反复执行；获取不到 IP 时可以重试，相当于刷新网络。

关闭不需要的网络管理服务：

sudo systemctl disable --now networking
sudo systemctl disable --now NetworkManager
sudo systemctl disable --now ModemManager

说明：服务器场景选择 networkd，不使用 NetworkManager。NetworkManager 更适合桌面和 Wi-Fi 管理。

注意：使用 Netplan + networkd 时，应确认 systemd-networkd 已启用。

bash systemctl enable --now systemd-networkd networkctl status

安装常用工具：

sudo apt install htop vim byobu

Byobu 习惯使用 Ctrl+S 作为激活快捷键。

3. 安装并初始化 Incus

Debian 13 可直接通过 apt 安装 Incus；Debian 12 需要 backports。

参考 Incus 官方 first steps 初始化。将当前用户加入 incus-admin：

sudo adduser "$USER" incus-admin
newgrp incus-admin

执行：

incus admin init

大部分保持默认，主要把 Incus 默认 storage 设置到希望存放虚拟机和容器的目录。

4. 部署 OpenWrt 主路由 VM

原先运行在 Incus container 上的 OpenWrt 迁移后有问题，短时间未解决，改为新装 VM 版本作为主路由。

拉取 OpenWrt 镜像并创建 VM：

incus create images:openwrt/25.12 openwrt-25-router-vm --vm

镜像别名需按实际 incus image list images:openwrt 确认。

4.1 创建网桥

用 Netplan 创建 br-wan 和 br-lan，并绑定物理网卡。br-lan 是必要的：OpenWrt LAN、宿主机本地网络、Wi-Fi AP 都像被一根虚拟线连在一起，类似交换机。br-wan 不是必须，也可以把物理网口直接分配给 OpenWrt；这里保留是为了习惯和结构清晰。

network:
  version: 2
  renderer: networkd
  ethernets:
    enp0s1:
      dhcp4: false
      dhcp6: false
      # Intel e1000e 老网卡偶尔卡滞几秒时，可尝试关闭 offload
      tcp-segmentation-offload: false
      generic-segmentation-offload: false
    enp1s2:
      dhcp4: false
      dhcp6: false

  bridges:
    br-wan:
      interfaces: [enp1s2]
      dhcp4: false
      dhcp6: false
      optional: true

    br-lan:
      interfaces: [enp0s1]
      dhcp4: true
      dhcp6: true
      # optional 防止 wait-for-online 等待分配 IP 时卡死
      optional: true
      parameters:
        # stp: false
        # forward-delay: 0

应用：

sudo netplan apply

4.2 给 OpenWrt VM 绑定网卡

incus config device add openwrt-25-router-vm eth0 nic nictype=bridged parent=br-wan
incus config device add openwrt-25-router-vm eth1 nic nictype=bridged parent=br-lan
incus config set openwrt-25-router-vm security.secureboot=false

启动：

incus start openwrt-25-router-vm

4.3 通过 console 初始化 OpenWrt LAN

默认 OpenWrt 未开启 LAN，内网没有分配 IP，SSH 进不去，需要 console：

incus console openwrt-25-router-vm

如果没显示，按方向键激活。退出方式：先按 Ctrl+a，再单独按 q。

编辑 /etc/config/network，加入：

config device
        option name 'br-lan'
        option type 'bridge'
        list ports 'eth1'

config interface 'lan'
        option device 'br-lan'
        option proto 'static'
        option netmask '255.255.255.0'
        option ip6assign '60'
        option ipaddr '192.168.99.1'

重启网络：

/etc/init.d/network restart

退出 console，在宿主机执行：

sudo netplan apply

宿主机 br-lan 会通过 DHCP 获得 OpenWrt 分配的 IPv4 地址。之后可通过 SSH 或浏览器配置 OpenWrt。连接在 br-lan 上的 Wi-Fi AP 也能正常广播网络服务。

5. 创建业务容器

再启动一个 Debian container，把文件共享、Jellyfin 等 Docker 服务放在里面。

主要操作：

1. 绑定 br-lan，让容器与其他网络设备平等互通。
2. 挂载宿主机目录。宿主机先把数据盘挂到 /mnt/data，再挂给容器：

incus config device add production data disk source=/mnt/data path=/mnt/data

好像做过idmap映射防止挂载文件出现的权限问题，或者是设置了硬盘的shift

容器内运行 Docker 需要给容器设置nesting：

incus config set production security.nesting=true

部署 linuxserver 打包镜像时遇到 s6 IPC permission 问题。日志指向 AppArmor，给 Docker container 加：

--security-opt apparmor=unconfined

可以绕过。该问题是否与宿主系统软件更新有关尚未确认，作为 workaround 记录。

6. 迁移 Home Assistant 到 Incus VM

原 Home Assistant 运行在 libvirt。安装 libvirt 时出现明显卡滞，怀疑与 Incus VM 冲突；导入 domain.xml 后问题短时间未解决，改为 Incus 管理。

Incus 管理 VM 的最大弊端：不能直接使用 qcow2，磁盘真实占用会较大。曾尝试直接挂载 qcow2，无法引导。

创建空 VM：

incus create --empty --vm homeassistant

编辑配置：

incus config edit homeassistant

关键配置：

config:
  security.secureboot: "false"

devices:
  eth0:
    nictype: bridged
    parent: br-lan
    type: nic
  haos-disk:
    boot.priority: "10"
    source: /path/to/homeassistant/haos.raw
    type: disk

要点：

• HAOS 磁盘需转换为 raw。
• 通过 disk device 挂载 raw 磁盘。
• 配置 br-lan。
• 关闭 secureboot。
• 不需要改太多其他配置，格式转换后即可正常启动。

7. Vim 配置：禁用鼠标

Debian 默认 Vim 配置开启鼠标控制。常规使用影响不大，但鼠标选中文字再复制到其他地方会受干扰。Vim 内部复制仍可用 Vim 命令。

临时禁用：

:set mouse=

永久配置：编辑 /etc/vim/vimrc，加入：

source $VIMRUNTIME/defaults.vim
" 禁用鼠标功能
set mouse=

注意：用户 home 下没有 .vimrc 时，Vim 会使用 /usr/share 下的配置，不读取 /etc/vim/vimrc。因此还需要：

touch ~/.vimrc
sudo touch /root/.vimrc

否则 sudo 下使用 Vim 时配置不生效。若没有显式 source $VIMRUNTIME/defaults.vim，后面的配置可能被 defaults 覆盖；先引入 defaults，再用 set mouse= 覆盖。

8. 文件系统性能测试

测试参考 Google Cloud 磁盘 benchmark 方法。结果如下：

场景	写 IOPS	写带宽	读 IOPS	读带宽
host ext4	39.7k	155 MiB/s	21.9k	85.6 MiB/s
container btrfs	10.4k	40.8 MiB/s	18.8k	73.5 MiB/s
container dir on ext4	22.2k	86.8 MiB/s	21.9k	85.4 MiB/s

结论：同一分区下 btrfs 比 ext4 的 load average 更高、速度更慢，因此暂不考虑 btrfs。该结论仅代表本机该次测试，日后会再次验证比对。

---

二、Homelab 历史演进

最早大概是 2016 年左右，参加工作几年后逐渐熟悉 Linux，主力机也换成了 Linux。当时一方面希望开发环境尽量接近线上，另一方面不想把主力电脑搞得太乱，于是开始用虚拟机做隔离。最开始用 VirtualBox/Vagrant，踩过的坑现在还记得：虚拟机里 Nginx 效率低，最后靠 sendfile on 解决；开发时文件在本地，虚拟机共享过去运行，VirtualBox 文件共享性能太低，于是又搭 NFS，效率好很多。

后来接触到 headless 技术，虚拟机可以像服务一样跑在后台。也给公司内网服务器搭过 VirtualBox Web Server，通过浏览器远程创建和控制虚拟机，算是内网部署环境，尽量向生产环境靠齐。

再后来觉得 VirtualBox 有点臃肿，频繁看到 QEMU，于是转向 libvirt/KVM。之前租 VPS 时只知道 KVM 和 OpenVZ，没细了解；实际用下来 KVM 几乎没有明显性能削弱。也考虑过在 macOS 上跑 QEMU，但原版 QEMU 似乎有网卡问题，需要用修改版 UTM，使用机会不多。

2021 年左右，笔记本领域终于突破近十年的 4 核世代，买了 AMD 5800H 新笔记本，老笔记本退役。玩了多年服务器，终于有一台属于自己的服务器。按惯性一直用 Ubuntu，公司服务器也是 Ubuntu，为操作方便还装了桌面版。顺手用 libvirt 部署 OpenWrt。部署前觉得这事很冒险：一台电脑怎么能在虚拟机里跑路由器，再给宿主机分配网络？查了很多资料，甚至考虑过简单点做旁路由。但硬着头皮走单软路由方案，把本地网络桥接后分配给虚拟机，一切顺利跑起来。那种感觉像走过一个摇摇欲坠的崖壁，预想过各种危险，结果如履平地。

之后搭文件共享、开发测试机，乱乱的，需要什么装什么。后来 OpenWrt 21 上一些代理软件停止更新，需要升级到 OpenWrt 23，sing-box 还需要 immortalwrt 变体。由此听说 Proxmox VE 和 LXC。之前只知道 Docker 这种 container，没接触过 LXC；试了之后立刻喜欢上：极致轻量，只做用户空间隔离。VM 只能共享 CPU 资源，而 LXC 内存、磁盘等都共享，避免 VM 预分配后即使没用到仍占资源。查 LXC 时知道了 Incus。

要迁移到全新平台，但旧笔记本一直当服务器用着，不能拿主力机装，也不想虚拟机套虚拟机。于是掏了一个准系统，配置不高，但跑虚拟机和容器够了。尝试 PVE 和 Incus：Incus 跑在 Debian 上，VPS 经验告诉我 Debian 内存和磁盘占用比 Ubuntu 低。PVE 涉及知识太多，有些没吃透就不敢用，可能是生产运维惯性带来的抗拒；Incus 更直观。最终选择 Incus。

从 libvirt 重构到 Linux container，目标是最大化硬盘和内存利用。libvirt 是 KVM 虚拟化，内存和硬盘预分配，无法在需求不多时与其他虚拟机共享。PVE 对 container 仍要预分配 image 文件，不能轻松与宿主机共享文件系统。切换 Incus 不需要重构系统，只是顺便在重构系统时把这些都做了。

2024/10：初步尝试 Incus 搭建 OpenWrt 成功分配 IP 并登录 OpenWrt，可行性验证成功。做法：装 Debian 纯净系统，宿主机最好两个网卡，安装 Netplan，分别绑定 br-wan、br-lan；视情况开启 DHCP，br-lan 需要 DHCP。测试 Incus LXC 里 OpenWrt 可正确分配 IP，上网正常。

2026/05：体验 Apple Silicon 后，觉得服务器用 macOS 跑也不是不行。统一内存有优势，也许以后能跑轻量大模型，待机功耗也可能比现在 20W 笔记本低。搜索发现主流是 Lima 维护虚拟化；想用 Incus，建议先开 Lima VM，再在里面跑 Incus，最大化资源共享。简单尝试 Lima VM 跑 Debian，效率可以；兼容 x86 转义运行很慢，CPU 降约 1/3，内存性能降更多，几乎不可用。Lima 还有部分转义运行方式，尚未尝试。

2026/11：捡到 256G 固态，比服务器上的 128G 大，准备换盘，顺便升级宿主系统和 OpenWrt。原宿主 Ubuntu 22.04 接近标准支持尾声，换 Debian 资源占用更少。OpenWrt 从 23 升级到 25，也是代理软件在老版本停止更新。

---

三、踩坑记录（日志原样保留版）

1. 网络、DNS 与防火墙日志

1.1 容器内找不到 ufw 日志

现象：在 container 里没有找到 ufw 的日志。虽然这种场景比较少，但仍然觉得缺少一些安全性。

排查：一开始以为是 ufw 的问题，后来安装了 firewalld 也一样。经过研究发现是 netfilter 的问题：netfilter 默认只能往 kernel 发日志；如果需要把日志放在别处，需要 ulogd 支持。目前还没有太多资料指示 ufw、firewalld 如何跟 ulogd 配置，只有原始的 iptables 可以配合。

结论：不是 ufw 单独的问题；需要 ulogd 方案，暂时没有继续深入。

1.2 Docker Compose 启动顺序

现象：尝试安排 docker compose 的启动顺序，多个独立的 compose 之间不能设置启动优先级，这点比较麻烦。

结论：多个独立 compose 之间没有原生启动优先级，需要外部脚本/编排工具处理。

1.3 局域网主机名解析失败

现象：通过主机名去访问局域网电脑，会解析不出来。看来 mihomo 不支持这个功能。

方案一：把 dnsmasq 监听 5353 端口，然后做一个 name server policy；如果是私有域名，让 mihomo 去访问 dnsmasq。这个方案可以避免网络里面的设备访问自己写死的 DNS，从而绕过代理策略。

方案二：Dnsmasq 做前置，上游服务器指向 mihomo。这样兼容性好一些。但 dnsmasq 设置里要取消其他上游请求，只导向 mihomo，不然可能 DNS 污染。

后续现象：电视盒子的 App 访问不了网络，利用 mihomo debug log 也看不出蹊跷；一旦关掉 mihomo，一切又正常。后来尝试继续用 dnsmasq 做前置，上游服务器指向 mihomo，解决问题。

1.4 x86 测试机 eth 被 169.254.x.x 污染

原文现象：在 x86 测试机上又遇到新的问题，就是好多 eth 会被 169.256.x.x 给污染了，查资料没有任何进展，又卡了好久，主要是被污染了之后路由会出现问题。

排查：反复对比配置文件，另外两个机器都没有出现这个问题。后来从日志里面发现似乎 avahi 分配了这些 IP 地址，可是又禁用不掉；再追查，似乎 connman 也会管理这些 IP 地址。禁用之后，一切正常了。

结论：connman 是 lxde 桌面环境安装的，问题根源是这里。

1.5 Ubuntu 迁移后 OpenWrt container 代理失效

现象：从老 Ubuntu 22.04 迁移运行在 Incus 的 OpenWrt 到新 Debian 13 上，起初一切良好，能分配 IP 地址，客户端也能访问网络，但是发现代理似乎没起作用。去 mihomo 检查，日志如下：

[App] Enabled.
[App] Start.
[Profile] Use file: profile.yml.
[Mixin] Mixin config.
[Profile] Checking...
[Profile] Check passed.
[Profile] Testing...
[Profile] Test passed.
[Core] Start.
[Proxy] Enabled.
[Proxy] Waiting for tun device online within 30 seconds...
[Proxy] TUN device is online.
[Proxy] Hijack failed.
[App] Exit.

宿主机 log 里面也会出现相关日志：

sysctl monitor bpf return error，invalid argument

AI 给出的资料是安装包缺失或者内核模块的问题。经过几番沟通尝试仍然无法修复，最后放弃使用 container 运行 OpenWrt，决定使用 KVM 去运行 OpenWrt。目前猜测结果可能是内核问题，因为 LXC 和宿主机共享内核。

---

2. Incus 与 OpenWrt 容器相关

2.1 导入 immortalwrt rootfs

操作：尝试导入 immortalwrt，首先需要编辑 metadata.yml。可以用以下命令和官方文档获取文件格式：

incus config metadata show test-openwrt

参考：https://linuxcontainers.org/incus/docs/main/reference/image_format/#metadatuu

文件可以从 immortalwrt 下载 rootfs，目前没用出不同 rootfs 的区别。

导入命令示例：

incus image import incus.tar.xz rootfs.squashfs --alias mycontainerimage

输出：

Image imported with fingerprint: 009349195858651a0f883de804e64eb82e0ac8c0bc51880

2.2 启动后没有 IP 和 mount /dev/log 问题

现象：系统启动后，没有 IP 地址分配，会遇到 mount /dev/log 之类的问题。

处理：需要给 container 分配 nesting 权限。

2.3 Dnsmasq random 权限问题

现象：遇到 Dnsmasq random 权限问题。

处理：根据 https://github.com/lxc/lxc-ci/blob/main/images/openwrt.yaml 里面的 action 对文件进行修改。之后分配 IP 地址正常，ping 外网正常。

2.4 immortalwrt opkg wget SSL 问题

参考：https://github.com/immortalwrt/immortalwrt/issues/1124

判断：应该是 openssl 依赖宿主机 /dev/ 加速问题。

2.5 homeproxy 权限问题

现象：在 container 里面安装 homeproxy，运行依然会遇到权限问题。

处理：把 homeproxy 切换成 tun 模式就可以了。

2.6 mihomo / openclash 菜单不显示

现象：homeproxy 这样是可以使用了，但是安装 mihomo 还有 openclash，都没有菜单显示出来，在 x86 还有 ARM container 上都一样。

mihomo 处理：问题是软件安装源的问题。kenzok8 提供的包有问题，去官方 GitHub 下载安装就可以正常使用。注意安装的时候内存消耗比较大，100M 内存不够用。

openclash 处理：没有显示菜单，是因为 openclash 依赖 luci-compat，但是软件包里面没有做这个依赖，所以不能自动安装，要手动安装。另外安装 openclash 需要安装 dnsmasq-full。安装之后会报和 immortalwrt 一样的错误，需要修改 dnsmasq 启动文件，把 jail 相关的地方用冒号 : 注释掉就可以运行了。

2.7 nikki 安装 wget 报 operation not permitted

现象：openwrt 内部 nikki 安装的时候需要用到 wget，会报：

operation not permitted

处理：忘记怎么修复的了，好像是一些证书相关的包没有安装，比如 ca-certificates。

2.8 ARMbian 下 XFCE 桌面

记录：在 armbian 里面用 armbian-config 安装的 xfce 桌面运行就比较稳定了，没有出现闪屏和乱码的情况。

---

3. pipenv 与 Python 环境

现象：迁移 python 项目遇到问题，想安装最新的 pipenv，只用系统 pip 会提示：

error: externally-managed-environment

处理：尝试了各种办法，不得不使用系统老版本的 pipenv。

---

4. Libvirt 相关坑与迁移到 Incus

4.1 安装 libvirt 时卡滞

现象：在安装 libvirt 的时候就感觉不对劲，在 apt 下载完软件包安装的时候，后面有明显的卡滞。我猜测可能是跟 Incus VM 起了冲突。

背景：本来很简单的把 domain.xml 文件导入 virsh 里面就可以了，因为遇到问题无法短时间解决，所以决定采用 Incus 来管理。

4.2 virsh list --all 时系统日志报错

每次进入 virsh，使用 list --all 命令的时候，系统日志就会有错误产生：

libvirtd[128607]: Unable to find 'dnsmasq' binary in $PATH: No such file or directory
libvirtd[128607]: Failed to open file '/sys/kernel/security/apparmor/profiles': Permission denied
libvirtd[128607]: Failed to read AppArmor profiles list '/sys/kernel/security/apparmor/profiles': Permission denied
libvirtd[128607]: Failed to open file '/sys/kernel/security/apparmor/profiles': Permission denied
libvirtd[128607]: Failed to read AppArmor profiles list '/sys/kernel/security/apparmor/profiles': Permission denied
libvirtd[128607]: Unable to open /dev/kvm: Permission denied

4.3 导入 Home Assistant 到 libvirt 报 qemu-bridge-helper 错误

把 homeassistant 虚拟机导入到 libvirt 里面（原来也是运行在 libvirt 里面的），先是会报这个错误：

libvirtd[182070]: /usr/lib/qemu/qemu-bridge-helper --use-vnet --br=br-lan --fd=32: failed to communicate with bridge helper: stderr=failed to parse default acl file `/etc/qemu/>
                                                  : Transport endpoint is not connected
kernel: audit: type=1400 audit(1793717765.301:2230): apparmor="DENIED" operation="open" class="file" profile="libvirtd//qemu_bridge_helper" name="/sys/devices/system/node/" pid=211096 comm="qemu-bridge-hel" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0

检查并调整 /usr/lib/qemu/qemu-bridge-helper 文件的权限还是不行，关掉 Incus 也不行。

我还重新安装了 libvirt，我甚至关掉了 apparmor，之后新的错误是：

libvirtd[1645046]: /usr/lib/qemu/qemu-bridge-helper --use-vnet --br=br-lan --fd=32: failed to communicate with bridge helper: stderr=libvirt:  error : cannot execute binary /usr/lib/qemu/qemu-bridge-helper: Permission denied
: Transport endpoint is not connected

之后我用：

apt reinstall qemu-system-common

重新安装，修复了权限问题，然后出现这些问题：

polkitd[3789]: Unregistered Authentication Agent for unix-process:1725567:3631875 (system bus name :1.140, object path /org/freedesktop/PolicyKit1/AuthenticationAgent, locale en_US.UTF-8) (disconnected from bus)
/usr/lib/qemu/qemu-bridge-helper --use-vnet --br=br-lan --fd=32: failed to communicate with bridge helper: stderr=failed to parse default acl file `/etc/qemu/bridge.conf'.
: Transport endpoint is not connected

可是这个文件就是空的啊，即使我加入了 allow all，也还是不行。

最后问题始终解决不了，不得已，把 homeassistant 交给 incus 管理。

都部署好之后，写文档的时候我以为是我之前权限没搞对，比如用户没有分配到对应的用户组里面，因为 libvirt 上次安装已经很久了，忘记有没有做除了安装之外的其他设置。不过官方文档写的非常不好，我用 AI 给的安装教程在服务器上重试了，也还是不行。

4.4 libvirt 与 Incus 的对比记录

对比了两者的开发情况，Incus 最近三个月平均每周有 150 次提交，而 libvirt 不过平均每周 10 几次，两者的版本更替节奏还是差不多，这么看 Incus 更有生命力一些。

而且 Incus 有自带 console 命令来操控还没有网络能力的虚拟机，libvirt 只能依靠第三方 VNC 来实现。

4.5 从 libvirt 迁移到 Incus 的问题

本以为有了 domain.xml 这个 libvirt 虚拟机定义文件，直接交给 AI 就能做迁移了，但是每个 AI 给出来的答案都不一致。尝试过用 incus migrate 还有 incus image import 或者 storage import，最大的问题是 Incus 需要用 /var 目录做中转，而不是直接使用到目标的 storage pool。而我现在的系统是单独分出 /var 分区，我都扩到了 40G 还是不能支撑完成这个任务。

其实整体做下来很简单：创建一个空的虚拟机，然后把 qcow2 转换成 raw，通过 device disk 挂载上，然后配置虚拟机需要的 br-lan，关闭 secureboot 就可以了。但是 AI 不能一针见血地把方案给出来，有的 AI 认为 qcow2 是被支持的，我也找不出什么官方文档，但是现实情况就是什么配置都不改变，只是做了格式转换，就可以正常运行起来了。

4.6 Incus 管理 VM 的磁盘格式限制

用 Incus 来管理最大弊端是不能使用 qcow2 格式，因此磁盘真实空间占用会很大。尝试过直接挂载 qcow2，无法引导启动。

---

5. Docker、AppArmor 与业务容器

5.1 linuxserver 镜像 s6 IPC permission 问题

现象：部署 linuxserver 打包的镜像，遇到了 s6 ipc permission 问题，找不到什么资料，然后用有权限的 lxc 也运行不起来。

后来从日志中发现，似乎跟 apparmor 有关系，但是不知道是哪里的关系。之前在另外一个 Debian 的机器上是好的，即使在宿主机上关掉也不行。

很久之后又尝试使用给 docker container 加上：

--security-opt apparmor=unconfined

发现可以解决，但是之前似乎也不行，不知道是否和宿主系统的软件更新有关系。

结论：作为 workaround 记录，根因未完全确认。

5.2 容器内运行 Docker 需要 nesting

为了使用 docker，需要把 security.nesting 设置为 true，这样内部才能运行 docker：

incus config set production security.nesting=true