When you encounter the "Permission denied" error while trying to edit your crontab file, it typically indicates a permissions configuration problem in your Unix/Linux system. The error often appears in this format:

user@host:~$ crontab -e
/var/spool/cron/crontabs/user: Permission denied

Before making any changes, let's check several important system aspects that might be causing the issue:

$ ls -al /usr/bin/crontab
-rwxr-xr-x 1 root root 32048 Aug 30  2009 /usr/bin/crontab

$ ls -al /var/spool/cron/crontabs
drwx-wx--T 2 root crontab 4096 Oct 25  2009 .
drwxr-xr-x 3 root root    4096 May 18  2009 ..
-rw------- 1 root root     612 Oct 25  2009 root

Two key observations here:
1. The crontab binary doesn't have the setgid bit set
2. It doesn't belong to the crontab group

On most Unix-like systems, crontab requires special permissions to function properly. The /var/spool/cron/crontabs directory has restrictive permissions (drwx-wx--T) which means:

• Only root and members of the crontab group can write to it
• The sticky bit (T) prevents users from deleting others' cron files

The crontab command needs to run with elevated privileges to modify files in this protected directory.

As root, execute these commands to properly configure crontab permissions:

# chown root.crontab /usr/bin/crontab
# chmod g+s /usr/bin/crontab

After applying these changes, verify the new permissions:

$ ls -al /usr/bin/crontab
-rwxr-sr-x 1 root crontab 32048 Aug 30  2009 /usr/bin/crontab

The 's' in the group permissions indicates the setgid bit is now properly set.

In some cases, you might need to additionally:

• Add your user to the crontab group: usermod -aG crontab username
• Check PAM configuration if using SELinux
• Verify ACLs aren't interfering: getfacl /var/spool/cron/crontabs

After making these changes, test by creating a simple cron job:

$ crontab -e
* * * * * /usr/bin/logger "Cron test successful"

Wait a minute, then check system logs:

$ grep Cron /var/log/syslog

While fixing permissions, be mindful of:

• Never set world-writable permissions on crontab-related files
• Maintain the sticky bit on /var/spool/cron/crontabs
• Regularly audit cron permissions with: ls -la /usr/bin/crontab /var/spool/cron/crontabs

---

When attempting to edit cron jobs using crontab -e, many users encounter the frustrating "Permission denied" error. Let's examine the specific case where:

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

The root cause becomes clearer when we examine the directory structure:

$ ls /var/spool/cron/crontabs
ls: cannot open directory /var/spool/cron/crontabs: Permission denied

$ sudo ls -al /var/spool/cron/crontabs
total 12
drwx-wx--T 2 root crontab 4096 2009-10-25 20:45 .
drwxr-xr-x 3 root root    4096 2009-05-18 01:19 ..
-rw------- 1 root root     612 2009-10-25 01:20 root

Key observations:

• The crontabs directory has restrictive permissions (drwx-wx--T)
• Only root and members of the crontab group can write to this directory
• The crontab binary lacks the setgid bit

The fundamental issue lies in how the crontab command interacts with the spool directory. Without proper group ownership and setgid permissions:

$ ls -al /usr/bin/crontab
-rwxr-xr-x 1 root root 32048 2009-08-30 03:34 /usr/bin/crontab

Notice the missing 's' in the group permissions field where we'd expect r-s instead of r-x.

To resolve this, we need to make two critical changes:

# Update group ownership
sudo chown root.crontab /usr/bin/crontab

# Set the setgid bit
sudo chmod g+s /usr/bin/crontab

After applying these changes, verify the new permissions:

$ ls -al /usr/bin/crontab
-rwxr-sr-x 1 root crontab 32048 2009-08-30 03:34 /usr/bin/crontab

The setgid bit (g+s) ensures that when users execute crontab, it runs with the group permissions of the crontab group rather than the user's primary group. This is essential because:

• The /var/spool/cron/crontabs directory only allows write access to the crontab group
• Regular users aren't in the crontab group by default
• The setgid bit provides temporary elevated privileges needed for editing cron jobs

If you still encounter issues after applying these changes:

# Verify the user's group memberships
groups

# Check for SELinux or AppArmor restrictions
sudo ausearch -m avc -ts recent
sudo aa-status

While this solution works, it's important to understand the security implications:

• The setgid bit gives the crontab command elevated privileges
• Only trusted users should have execute permissions on /usr/bin/crontab
• Regular audits of /etc/cron.allow and /etc/cron.deny are recommended

For systems with strict security requirements, consider alternatives like systemd timers or dedicated scheduling services.