容器起不来

适用范围

点 Start 后容器任务失败，或者容器状态一直停在 stopped。

不适用于容器能启动、但挂载点写入被拒绝的情况，那类问题见挂载点权限被拒绝。

记录：这个容器是新建的还是一直在用的？最近有没有改过 Features（Nesting、FUSE 等）、改过 lxc.idmap、换过模板、升级过宿主机内核？这些信息决定了从哪个方向查起。

pct start <ctid>

Web UI 的提示通常只有一行，命令行会给出更完整的错误。还不够详细时，加上调试日志：

lxc-start -n <ctid> -F -l DEBUG -o /tmp/lxc-<ctid>.log
cat /tmp/lxc-<ctid>.log
journalctl -u pve-container@<ctid> -n 100 --no-pager

报错/现象	大概率原因	下一步
`newuidmap`、`subuid`、权限相关	UID 映射或 `/etc/subuid`、`/etc/subgid` 配置有问题	见第三步
cgroup 相关（`cgroup`、`mount cgroup` 失败）	模板与宿主机内核的 cgroup 版本不匹配	见第四步
存储相关（`no such logical volume`、找不到 rootfs）	容器的根文件系统所在存储异常	`pvesm status` 确认，处理方式同虚拟机开不了机里存储部分
`unable to acquire lock`	容器被锁定	确认对应任务（备份、克隆等）已结束后 `pct unlock <ctid>`，判断方法同虚拟机被锁定
与 Nesting/FUSE 等 Feature 相关	开启的 Feature 和当前内核或容器类型不兼容	见第五步

非特权容器的 root（容器内 UID 0）默认映射到宿主机的 UID 100000。如果 /etc/subuid、/etc/subgid 里没有给 root 用户授权足够的 ID 段，或者容器配置里的自定义 lxc.idmap 写错了，容器会直接启动失败。

# 确认宿主机授权的 ID 段
grep root /etc/subuid /etc/subgid

# 查看容器是否有自定义 idmap
cat /etc/pve/lxc/<ctid>.conf | grep -E 'idmap|unprivileged'

改过自定义 idmap 之后起不来，最快的恢复方式是先还原成改动前的配置文件（如果有备份），再慢慢调整。详细的映射原理和常见坑见特权与非特权容器。

老的容器模板（尤其是几年前制作的）在较新的内核上可能因为 cgroup v1/v2 的差异启动失败。

处理方向：换用较新的官方模板重新创建容器，而不是在旧模板上反复调整宿主机的 cgroup 挂载方式——后者绕开了根因，且容易在下次升级时又出问题。

pct config <ctid> | grep features

nesting、fuse、mount、keyctl 等选项如果和容器内运行的软件版本或宿主机内核不兼容，可能表现为启动失败而不是运行时报错。逐个排除时，先关闭非必需的选项测试能否启动，确认是哪一项导致后，再评估这个功能是否真的需要（用途和风险取舍见特权与非特权容器）。

如果容器里跑的是 Docker，一部分启动失败和这里的 Feature 组合有关，具体取舍见在 LXC 里跑 Docker。

按如何有效求助准备信息，至少包括：

pveversion -v
pct config <ctid>

加上 pct start <ctid> 的完整报错、journalctl -u pve-container@<ctid> 的相关片段，以及容器使用的模板名称和版本。