Linux 中怎么修复 crontab 文件权限导致的执行失败-linux运维-PHP中文网

crontab执行失败的根源在于/tmp、/var/spool/cron目录权限及pam/cron.allow访问控制，需分别修复：chmod 1777 /tmp、chown root:root && chmod 700 /var/spool/cron、配置/etc/cron.allow或/etc/security/access.conf放行用户。

linux 中怎么修复 crontab 文件权限导致的执行失败

crontab 执行失败常因权限问题，但根源不只在 crontab 文件本身，而在于它依赖的几个关键路径和配置。修复重点不是“改 crontab 文件权限”，而是理清系统对临时文件、任务存储目录、用户访问控制的权限要求。

/tmp 目录权限异常

执行 crontab -e 时，系统会在 /tmp 下创建临时文件（如 /tmp/crontab.XXXXXX），编辑完成后复制到正式位置。若 /tmp 权限不对，就会报 Permission denied。

检查当前权限：ls -ld /tmp，正常应为 drwxrwxrwt（末位 t 表示 Sticky Bit）
若缺少写权限或无 Sticky Bit，root 用户执行：chmod 1777 /tmp
Sticky Bit（1xxx）确保只有文件所有者能删除自己在 /tmp 中创建的文件，避免跨用户干扰

/var/spool/cron 目录归属与权限

每个用户的 crontab 实际保存在 /var/spool/cron/用户名，该目录必须由 root 拥有且仅 root 可写。

PyCharm 2026.2.0.1 Linux版

PyCharm 2026.2.0.1 Linux版提供 JetBrains 官方 2026.2.0.1 版本安装包，适合需要指定 PyCharm 版本进行 Python 项目开发、运行和调试的用户。

下载

确认目录权限：ls -ld /var/spool/cron，应为 drwx------. 2 root root
若权限宽松（如 755）或属主非 root，运行：chown root:root /var/spool/cron && chmod 700 /var/spool/cron
普通用户无法直接修改该目录下文件，crontab 命令通过 setuid 机制提权写入，因此不能开放写权限给其他用户

用户 crontab 访问权限控制

即使文件系统权限正确，用户仍可能被系统策略拒绝使用 crontab，常见于 cron.allow 或 cron.deny 配置。

先查白名单：cat /etc/cron.allow —— 若存在且不含你的用户名，你就没权限
再查黑名单：cat /etc/cron.deny —— 若存在且含你的用户名，也会被拒
典型修复：root 运行 echo "username" >> /etc/cron.allow（若文件不存在则先创建），并确保该用户未出现在 cron.deny 中