VMware ESXi and vSphere Cluster Management

User Cron Jobs in Linux

Learn how to create, edit, view, install, remove, and troubleshoot per-user Linux cron jobs with the crontab command.

What is a user cron job?

cron is a Linux scheduling service that runs commands at configured times. A cron job is one scheduled command or script execution.

A user crontab is a schedule owned by one user. Every command in that schedule runs with the identity, permissions, environment, and file ownership of the crontab owner. A regular user cron job cannot access files or perform operations that the user could not access manually.

User crontabs are useful for tasks such as backups, reports, cleanup, synchronization, and periodic health checks without requiring system-wide administrator access.

User crontab versus system cron configuration

The crontab command manages a user's scheduled entries. System-wide configuration, such as /etc/crontab, is intended for jobs managed by administrators and can choose which account executes each command.

Do not add a username to a user crontab entry. The owner is already implied. For example, this user entry has five time fields followed directly by the command:

0 22 * * * /home/bob/bin/cleanup.sh

A system cron file may use a form like this instead:

0 22 * * * bob /home/bob/bin/cleanup.sh

The crontab command

The general command form is:

crontab [-u USER] [OPTIONS] [FILE]

When -u is omitted, the command operates on the current user's crontab. Selecting another user's crontab, such as with crontab -u alice -l, generally requires administrative privileges.

Editing a user crontab

Open the current user's managed crontab editor with:

crontab -e

The editor is selected by the system or by environment settings. It may be nano, vi, vim, or another configured editor. If you are unfamiliar with the editor, learn how to save and exit before changing the schedule.

Add or change entries, then save the file and exit the editor. The crontab command validates and installs the resulting schedule when the editor closes successfully. Verify the installation with:

crontab -l

Use crontab rather than directly editing files in the cron spool. Spool files are internal implementation storage, may have special ownership and permissions, and can vary between distributions. Direct edits can be ignored, overwritten, or create an invalid schedule.

Cron entry format

A user cron entry contains five scheduling fields followed by the command:

minute hour day-of-month month day-of-week command

Common scheduling operators are:

• Wildcard (*): every allowed value. For example, * in the hour field means every hour.
• List (,): several values. For example, 1,15 means the first and fifteenth.
• Range (-): a continuous interval. For example, 1-5 means Monday through Friday when day-of-week numbering uses 1 for Monday.
• Step (/): every interval within a field. For example, */15 in the minute field means minutes 0, 15, 30, and 45.

Understanding schedules

Cron uses 24-hour time. The entry 0 22 * * * means minute 0 of hour 22, every day of the month, every month, and every day of the week. In other words, it runs daily at 22:00, or 10:00 p.m.

0 22 * * * /usr/bin/rm -f /home/bob/trash/*

This example uses the crontab owner's permissions and runs once each day at 22:00. Because it deletes files, validate the path and wildcard carefully before scheduling it.

When both day-of-month and day-of-week are restricted rather than set to *, traditional cron implementations generally run the command when either restriction matches. If one of those fields is *, the other field supplies the restriction. Implementations and extensions can differ, so test schedules that specify both fields, especially when the intended meaning is “and” rather than “or.”

Useful scheduling examples

Run every 15 minutes

*/15 * * * * /usr/local/bin/check-status

The step operator schedules the command at 15-minute intervals. The executable must be accessible to the crontab owner.

Run a backup script daily at 01:30

30 1 * * * /home/alice/bin/backup.sh >> /home/alice/logs/backup.log 2>&1

The first two fields specify 01:30 daily. >> appends standard output to the log, and 2>&1 sends standard error to the same destination.

Viewing and removing crontabs

List the current user's installed entries with:

crontab -l

Remove the current user's entire crontab with:

crontab -r

This is destructive and removes all entries, not just one line. Back up or list the schedule first. On systems that support interactive removal, use:

crontab -r -i

The interactive form asks for confirmation before removal. Option support can vary, so consult the local command documentation with man crontab.

Installing a crontab from a file

