Run a cron job as a specific user

Use the target account's own crontab, or put its username in a system cron entry. These are different formats: user crontabs have five schedule fields followed by the command; /etc/crontab and supported /etc/cron.d/ files add a username before the command.

Edit the account's crontab

An administrator can edit an application user's table with:

sudo crontab -u appuser -e

An entry in that table needs no username:

0 3 * * * /home/appuser/jobs/nightly.sh >> /home/appuser/jobs/nightly.log 2>&1

A user editing their own table simply runs crontab -e. Use sudo crontab -u appuser -l to confirm which table you changed. Avoid direct spool edits; the location and access controls depend on the cron implementation.

Use a system cron file

For centrally managed jobs, system entries identify the execution account explicitly:

# minute hour day month weekday user command
0 3 * * * backup /opt/scripts/backup.sh
*/5 * * * * appuser /srv/app/bin/collect.sh

On Debian, /etc/crontab and /etc/cron.d/ files must be root-owned and must not be group- or other-writable. A file in /etc/cron.d/ does not automatically inherit environment assignments from /etc/crontab. Follow the distribution's filename and permission rules.

Normal supported configuration changes are detected by cron; restarting it is usually unnecessary. Check logs and an actual run after installation.

Choose the ownership model

A user's crontab keeps application scheduling with that account. System cron files suit configuration-managed host tasks that administrators want to review together. Configuration-management tools can manage either form; check whether their module expects a user table or a system file rather than assuming one format.

Use a dedicated account with the permissions the job needs. Running everything as root can hide ownership mistakes and expands what a compromised script can change.

Verify the runtime context

Set a deliberate PATH, use absolute paths, and change into the required working directory in the script. Cron does not reproduce the administrator's interactive environment. Check access to scripts, inputs, network credentials and output directories as the chosen account.

Output must have a destination. A log redirection requires write permission before the command can start. Cron mail additionally requires a working mail transport.

Common questions

Why does crontab -u report a privilege error? Managing another user's table normally requires administrative privileges. Use your own table or an authorized administrative command.

Can an account with a nologin shell run cron jobs? Often yes: cron normally invokes the configured SHELL, not the account's interactive login shell. But account expiry, PAM policy and distribution-specific access controls can still block execution. cron.allow and cron.deny commonly control use of the crontab command; they are not a universal description of runtime authorization.

Why can a root job still receive “permission denied”? Inspect the actual failing operation. SELinux, read-only mounts, NFS root squashing, namespaces and other restrictions can matter; ordinary file permissions alone do not explain every denial.

References

• Debian crontab syntax
• Debian cron daemon behavior