rsync 配合 cron 定时备份遇到权限报错？这篇帮你排查并解决

最近在捣鼓服务器自动化运维，想搞一个自动备份的脚本，很多人第一反应就是用 rsync 配合 cron。这俩搭档确实是 Linux 下的黄金组合，简单高效，但真上手的时候，往往会被接踵而至的“Permission denied”劝退。

既然是写脚本自动跑，最常见的问题其实不在 rsync 本身，而在于 cron 的运行环境和你手动敲命令的环境不一样。这就导致了你手动执行一切 OK，一到 cron 定时任务执行就报错。今天就来聊聊怎么排查并解决这种隐形的权限坑。

首先，最基础的问题：你的 crontab 是在哪个用户下配置的？

检查当前用户身份命令示例

检查执行用户身份

如果你是用 root 用户的 crontab -e 配置的任务，那还好办。但如果是普通用户（比如 www 或 backup），在执行脚本时，该用户必须对源目录有读权限，对目标目录有写权限。

排查方法： 在脚本里加一行日志，记录当前执行的用户是谁：

echo "Running as $(whoami)" >> /var/log/backup.log

如果发现用户不对，记得检查 /etc/crontab 和 crontab -e 的区别，前者可以指定用户，后者则是当前登录用户。

cron 执行任务时，默认的环境变量非常少，它不会自动加载你在 .bashrc 或 .profile 里设置的 PATH。

这导致什么问题？如果你的脚本里直接写 rsync -avz ...，cron 可能根本找不到 rsync 命令在哪里，或者找不到脚本里引用的相对路径文件。

解决方法：

脚本开头加上 SHELL=/bin/bash 和 PATH=/usr/bin:/bin:/usr/local/bin（根据你实际的 rsync 路径调整）。
脚本中所有涉及路径的地方，全部使用绝对路径。比如 /home/user/data 而不是 ./data。
或者在脚本执行前先 source 一下环境变量（不推荐，容易引入其他问题）。

如果你的备份目标是一台远程服务器，rsync 通常会走 SSH 协议。这时候，权限问题通常指向 SSH Key（私钥）。

手动执行成功是因为 SSH 默认会尝试使用当前用户 ~/.ssh/id_rsa 下的私钥。但 cron 在执行时，可能因为环境变量丢失（特别是 HOME 变量），导致找不到私钥文件。

解决方法： 在 rsync 命令中显式指定私钥路径：

rsync -avz -e "ssh -i /home/your_user/.ssh/backup_key" /source/ user@remote:/dest/

同时，确保该私钥文件的权限是 600（即只有所有者可读写），SSH 协议对私钥权限检查非常严格，权限过大会直接拒绝连接。

如果确认用户和路径都没问题，还是报错，那就得检查一下是不是 SELinux 在搞鬼（CentOS/RedHat 系常见）。SELinux 的强制访问控制可能会阻止 Cron 任务访问某些目录。

临时排查： 可以先 setenforce 0 关闭 SELinux 试试，如果关了就好了，那就是策略问题。正确做法不是一直关闭，而是使用 chcon 或 audit2allow 来调整文件上下文。

另外，检查一下是否有 ACL（访问控制列表）限制，使用 getfacl 命令查看一下目录是否针对特定用户做了限制。

折腾脚本遇到报错很正常，尤其是 cron 这种“静默执行”的工具，报错了往往无处投诉。养成在脚本里加日志（tee 或重定向到文件）的习惯，能帮你节省大量的排错时间。希望这几个方法能帮你把自动备份顺利跑起来！