Prepare a plain text file containing the entries. It should contain user-crontab syntax: five time fields followed by each command, with no username field.

Before replacing the installed schedule, create a backup:

crontab -l > my-crontab-backup.txt

Install the prepared file with:

crontab my-schedule.txt

Installing from a file replaces the user's existing crontab rather than merging the new entries with it. Include any entries you want to keep in the replacement file, and verify the result:

crontab -l

Storage and safe management

Cron implementations commonly store installed user crontabs in a protected spool location, often beneath /var/spool/cron. The exact path varies by distribution and cron implementation.

The spool is internal storage. Do not edit spool files directly. Use crontab -e, install a prepared file with crontab FILE, and use crontab -l for inspection.

Making commands reliable under cron

Cron starts commands in a limited, non-interactive environment. It may not load the same shell startup files, use the same PATH, or start in the directory you expect from an interactive terminal.

• Use absolute paths for commands, scripts, input files, and output files.
• Set required variables explicitly when appropriate.
• Do not assume aliases, shell functions, interactive prompts, or profile files are available.
• Redirect standard output and standard error to a persistent, user-writable log.
• Use a script for multi-step or destructive automation so that it can be reviewed, tested, and logged.

For example, a crontab can define a predictable command path and mail destination:

PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
SHELL=/bin/sh
HOME=/home/alice
MAILTO=alice

Variable syntax and supported behavior can vary slightly between cron implementations. A job's output may be emailed to the job owner when local mail delivery is configured. If mail is not configured or not being read, redirect output to a log instead.

Permissions and safety

A user cron job cannot exceed the permissions of its owner. It can modify only files the owner can modify and cannot normally perform administrator-only operations.

Be especially careful with deletion, wildcards, relative paths, and unquoted shell expansions. Test the exact command manually as the crontab owner before scheduling it. For cleanup, first replace a destructive command with a non-destructive listing command and inspect the results.

For complex automation, put the logic in a reviewed script with explicit paths, validation, logging, and appropriate safeguards. Keep logs in a location the user can write to, and consider log rotation if the job runs frequently.

Verification and troubleshooting

The job works in a terminal but not when scheduled

• Replace commands with absolute paths because cron may have a limited PATH.
• Use absolute paths for files because the working directory may not be the directory used in your terminal.
• Move required setup from an interactive shell profile into the script or crontab environment.
• Redirect both output streams to a log file.

The job appears not to run

• Confirm the installed entry with crontab -l.
• Confirm that a cron service is installed and running. Service names vary; common checks include systemctl status cron and systemctl status crond.
• Check the schedule fields, including minute, hour, month, and day restrictions.
• Test the command manually as the crontab owner.
• Check executable permissions, file ownership, interpreter paths, and any required environment variables.
• Inspect distribution-appropriate system logs or journal output for cron execution messages, such as with journalctl or relevant files under /var/log.

No output or errors are visible

• Cron may have mailed output locally, but local mail delivery may not be configured or the mailbox may not be monitored.
• Add a suitable MAILTO value where mail is configured.
• Append standard output and standard error to a persistent log file, for example >> /home/alice/logs/job.log 2>&1.

A cleanup job removed unexpected files

• An incorrect absolute path or overly broad wildcard may have matched unintended files.
• The command may not have been tested before scheduling.
• Use a listing command first, then add safeguards and explicit paths.
• Move complex cleanup into a reviewed script with logging.

Access to cron is denied

Some systems restrict cron access with /etc/cron.allow and /etc/cron.deny. Their exact precedence and behavior depend on the cron implementation. If present, check whether the user is allowed to use cron and consult the local documentation or administrator.

Recommended workflow

1. Test the command manually as the intended user.
2. Convert command, script, input, and output references to absolute paths.
3. Open the schedule with crontab -e.
4. Add the five scheduling fields and command, without a username field.
5. Save and exit to install the schedule.
6. Run crontab -l to verify the installed entry.
7. Check logs or redirected output after the scheduled time.
8. Back up the schedule before making large replacements or using crontab FILE.