When working with cron jobs on Linux systems, you might encounter permission-related errors when attempting to list or edit crontab entries. The specific errors we're examining here manifest as:
crontabs/user/: fopen: Permission denied
crontabs/user/: fdopen: Permission denied
These errors typically occur when there's a mismatch in permissions between the crontab binary, the spool directory, and the user's crontab file itself.
Three critical locations need proper permission settings:
1. The crontab binary:
$ ls -l /usr/bin/crontab
-rwxr-sr-x 1 root libuuid 35896 Aug 24 2010 /usr/bin/crontab
2. The crontab spool directory:
$ ls -ld /var/spool/cron/crontabs
drwx-wx--T 2 root libuuid 4096 Jan 10 2014 /var/spool/cron/crontabs
3. Individual crontab files:
$ ls -l /var/spool/cron/crontabs/
-rw------- 1 1017 libuuid 1120 Dec 3 2013 user
-rw------- 1 root libuuid 1342 Jan 10 2014 root
For proper operation, these should be the permission settings:
# crontab binary (typically correct by default)
chmod 2755 /usr/bin/crontab
chown root:libuuid /usr/bin/crontab
# crontab spool directory
chmod 1730 /var/spool/cron/crontabs
chown root:libuuid /var/spool/cron/crontabs
# individual crontab files (auto-managed by cron)
# Should maintain 600 permissions and proper ownership
Case 1: When the sticky bit is missing from the crontabs directory:
sudo chmod +t /var/spool/cron/crontabs
Case 2: When the group ownership is incorrect:
sudo chown :libuuid /var/spool/cron/crontabs
Case 3: When the directory permissions are too restrictive:
sudo chmod 1730 /var/spool/cron/crontabs
For system administrators managing multiple servers, here's a bash script to verify and fix crontab permissions:
#!/bin/bash
# Check and fix crontab binary permissions
CRONTAB_BIN="/usr/bin/crontab"
if [ "$(stat -c '%a' $CRONTAB_BIN)" != "2755" ]; then
echo "Fixing crontab binary permissions..."
sudo chmod 2755 $CRONTAB_BIN
sudo chown root:libuuid $CRONTAB_BIN
fi
# Check and fix crontab directory permissions
CRONTAB_DIR="/var/spool/cron/crontabs"
if [ "$(stat -c '%a' $CRONTAB_DIR)" != "1730" ]; then
echo "Fixing crontab directory permissions..."
sudo chmod 1730 $CRONTAB_DIR
sudo chown root:libuuid $CRONTAB_DIR
fi
# Verify individual crontab files
for file in $CRONTAB_DIR/*; do
if [ -f "$file" ] && [ "$(stat -c '%a' "$file")" != "600" ]; then
echo "Fixing permissions for $file"
sudo chmod 600 "$file"
fi
done
- Use
strace crontab -l
to see exactly where the permission check fails - Check system logs:
grep cron /var/log/syslog
- Verify your user's group membership with
groups
command - Test with root user to isolate permission issues:
sudo crontab -u username -l
To avoid these issues in the future:
- Regularly audit cron-related permissions
- Include permission checks in your server provisioning scripts
- Monitor cron job execution in your system monitoring
- Document the proper permission settings for your team
The crontab system relies on several key permission settings to function properly:
/usr/bin/crontab permissions:
-rwxr-sr-x 1 root libuuid
/var/spool/cron/ structure:
drwxr-xr-x 3 root root
drwx-wx--T 2 root libuuid crontabs/
When you encounter the "fopen: Permission denied" error during crontab operations, it typically indicates one of these scenarios:
- The sticky bit (T) on the crontabs directory is set incorrectly
- The user lacks proper group membership (should be in libuuid group)
- The individual crontab file permissions are corrupted
First, verify the user's group membership:
groups username
id username
If the user isn't in the libuuid group, add them:
sudo usermod -a -G libuuid username
Next, check and correct directory permissions:
sudo chmod 1730 /var/spool/cron/crontabs
sudo chown root:libuuid /var/spool/cron/crontabs
After making these changes, test crontab access:
sudo -u username crontab -l
If successful, you should see the user's crontab contents or an empty file.
To avoid future permission issues:
# Create a maintenance script
#!/bin/bash
chmod 1730 /var/spool/cron/crontabs
chown root:libuuid /var/spool/cron/crontabs
chmod g+s /usr/bin/crontab
Schedule this script to run periodically or include it in your system maintenance routines.