VS Code远程容器(Ubuntu) /dev/null权限拒绝致Server安装失败

• 原有正常开发链路：通过VS Code Remote Containers能力，基于自定义Ubuntu镜像构建开发环境，搭配Dockerfile、docker-compose完成编排（同步启动MongoDB容器配套服务），此前全流程运行稳定
• 异常触发场景：间隔1个多月未启动远程容器集群，升级至最新正式版VS Code后，在Apple Silicon M1、Intel架构的两台MacBook Pro上复现完全一致的故障
• 核心故障表现：
  • 所有容器（含Ubuntu开发容器、MongoDB容器）可通过docker命令正常启动、运行，基础进程无异常
  • VS Code 远程服务端（Server）安装流程直接中断，核心报错为/dev/null: Permission denied
  • 手动通过docker exec进入运行中的开发容器后，容器内zsh终端会持续输出大量/dev/null权限拒绝报错
  • 自行排查4天未定位根因，已留存全量调试材料：remoteContainers运行日志、devcontainer.json配置、docker-compose.yml编排配置、Dockerfile镜像构建配置

该故障无跨架构兼容性问题，是两层版本变更叠加触发的权限冲突：

1. Docker Desktop 安全策略变更
   近期全平台Docker Desktop版本更新后，对容器内挂载的字符/块设备权限校验逻辑做了调整：如果compose配置或启动参数中，显式将宿主机的/dev/null挂载到容器内的/dev/null路径，挂载后的容器内对应文件权限位会被强制设置为000（无任何读写执行权限），挂载层的优先级高于镜像层配置，会直接覆盖Dockerfile中提前设置的/dev/null正确权限。
2. VS Code Server 流程的强依赖特性
   新版VS Code远程服务端的安装脚本，在初始化阶段会频繁调用对/dev/null的读写操作（用于重定向无关日志、屏蔽进程输出），一旦该路径无读写权限，脚本会直接抛出错误中断安装；即便不触发服务端安装流程，容器内shell的初始化脚本（zsh启动配置、各类插件初始化逻辑）只要执行对/dev/null的重定向操作，就会持续输出权限报错。

• 第一步：移除冗余错误挂载配置
  逐行检查docker-compose.yml、VS Code容器附加启动参数，删除所有针对/dev/null的显式挂载项。Docker运行时默认会为每个容器分配权限为0666、属主为root的标准/dev/null设备文件，无需手动挂载宿主机路径的对应文件。
  可通过docker inspect <运行中容器ID>查看挂载列表，若存在挂载源为宿主机路径/dev/null的配置，即为核心问题点。
• 第二步：快速修复已启动容器的权限
  对已经启动、无法直接调整挂载配置的容器，可通过宿主机侧命令直接修正/dev/null的权限：

  无需进入容器交互环境，命令执行完成即生效：
  docker exec --privileged <容器ID> bash -c "rm -f /dev/null && mknod -m 666 /dev/null c 1 3"
  验证方式：进入容器后执行echo test > /dev/null，若无报错即代表权限恢复正常，此时重启VS Code远程连接，服务端即可正常完成安装。

• 第三步：配置长期稳定的兼容规则
  重建开发镜像时，可在Dockerfile末尾补充权限修正逻辑，避免后续配置变更再次触发问题：

  # 修正dev目录设备权限，避免被错误挂载覆盖导致/dev/null访问异常
  RUN if [ -e /dev/null ]; then chmod 666 /dev/null; fi
  

• 注意事项：
  无需为解决该问题给容器配置全量--privileged特权启动参数，这会绕过Docker的多层安全隔离，仅需针对/dev/null路径做最小权限修正即可。

内容的提问来源于stack exchange，提问作者Jeremy M