惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

小众软件
小众软件
博客园 - Franky
罗磊的独立博客
G
Google Developers Blog
The GitHub Blog
The GitHub Blog
P
Proofpoint News Feed
Recent Announcements
Recent Announcements
V
V2EX
F
Fortinet All Blogs
阮一峰的网络日志
阮一峰的网络日志
Blog — PlanetScale
Blog — PlanetScale
月光博客
月光博客
U
Unit 42
GbyAI
GbyAI
A
About on SuperTechFans
WordPress大学
WordPress大学
Engineering at Meta
Engineering at Meta
雷峰网
雷峰网
Microsoft Azure Blog
Microsoft Azure Blog
Martin Fowler
Martin Fowler
D
DataBreaches.Net
The Cloudflare Blog
H
Hackread – Cybersecurity News, Data Breaches, AI and More
MongoDB | Blog
MongoDB | Blog

See you soon

哟,好久不见,无线打印 | See you soon 试试将文章版本化管理吧 | See you soon 使用 Quadlet 将 Podman 中的 Postgres 当作 systemd 服务运行 | See you soon 大他者,那个无时无刻都在盯着你的东西 | See you soon Laws of Software Engineering,软件工程定律 | See you soon 浅记多因素身份认证 | See you soon Linux 内核中的度量单位 | See you soon 重置 GPG 智能密钥 | See you soon 向 NAS 引入 samba | See you soon 无法重复键入的 Fcitx5 | See you soon ZFS 降级事故 | See you soon agent 的 skill 与 toolcall | See you soon 记一次服务器被挂恶意挖矿二进制 | See you soon 活着的 Arc | See you soon 令 acme.sh 使用 Cloudflare 的 DNS API 签发与续签证书 | See you soon 于 Tokio 中卸载 CPU Bound 任务 | See you soon 如我所见,梦破碎的时候 | See you soon 74LS 家族手册 | See you soon JDK Projects 备忘录 | See you soon 关于历史 | See you soon 用 curl 下载 OnePlus 的 ROM | See you soon 实用命令切片 | See you soon 再见,Oh My Zsh。 | See you soon 你不应该复用 strings.Builder | See you soon 博客的明日 | See you soon 被 AppArmor 击杀的 Dockge | See you soon AI 时代的自我 | See you soon 支持删除的布隆过滤器 | See you soon 基于栈的虚拟机与基于寄存器的虚拟机 | See you soon RVA23 包含了什么 | See you soon
记被 XanMod Kernel 和 AppArmor 联合坑的一次踩坑 | See you...
Krysztal Huang · 2026-03-17 · via See you soon

排查了下自己的 NAS 上 immich 为什么突然没办法拉起。

immich 排障记录

podman 给了如下的报错信息:

profile "containers-default-0.64.2" specified but AppArmor is disabled on the host

嗯。。。看起来是 AppArmor 被关掉了导致的,但是在此之前 podman 是正常运行的。

当时运行的是 6.18.16-x64v3-xanmod1podman info 显示 apparmorEnabled=false,而容器启动时被分配了默认的 AppArmor profile,因此报错:

进一步检查发现,机器虽然安装了 AppArmor 用户态包,内核也编译了 AppArmor 支持,但当前启动出来的 LSM 链里没有 apparmor,所以宿主机实际上处于 AppArmor 未启用状态。这导致 podman 创建出的 immich 容器可以生成,但在启动阶段失败。

检查了一下 LSM 的情况:

cat /sys/kernel/security/lsm

capability,landlock,lockdown,yama,bpf

我的 NAS 里的系统内核是 XanMod,考虑到可能是内核编译参数导致的问题,因此把系统切回 Debian 提供的内核。

完成后,运行内核变成 6.19.6+deb14-amd64,这时 apparmorEnabled=true,说明 AppArmor 问题已经消失。所以初步结论是,LSM 链里的 apparmor 没有正常工作。

现在容器已经可以正常启动,说明 Debian 的官方内核是没有问题的。

随后又检查了服务器在切回 Debian 内核之后的 LSM 工作状态:当前运行内核是 6.19.6+deb14-amd64/sys/kernel/security/lsm 显示当前启用的 LSM 链为:

cat /sys/kernel/security/lsm

lockdown,capability,landlock,yama,apparmor,tomoyo,bpf,ipe,ima,evm

确定了 apparmor 已经在链上,而且状态正常:

  • /sys/module/apparmor/parameters/enabledY
  • podman info 显示 apparmorEnabled=true

检查一下 aa-status 命令的情况

aa-status | rg container

containers-default-0.64.2

containers-default-0.66.0

/usr/local/bin/valkey-server (115513) containers-default-0.64.2

/usr/lib/postgresql/14/bin/postgres (115655) containers-default-0.64.2

/usr/lib/postgresql/14/bin/postgres (116222) containers-default-0.64.2

/usr/lib/postgresql/14/bin/postgres (116278) containers-default-0.64.2

/usr/lib/postgresql/14/bin/postgres (116279) containers-default-0.64.2

/usr/lib/postgresql/14/bin/postgres (116280) containers-default-0.64.2

/usr/lib/postgresql/14/bin/postgres (116282) containers-default-0.64.2

/usr/lib/postgresql/14/bin/postgres (116283) containers-default-0.64.2

/usr/lib/postgresql/14/bin/postgres (116284) containers-default-0.64.2

/usr/lib/postgresql/14/bin/postgres (119091) containers-default-0.64.2

/usr/lib/postgresql/14/bin/postgres (119092) containers-default-0.64.2

/usr/lib/postgresql/14/bin/postgres (119093) containers-default-0.64.2

/usr/lib/postgresql/14/bin/postgres (119094) containers-default-0.64.2

/usr/lib/postgresql/14/bin/postgres (119098) containers-default-0.64.2

/usr/lib/postgresql/14/bin/postgres (119099) containers-default-0.64.2

/usr/bin/tini (115612) containers-default-0.66.0

/usr/local/bin/python3.11 (115681) containers-default-0.66.0

/usr/bin/tini (116011) containers-default-0.66.0

/usr/local/bin/node (116047) containers-default-0.66.0

/usr/local/bin/python3.11 (116546) containers-default-0.66.0

/usr/local/bin/python3.11 (116788) containers-default-0.66.0

/usr/local/bin/node (118708) containers-default-0.66.0

其中容器相关的 containers-default-0.64.2containers-default-0.66.0 profile 都已经加载。起码现在看起来是工作正常的。

这说明现在服务器的 LSM 尤其是 AppArmor 已经工作正常,podman 容器也能够正常使用 AppArmor profile,不再是之前那种宿主机未启用 AppArmor 导致容器启动失败的状态。

本机 XanMod 内核下的 LSM 检查

顺手也检查了本机的 LSM 状态。本机运行的是 6.9.12-x64v4-xanmod1,和刚才服务器之前使用的 XanMod 不是同一颗内核,但同属于 Xanmod 内核发行版。

当前本机的 /sys/kernel/security/lsm 内容为:

❯ cat /sys/kernel/security/lsm

lockdown,capability,landlock,yama,apparmor,ima,evm

同时 /sys/module/apparmor/parameters/enabledY,说明本机这颗 XanMod 内核下 AppArmor 是正常启用的。

内核配置里也能看到:

  • CONFIG_SECURITY_APPARMOR=y
  • CONFIG_DEFAULT_SECURITY_APPARMOR=y
  • CONFIG_LSM="landlock,lockdown,yama,integrity,apparmor"

不知道因为什么原因导致 XanMod 没有正常启用 AppArmor,还得是 Debian 的官方源里的内核稳定。。。