The Extra User Field in System Crontabs
System-wide crontabs — /etc/crontab and files in /etc/cron.d — take a sixth field: the user to run the job as, placed between the schedule and the command. User crontabs (crontab -e) do not. Omitting or adding it in the wrong place makes the job fail.
The format
In /etc/crontab and /etc/cron.d/*:
0 3 * * * root /path/to/job.sh
Fields: minute hour day-of-month month day-of-week user command. Here the job runs as root at 3 AM.
Personal crontabs are different
Files edited with crontab -e have no user field — they already run as their owner. Adding one there turns the username into part of the command and breaks it.
Rules for /etc/cron.d files
Filenames must contain no dots, permissions should be 644, owned by root, and the file must end with a newline. A stray dot in the name makes cron ignore the whole file.
FAQ
Does /etc/crontab need a user field?
Yes. System crontabs (/etc/crontab and /etc/cron.d/*) add a user field between the schedule and the command, e.g. 0 3 * * * root /path/job.sh.
Why does my /etc/cron.d job not run?
Common causes: missing user field, a dot in the filename, wrong permissions (should be 644 root-owned), or no trailing newline.
Do personal crontabs need the user field?
No. crontab -e files run as their owner and have five time fields then the command. Adding a username there breaks the job.