Linux Crontab Permission Denied — Cron Job Not Running Fix

What Does This Error Mean?

A crontab permission denied error means your user account is not allowed to use cron, or the script your cron job is trying to run does not have execute permission. Cron jobs also commonly fail silently because the environment they run in is much more limited than your normal shell — missing PATH variables mean commands that work in your terminal simply are not found by cron. Checking file permissions and using full paths in your cron commands fixes most issues.

Affected Models

Ubuntu
Debian
Fedora
CentOS
Arch Linux
Rocky Linux
RHEL

Common Causes

The script being executed by cron does not have execute permissions (chmod +x not set)
The user account is listed in /etc/cron.deny, which prevents that user from using crontab
The cron job uses commands that are not in cron's default PATH environment
The script path in the crontab entry is wrong — cron is looking for the file in the wrong location
SELinux or AppArmor policy is blocking the script from executing or accessing resources

How to Fix It

Check that the script has execute permission. Run: ls -la /path/to/your/script.sh — if the permissions do not include 'x' (for example, -rw-r--r--), add execute permission: chmod +x /path/to/your/script.sh.

Cron will silently fail if the script is not executable. The cron job appears to run but nothing happens.
Use full paths for all commands in your script and crontab entry. Instead of: backup.sh — use: /home/user/scripts/backup.sh. Inside scripts, use full paths like /usr/bin/python3 instead of python3.

Cron runs with a minimal PATH that does not include /usr/local/bin or your user's local paths. Commands that work in your terminal fail in cron because cron cannot find them.
Check if your user is blocked by cron.deny. Run: cat /etc/cron.deny — if your username appears in this file, remove it (as root) or ask your system administrator to remove it.

Alternatively, check /etc/cron.allow — if this file exists and your username is NOT in it, you are also blocked. Add your username to cron.allow.
Redirect cron job output to a log file to see errors. Edit your crontab (crontab -e) and change your entry to: */5 * * * * /path/to/script.sh >> /tmp/myjob.log 2>&1 — the 2>&1 redirects both standard output and errors to the log file.

By default, cron sends output by email to the local system mail. Most modern Linux systems do not have a mail server configured, so errors are silently lost. Redirecting to a file lets you actually read them.
Verify the cron service itself is running. Run: sudo systemctl status cron (on Debian/Ubuntu) or: sudo systemctl status crond (on Fedora/CentOS). If it shows inactive or failed, start it: sudo systemctl start cron and enable it: sudo systemctl enable cron.

On some minimal server installations, the cron service is not installed or enabled by default. Install it with: sudo apt install cron on Debian/Ubuntu.

When to Call a Professional

Crontab issues are almost always fixable by non-experts using the steps below. SELinux-related cron failures are more complex and may benefit from a Linux administrator on production servers.

Frequently Asked Questions

My cron job runs fine when I test it manually but does not work when cron runs it. Why?

This is the most classic cron problem and it is always caused by the environment difference. When you run a script manually in your terminal, you have your full PATH, environment variables, and shell settings loaded from your .bashrc or .profile. Cron starts with a minimal environment — only PATH=/usr/bin:/bin is set by default. The fix is either to add the full PATH at the top of your crontab (PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin) or to use absolute paths for every command in your scripts.

How do I test a cron job without waiting for the schedule?

The quickest way is to run the exact same command that is in your crontab directly in a terminal. If that works, edit the crontab to run it every minute temporarily: * * * * * /path/to/script.sh >> /tmp/test.log 2>&1 — wait 2 minutes, then check the log file. This tells you both whether cron is executing the job and what output or errors it produces. Remember to change the schedule back after testing.

What is the format of a crontab entry?

Each crontab line has five time fields followed by the command: minute (0-59) — hour (0-23) — day of month (1-31) — month (1-12) — day of week (0-7, both 0 and 7 mean Sunday). For example: 30 2 * * * /path/to/script.sh runs at 2:30 AM every day. Asterisks mean 'every'. So * * * * * means every minute. The website crontab.guru is an excellent tool for building and testing crontab schedules visually.