What the error means

Normal users edit their scheduled tasks with the crontab command. It writes to a protected folder, /var/spool/cron, which only root can change. The setuid bit lets the program do that on the user’s behalf. If the bit is missing, or the file is not owned by root, crontab refuses to run and prints:

/usr/bin/crontab permissions are wrong. Please set to 4755

On a cPanel server, account owners see the problem as errors when they add or edit jobs in Advanced > Cron Jobs, or their existing jobs stop changing.

Common causes

• A recursive chmod or chown run on /usr or / by mistake.
• A security script or hardening tool that removed setuid bits.
• A restore or file copy that did not keep special permissions.
• A damaged or partly updated cron package.

Step 1: check the current permissions

ls -l /usr/bin/crontab
# Correct: -rwsr-xr-x. 1 root root ... /usr/bin/crontab

The s in the owner’s permissions is the setuid bit. If you see -rwxr-xr-x, or an owner other than root, the permissions are wrong.

Step 2: let the package manager check and fix it

The cron package records the correct owner and permissions of its files. Compare them and restore them:

# AlmaLinux, Rocky Linux, CloudLinux, RHEL
rpm -qf /usr/bin/crontab          # which package owns the file (usually cronie)
rpm -V cronie                     # lists files that differ from the package
rpm --setugids cronie             # restore owners and groups
rpm --setperms cronie             # restore permissions

rpm -V prints nothing when everything matches. A line with M means the mode (permissions) changed.

Step 3: or set the permissions by hand

chown root:root /usr/bin/crontab
chmod 4755 /usr/bin/crontab
ls -l /usr/bin/crontab

Step 4: reinstall if the file is damaged

# AlmaLinux, Rocky Linux, CloudLinux
dnf reinstall -y cronie crontabs

# Debian and Ubuntu (package name: cron)
apt install --reinstall cron

Old guides mention vixie-cron. That package belongs to CentOS 5 and 6; current systems use cronie on the Red Hat family and cron on Debian and Ubuntu.

Step 5: make sure the cron service runs

systemctl enable --now crond     # AlmaLinux, Rocky Linux, CloudLinux
systemctl status crond --no-pager

systemctl enable --now cron      # Debian and Ubuntu

Step 6: test with a real job

As a normal user, or from cPanel’s Cron Jobs page, add a job that writes to a file every minute:

* * * * * date >> $HOME/cron-test.log

After two minutes, check that cron-test.log has new lines, then delete the job and the file. On cPanel servers, also check that the user’s jobs are in /var/spool/cron/USERNAME.

Cron jobs in cPanel

Account owners manage their jobs in cPanel under Advanced > Cron Jobs. Set a cron email address there to receive the output of each job, which makes failed jobs easy to spot. Use full paths in commands, such as /usr/local/bin/php, because cron runs with a minimal environment.

If many files lost their permissions

If the cause was a recursive chmod or chown, other programs, such as sudo, passwd and su, are probably broken too. Check every installed package and restore them:

rpm -Va | grep -E "^.M" | head -n 50     # files with changed permissions
rpm -a --setperms                         # restore permissions for all packages
rpm -a --setugids                         # restore owners and groups

Run this carefully, and only on the Red Hat family. Restoring all packages also resets permissions you may have changed on purpose. On a badly damaged server, restoring from a backup can be quicker.