namespaces未启用是docker启动失败的主因，需通过grep检查config_namespaces=y、unshare命令验证及/proc/sys/user/max_user_namespaces值确认。
检查 namespaces 内核特性是否启用
宝塔面板里点“Docker管理”提示启动失败，大概率是内核没开启 namespaces —— 这不是 Docker 自己的问题，而是底层 Linux 内核没编译进这个基础能力。CentOS 7 默认内核（比如 3.10.0-1160）虽然支持，但某些精简版镜像或 OpenVZ/Virtuozzo 虚拟化环境会直接阉掉。
- 执行
grep -q '^CONFIG_NAMESPACES=y' /boot/config-$(uname -r)，返回 0 才算启用；如果报错或无输出，说明没开 - OpenVZ 宿主机上跑的 VPS 基本不可能有
namespaces，这种环境下装 Docker 就是白忙活 - 阿里云/腾讯云的 CentOS 7 镜像一般没问题，但如果你用的是第三方提供的“最小化 ISO”，得自己确认内核配置
验证 unshare 命令能否运行
unshare 是最轻量的命名空间功能验证方式，比跑完整 Docker 更直接。它不依赖 Docker daemon，只靠内核支持就能测出核心能力是否就位。
- 运行
unshare --user --pid echo ok，如果输出ok，说明用户命名空间和 PID 命名空间都正常 - 如果报错
unshare: unshare failed: Invalid argument或Operation not permitted，基本锁定是内核不支持或被禁用 - 部分系统（如某些 CloudLinux）会通过
grsecurity补丁禁用命名空间，即使内核配置开着也没用
排查 /proc/sys/user/max_user_namespaces 限制
有些内核虽然编译了命名空间，但默认把用户命名空间关掉了，表现为 unshare 报 Operation not permitted，而 grep CONFIG_USER_NS /boot/config-* 显示是 y。
- 检查
cat /proc/sys/user/max_user_namespaces，如果是0，说明被显式禁用了 - 临时开启：运行
echo 10000 > /proc/sys/user/max_user_namespaces - 永久生效需在
/etc/sysctl.conf加一行user.max_user_namespaces = 10000，再执行sysctl -p - 注意：这个值设太高可能引发安全策略拦截，尤其在启用了 SELinux 或 grsecurity 的系统上
Docker 启动失败时看 journalctl -u docker 的关键错误行
别只盯着宝塔界面那句“启动失败”，真正线索藏在 systemd 日志里。Docker daemon 启动时第一件事就是检测命名空间，卡在这步就会立刻退出。
- 运行
journalctl -u docker --since "1 hour ago" | grep -i "namespace\|unshare\|not supported" - 常见错误：
failed to start daemon: Namespaces are not enabled on this system或error initializing graphdriver: driver not supported（后者常因 overlay2 依赖命名空间） - 如果看到
overlay相关报错，先别急着换devicemapper，优先确认命名空间是否就绪——否则换啥驱动都没用 - 日志里出现
cannot enable tty mode on non-tty input这类是干扰项，和命名空间无关，不用管
内核命名空间不是开关按钮，它是整个容器运行时的地基。很多问题表面看是 Docker 配置或宝塔插件异常，实际一查 unshare 就露馅。尤其是用非官方镜像、小厂 VPS 或旧版系统时，先验 CONFIG_NAMESPACES 和 max_user_namespaces，能省掉后面所有无效操作。
