Jenkins调用Shell脚本遇Permission denied错误的调试求助

这种场景我之前也碰到过好几次——明明手动用相同用户执行完全正常，Jenkins一跑就报权限拒绝，确实挺让人困惑的。结合你已经排查的用户ID没问题这一点，给你几个实用的排查方向：

1. 排查Jenkins与手动环境的变量差异 #

Jenkins运行任务时的环境变量（比如PATH、umask）和你交互式登录shell时的环境往往不一样，这很容易埋下隐患：

• 比如Shell脚本里用了相对路径调用命令，Jenkins的PATH里没包含该命令所在目录；
• 或者umask设置过严，导致脚本创建临时文件时权限不足。

解决方法：

• 在Jenkins任务的开头添加步骤打印环境变量：printenv（Shell步骤）或者在Python里打印os.environ；
• 和你手动登录后执行printenv的结果对比，找出差异项并在Jenkins中显式设置（比如添加export PATH=$PATH:/path/to/your/commands）；
• 在调用Shell脚本前执行umask 0022，确保文件创建权限足够。

2. 检查SELinux/AppArmor等系统安全模块限制 #

很多Linux系统默认启用了SELinux或AppArmor，这些安全模块会针对服务进程（比如Jenkins的java进程）做权限限制，即使用户相同，服务上下文的权限和交互式shell也不一样。比如Jenkins进程被禁止访问某个目录，或者执行某个脚本。

解决方法：

• 临时关闭SELinux测试：sudo setenforce 0，然后重新运行Jenkins任务，如果问题消失，说明是SELinux的问题；
• 永久解决的话，需要给Jenkins进程添加对应的SELinux策略（比如chcon -t httpd_sys_script_exec_t /path/to/your/script.sh，具体策略根据实际场景调整）；
• 如果是AppArmor，检查相关配置文件，允许Jenkins访问目标脚本或目录。

3. 注意Jenkins的Shell执行模式差异 #

Jenkins默认用非交互式非登录Shell执行命令，而你手动登录是交互式登录Shell，这会导致Shell加载的配置文件不同：

• 交互式登录Shell会加载.bash_profile、.profile，而非交互式Shell只加载.bashrc（甚至有些情况不加载）；
• 如果你的Shell脚本依赖了这些配置里的环境变量或别名，就会出问题。

解决方法：

• 在Jenkins的Shell步骤开头添加source ~/.bashrc或source ~/.bash_profile，手动加载配置；
• 或者用登录Shell执行命令：bash -l -c "/path/to/your/script.sh"；
• 尽量把脚本里的依赖配置改成不依赖Shell配置的绝对路径形式。

4. 检查目录的继承权限 #

虽然你确认了脚本本身有执行权限，但脚本所在的父目录链可能存在权限问题：Linux系统中，要访问一个文件，你需要对该文件所在的每一级目录都有execute（x）权限。比如/home/user/scripts/run.sh，你需要对/home、/home/user、/home/user/scripts都有x权限。

解决方法：

• 用ls -ld /path/to/script/..、ls -ld /path/to/script/../..逐级检查父目录权限；
• 确保Jenkins运行的用户对每一级目录都有x权限，必要时执行chmod +x /path/to/directory调整。

5. 检查Python调用Shell脚本的方式 #

如果Python调用Shell脚本的方式不当，也可能触发权限问题：

• 比如用subprocess.call(["run.sh"])且shell=False，但没指定脚本的绝对路径；
• 或者调用时的工作目录和手动执行时不一样，导致脚本找不到依赖文件。

解决方法：

• 在Python里调用脚本时使用绝对路径，比如subprocess.call(["/home/user/scripts/run.sh"])；
• 显式设置cwd参数指定脚本所在目录：subprocess.call(["run.sh"], cwd="/home/user/scripts")；
• 打印Python的工作目录确认：print(os.getcwd())，看是否和手动执行时一致。

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