Linux Crontab Permission Denied — Fix Guide

💡A crontab permission denied error means the cron process cannot execute the script or access a file it needs. The most common fixes are adding the execute bit with chmod +x, ensuring directory permissions allow the cron user to traverse the path, and using absolute paths for all commands and files.

Quick Diagnosis

If you see “permission denied in cron log for the script” → it means the script does not have the execute bit set → do this: run chmod +x /path/to/script.sh and verify with ls -la

If you see “permission denied accessing a file inside the script” → it means cron runs as a different user than you — that user lacks read access to the file → do this: check which user cron runs as (grep cron /etc/crontab) and adjust file ownership or permissions

If you see “permission denied writing to a log file” → it means the cron user cannot write to the directory specified in the redirect → do this: use /tmp/ for test logs, or adjust directory permissions with chmod and chown

If you see “cron runs as root but still gets permission denied” → it means SELinux or AppArmor policy is blocking the operation → do this: check audit log: ausearch -m avc -ts recent, then adjust policy or disable enforcement for the script

Common Fixes

Script missing execute permission

❌ Wrong

# Script exists but is not executable
ls -la /home/user/backup.sh
# -rw-r--r-- 1 user user 512 Apr 24 backup.sh

# Cron log:
# /bin/sh: /home/user/backup.sh: Permission denied

✅ Fixed

# Add execute permission
chmod +x /home/user/backup.sh

# Verify
ls -la /home/user/backup.sh
# -rwxr-xr-x 1 user user 512 Apr 24 backup.sh

Cron executes scripts via /bin/sh, which requires the execute bit. chmod +x adds it.

Cron user cannot read a directory

❌ Wrong

# Home directory permissions too restrictive
ls -ld /home/user/
# drwx------ (mode 700) — only owner can enter

# Cron running as www-data cannot read files inside

✅ Fixed

# Allow other users to traverse the directory
chmod 755 /home/user/
# Or move scripts to a shared location like /usr/local/bin/
chmod +x /usr/local/bin/myscript.sh

Other users need execute permission on each directory in the path to reach a file.

Validate Your Cron Expression

Once permissions are fixed, confirm the cron expression itself is correct by testing it online before adding it to crontab.

Open Crontab Generator →

Permission Checklist

  • ✓Script has execute bit: chmod +x /path/to/script.sh
  • ✓All directories in the path allow traversal (execute bit for cron user)
  • ✓Script file is owned by the user whose crontab it is in
  • ✓Any files the script reads are accessible to the cron user
  • ✓Any directories the script writes to are writable by the cron user
  • ✓SELinux/AppArmor: check ausearch -m avc for denial entries

Related Guides

Frequently Asked Questions

What user does cron run scripts as?

User-level crontab (crontab -e) runs jobs as that user. System-level /etc/crontab has a user field in each line. Root crontab (/var/spool/cron/root) runs as root.

How do I test if a cron permission error is a PATH issue?

Add the full absolute path to every command in the script. Use which command to find the path. Add PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin at the top of the crontab.

Can SELinux cause crontab permission denied?

Yes. SELinux can block operations that filesystem permissions allow. Check ausearch -m avc -ts recent for AVC denials and use audit2allow to generate a policy fix.

All tools run in your browser. Your data never leaves your device.