Fix “Permission Denied” Errors When Accessing Cron as Regular User: Linux Cron Troubleshooting Guide


2 views

When working with cron on Linux systems, permission issues often arise from the default configuration where only root has full access to cron-related files. The key directories and files involved are:

/var/spool/cron/crontabs/  # User crontab storage
/var/run/crond.pid        # PID file for cron daemon
/etc/cron.allow           # Allow list (if exists)
/etc/cron.deny            # Deny list (if exists)

Let's first examine the actual permission errors you're encountering:

$ crontab -l
crontab: can't open or create /var/spool/cron/crontabs/username: Permission denied

$ crontab -e
/var/spool/cron/crontabs/username: Permission denied

The directory permissions should look like this for proper functionality:

$ ls -ld /var/spool/cron/crontabs/
drwx-wx--T 2 root crontab 4096 Jul 12 10:00 /var/spool/cron/crontabs/

The main issue stems from two permission problems:

  1. The /var/spool/cron/crontabs/ directory doesn't have the sticky bit set
  2. Your user isn't properly added to the crontab group

Solution 1: Fixing Directory Permissions

As root, execute:

# chmod 1730 /var/spool/cron/crontabs
# chown root:crontab /var/spool/cron/crontabs

This sets:
- Sticky bit (1)
- Owner read/write/execute (7)
- Group write/execute (3)
- Others no permissions (0)

Solution 2: Verifying Group Membership

Check if your user is in the crontab group:

$ groups
username adm cdrom sudo dip plugdev lpadmin sambashare

If missing, add your user:

# usermod -a -G crontab username

Then verify the group exists in /etc/group:

crontab:x:102:username,otheruser

If issues persist after these changes:

  1. Check SELinux/AppArmor policies
  2. Verify PAM configuration
  3. Examine system logs (/var/log/syslog or journalctl -u cron)

Example log check:

$ sudo grep cron /var/log/syslog | tail -20

For temporary solutions or specific commands:

$ sudo crontab -u username -e

Or create a sudoers rule:

username ALL=(root) NOPASSWD: /usr/bin/crontab -u username *

When adjusting cron permissions:

  • Never set world-writable permissions on cron directories
  • Maintain proper ownership (root:crontab)
  • Regularly audit /etc/cron.allow and /etc/cron.deny
  • Monitor crontab changes through system logs

When dealing with cron permission issues, we're typically facing two distinct but related problems:

1. Read/write permissions for /var/run/crond.pid
2. Access rights to /var/spool/cron/crontabs directory

The error messages reveal the core permission structures:

$ ls -la /var/run/crond.pid
-rwxr-Sr-- 1 root root 5 2011-05-27 12:44 crond.pid

$ ls -la /var/spool/cron/
drwxr-sr-x  5 root root     4,0K 2009-12-23 23:01 cron

Despite being in the crontab group (as shown in /etc/groups), users still encounter:

crontab:x:102:skerit,www-data

This suggests the group permissions aren't properly applied or the system needs refresh.

First, verify your effective group membership:

id -a
groups

Then check if the crontab group has execute permissions on parent directories:

namei -l /var/spool/cron/crontabs

Here's a complete fix that addresses all aspects:

# 1. Verify and update group membership
sudo usermod -aG crontab $USER

# 2. Fix directory permissions (temporary)
sudo chmod g+rwx /var/spool/cron/crontabs
sudo chmod g+rwx /var/run/

# 3. Permanent solution via PAM
echo "session optional pam_limits.so" | sudo tee -a /etc/pam.d/cron

# 4. Restart services
sudo systemctl restart cron

For systems where you can't modify permissions:

# Option 1: Use sudo with crontab
sudo crontab -u $USER -e

# Option 2: Create user-specific cron directory
mkdir ~/.cronjobs
echo "* * * * * /home/$USER/.cronjobs/myscript.sh" | tee ~/.cronjobs/crontab
crontab ~/.cronjobs/crontab

When permissions are fixed but jobs still fail:

# View cron logs
sudo tail -f /var/log/syslog | grep CRON

# Test environment variables
* * * * * env > /tmp/cronenv