Docker容器内运行Puppeteer触发Chrome沙箱权限报错问题

• 场景：在Docker容器内部署集成Puppeteer的Node应用，通过docker-compose启动服务全程无编译、启动报错，仅当调用触发Puppeteer执行逻辑的API接口时，捕获到Chrome运行报错：Running as root without --no-sandbox is not supported.
• 已完成的排查操作：
  • Dockerfile中配置了非root运行用户pptruser，调整了相关目录的权限归属
  • docker-compose配置中为容器添加SYS_ADMIN权限、启用init进程
  • 代码层面Puppeteer启动配置已添加沙箱禁用参数：puppeteer.launch({ args: ['--no-sandbox', '--disable-setuid-sandbox'] })
  • 上述操作完成后，报错仍未消失

1. 优先排查Dockerfile指令顺序与权限错位问题 #

这是当前场景下最容易触发报错的核心原因：

• 你在Dockerfile中将USER pptruser指令的位置放在文件拷贝、依赖安装操作之前，存在明显的权限错配：
  • 此前执行的chown -R pptruser:pptruser /node_modules指向的是文件系统根目录下的/node_modules，但你的工作目录是/app，实际项目依赖安装目录是/app/node_modules，这个目录的所有者始终是root，pptruser没有对应操作权限
  • 无论前面的USER指令如何设置，COPY操作在构建时默认会将所有复制进镜像的文件所有者设置为root，在切换用户后执行COPY、依赖安装操作，会进一步放大权限不匹配的问题
  • 你在前面单独执行yarn add puppeteer的操作是冗余步骤：后续流程已经包含了基于package.json的依赖安装逻辑，单独执行的操作会把puppeteer安装到和项目目录不匹配的路径下，进一步加重权限错配问题
• 修正方式：把所有需要root权限执行的文件拷贝、依赖安装、冗余指令清理操作，全部移动到USER pptruser指令之前；完成所有文件写入操作后，统一执行chown -R pptruser:pptruser /app调整项目目录的所有者为运行用户，最后再切换为pptruser身份启动应用。

2. 排查Puppeteer与Chrome可执行文件的匹配问题 #

• 你在镜像中手动安装了系统级的google-chrome-stable，但没有在Puppeteer启动配置中通过executablePath参数明确指定可执行文件路径，Puppeteer默认会优先读取自身安装时自动下载的内置Chromium二进制文件
• 由于前述权限错配，内置Chromium的用户级缓存目录权限属于root，pptruser身份无法正常读取，可能触发异常的权限逻辑，导致Chrome进程最终以root身份启动，进而触发沙箱校验报错
• 修正方式：在Puppeteer启动配置中明确指定系统Chrome的路径：executablePath: '/usr/bin/google-chrome-stable'，避免Puppeteer读取到权限异常的内置Chromium文件。

3. 排查镜像构建的残留干扰 #

• 你的Dockerfile中连续写了两个CMD指令，虽然Docker只会识别最后一个作为容器启动命令，但前面多余的CMD ["google-chrome-stable"]会产生无意义的镜像层，甚至可能触发构建缓存异常
• 可以删除多余的CMD指令，重新不带缓存构建镜像（添加--no-cache参数），避免旧的异常层残留影响运行结果。

4. 运行时身份校验 #

• 服务启动后，进入运行中的容器执行身份校验命令，确认应用进程的实际运行身份：docker exec -it web_scraping whoami
• 如果返回的用户是root，说明此前的USER指令没有生效，需要回头检查权限调整、目录归属的配置是否正确。

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