Linux文件创建权限拒绝：Jenkins在SSH服务器执行脚本失败排查

遇到过一模一样的坑，给你几个逐步排查的方向，应该能定位并解决：

1. 确认Jenkins SSH任务的实际执行用户 #

有时候我们以为给Jenkins账号授权了，但实际SSH连接时用的是另一个用户。在你的脚本开头加两行调试命令：

whoami
id

执行Jenkins任务后，查看构建日志里的输出，确认显示的用户是不是你已经授予rwx权限的那个账号。如果不是，去Jenkins的SSH配置里检查“构建完成后通过SSH发送文件或执行命令”的设置，确保选择的是正确的执行用户。

2. 检查路径的完整权限链 #

不要只看目标目录的权限，从根目录到目标目录的每一层都需要有执行（x）权限——这是Linux进入目录的必要条件。比如你要在/data/backups生成文件，需要确保：

• /data目录对Jenkins用户有x权限
• /data/backups目录对Jenkins用户有rwx权限

可以用这个命令检查路径的权限链：

namei -l /data/backups

输出里每一行的权限都要允许Jenkins用户访问。

3. 改用绝对路径输出文件 #

本地执行脚本时的工作目录和Jenkins SSH执行的工作目录可能完全不同。如果你的脚本里用了相对路径（比如./a.txt），Jenkins可能会尝试在它默认的工作目录（比如/var/lib/jenkins）创建文件，而这个目录你可能没授权。

把脚本里的输出路径改成绝对路径，比如：

pg_dump -U your_db_user your_db_name > /opt/backups/a.txt

确保/opt/backups目录已经给Jenkins用户rwx权限。

4. 排查SELinux/AppArmor的限制 #

如果服务器开启了SELinux（大部分RHEL/CentOS系统默认开启），即使文件系统权限正确，SELinux的安全上下文也可能阻止Jenkins用户写入文件。

可以临时关闭SELinux测试：

setenforce 0

重新执行Jenkins任务，如果成功了，说明是SELinux的问题。接下来可以调整目标目录的SELinux上下文：

chcon -R -t httpd_sys_rw_content_t /opt/backups

或者添加自定义的SELinux规则来允许Jenkins用户写入该目录。

5. 检查脚本中的sudo使用 #

如果你的脚本里用了sudo执行pg_dump，那生成的文件可能属于root用户，后续操作a.txt时就会触发权限拒绝。

解决方法有两种：

• 给Jenkins用户配置免密sudo权限（编辑/etc/sudoers，添加jenkins ALL=(ALL) NOPASSWD: ALL，注意安全）
• 去掉sudo，直接用Jenkins用户执行pg_dump——前提是这个用户已经被授予PostgreSQL的备份权限（在PostgreSQL中执行GRANT SELECT ON ALL TABLES IN SCHEMA public TO jenkins_user;，以及GRANT CONNECT ON DATABASE your_db_name TO jenkins_user;）

6. 检查目标文件是否已存在 #

如果a.txt已经存在，并且属于其他用户（比如root），即使Jenkins用户有目录权限，也无法覆盖这个文件。

可以在脚本里先删除旧文件再生成：

rm -f /opt/backups/a.txt
pg_dump -U your_db_user your_db_name > /opt/backups/a.txt

或者用原子替换的方式避免覆盖问题：

pg_dump -U your_db_user your_db_name > /opt/backups/a.txt.tmp && mv /opt/backups/a.txt.tmp /opt/backups/a.txt

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