在Windows上执行docker commit后镜像内Python脚本通过docker run执行失败

根因分析 #

你遇到的报错本质是系统将Python脚本识别为Shell脚本执行，才会抛出from: command not found的语法错误，触发该问题的核心诱因是Windows环境下的换行符转换：

• 原始Linux环境构建的镜像中，脚本使用LF（\n）作为换行符，首行的#!/usr/bin/python3 Shebang声明可以被Linux内核正常识别，自动调用Python3解释器执行脚本。
• 在Windows环境执行docker commit操作时，容器内的文件换行符会被自动转换为Windows默认的CRLF（\r\n）格式，Shebang行末尾多了不可见的\r字符，内核会尝试寻找/usr/bin/python3\r这个不存在的解释器，找不到就会 fallback 到用Shell执行脚本，触发语法报错。
• 进入容器内部执行脚本正常的原因是：交互式Bash会自动忽略行尾的\r字符，可以正常识别Shebang声明，因此能正确调用Python解释器执行。

还有小概率场景：docker commit操作意外修改了镜像的默认ENTRYPOINT为/bin/sh，相当于直接用Shell执行Python脚本，也会触发相同报错，可以通过docker inspect newimage | grep Entrypoint命令确认该配置是否异常。

解决方案 #

临时绕过方案 #

运行容器时显式指定Python解释器执行脚本，跳过Shebang解析逻辑：

docker run newimage python3 /opt/test.py

永久修复方案 #

1. 修改换行符配置：在Windows的Docker Desktop设置中关闭「Auto CRLF conversion」功能，如果你的脚本是通过Git拉取到本地的，同时执行git config --global core.autocrlf false关闭Git的自动换行符转换，之后重新提交镜像即可。
2. 容器内预处理脚本：提交镜像前先进入运行中的容器，执行dos2unix /opt/test.py命令将脚本换行符转换为Linux格式，再执行docker commit生成新镜像即可。
3. 修复ENTRYPOINT异常：如果确认是ENTRYPOINT被意外修改，运行容器时显式覆盖即可：

docker run --entrypoint="" newimage /opt/test.py

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