Linux容器权限问题主因是SELinux、seccomp策略或systemd-cgroups限制，非镜像或Docker安装问题；调试应先用--privileged测试，再针对性禁用seccomp、SELinux标签或调整service配置。
Linux 容器不是虚拟机，别用 KVM 的思路去配 Docker。
容器启动就报 permission denied 或 operation not permitted
这是最常卡住新手的第一关：容器进程被 SELinux 或 systemd-cgroups 限制了权限，不是镜像坏了，也不是 Docker 没装好。
- 先跑
docker run --rm -it --privileged alpine sh测试——如果这个能进，说明是普通容器权限不足，不是环境问题 - 常见罪魁是
seccomp默认策略，比如调用mount()、setns()就会被拦；加--security-opt seccomp=unconfined临时绕过（仅调试） - 在 RHEL/CentOS 上，
containerd默认启用 SELinux 标签，但镜像没打标签时会拒绝挂载；加--security-opt label=disable或用:z后缀挂载宿主机目录（如-v /data:/app:z） - systemd 系统里，
docker.service可能被RestrictSUIDSGID=true拦住 setuid 二进制（比如某些 Java 镜像里的java），得改 service 文件或换基础镜像
docker build 时 COPY 失败：no such file or directory
不是路径写错了，大概率是构建上下文（build context）和 WORKDIR 混了，或者 .dockerignore 删过头。
-
COPY只能从构建上下文目录（即docker build -f xxx .最后的那个.所指的目录）里复制文件，不能写绝对路径，也不能跨出这个目录 - 检查
.dockerignore是否误写了*、**或node_modules—— 它会把匹配文件从上下文里彻底剔除，COPY根本看不到 -
WORKDIR不影响COPY源路径，只影响目标路径；比如WORKDIR /app后写COPY app.js .，意思是“把上下文里的app.js复制到容器内当前工作目录” - 调试技巧：加个中间步骤
RUN ls -la看上下文里到底有啥，比猜快得多
容器里 ps 看不到其他进程，top 显示只有自己
这不是 bug，是 Linux 命名空间（PID namespace）的正常行为。每个容器默认运行在独立 PID namespace 里，只能看到自己 namespace 内的进程。
- 想看宿主机所有进程？启动容器时加
--pid=host，但代价是失去 PID 隔离，不推荐用于生产 - 想让多个容器共享一个 PID namespace（比如调试 sidecar 场景），用
--pid=container:<name_or_id></name_or_id> -
ps aux在容器里显示 UID 是数字而非用户名？因为/etc/passwd里没对应条目，不是权限问题，只是用户数据库没同步；id命令查 UID/GID 更可靠 - 某些精简镜像（如
scratch、distroless）压根没ps或top，别白费劲；用cat /proc/1/cmdline或ls /proc/[0-9]*/comm替代
真正难的从来不是命令怎么敲，而是搞清哪个隔离机制正在生效——cgroups v1/v2、user namespace 映射、AppArmor profile、甚至内核模块是否加载，都可能让同一行 docker run 在不同机器上表现迥异。
