Docker部署Tomcat 9-jre11容器启动失败：无法找到/usr/local/tomcat/bin/setclasspath.sh

我之前也碰到过类似的诡异问题，运行tomcat:9-jre11镜像时容器一启动就报Cannot find /usr/local/tomcat/bin/setclasspath.sh This file is needed to run this program然后崩溃。虽然通过Rancher改入口为/bin/bash进去后，明明能看到这个文件存在，甚至把权限拉满到777、调整所有者、给整个bin目录开权限都没用，catalina.sh里的-r检测就是返回false，当前运行用户还是root，这属实让人摸不着头脑。

下面是我总结的几个排查方向和解决方案，你可以逐一试试：

1. 先确认CATALINA_HOME环境变量是否正常 #

有时候容器启动时这个变量可能没正确设置，或者被其他配置篡改了。进入容器后先执行：

echo $CATALINA_HOME

如果输出不是/usr/local/tomcat，那就是问题根源了。你可以在启动容器时显式指定这个环境变量：

docker run -e CATALINA_HOME=/usr/local/tomcat tomcat:9-jre11

或者在Rancher的容器配置里添加环境变量CATALINA_HOME=/usr/local/tomcat，强制指定正确的路径。

2. 检查主机SELinux是否限制了容器权限 #

如果你的宿主机开启了SELinux，哪怕容器内文件权限设为777，SELinux的上下文标签也可能阻止Tomcat读取文件。可以临时关闭SELinux测试：

setenforce 0

重启容器后如果问题解决，就需要给容器添加SELinux权限标签，或者调整镜像的SELinux上下文（比如用chcon命令修改文件标签）。

3. 排查脚本的换行符/编码问题 #

有时候镜像里的shell脚本如果带有Windows风格的CRLF换行符，bash执行时会出现异常判断。你可以检查文件的换行符类型：

file /usr/local/tomcat/bin/catalina.sh
file /usr/local/tomcat/bin/setclasspath.sh

如果输出里有CRLF字样，说明是换行符问题，用dos2unix转换一下：

dos2unix /usr/local/tomcat/bin/catalina.sh /usr/local/tomcat/bin/setclasspath.sh

转换完后手动执行./catalina.sh start试试能不能正常启动。

4. 检查是否有挂载卷覆盖了bin目录 #

如果你启动容器时挂载了本地目录到/usr/local/tomcat/bin，可能把镜像里原有的文件覆盖了，导致实际运行时文件异常。看看你的容器启动命令或者Rancher配置里有没有相关挂载，暂时移除挂载再测试容器启动。

5. 尝试重新拉取镜像 #

有可能你本地的tomcat:9-jre11镜像损坏了，文件系统出现了隐性异常。直接重新拉取镜像再启动：

docker pull tomcat:9-jre11

用新拉取的镜像启动容器，说不定问题就解决了。

额外的调试小技巧 #

你可以修改catalina.sh脚本，在那个判断分支前加一些调试输出，帮你定位到底哪里出问题：

echo "Current running user: $(whoami)"
echo "CATALINA_HOME is set to: $CATALINA_HOME"
echo "Target file path: $CATALINA_HOME/bin/setclasspath.sh"
ls -ld "$CATALINA_HOME/bin"
ls -l "$CATALINA_HOME/bin/setclasspath.sh"
test -r "$CATALINA_HOME/bin/setclasspath.sh" && echo "✅ File is readable" || echo "❌ File NOT readable"
test -f "$CATALINA_HOME/bin/setclasspath.sh" && echo "✅ File exists" || echo "❌ File NOT exists"

添加完这些后启动容器，就能看到更详细的状态信息，帮你精准定位问题点。

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