[F36] Cron jobs not executing with root user, OS installed as root disabled

Hey Guys,

After installing F36 as root disabled, I’m getting the following error in the log files when trying to run cron jobs as root:

crond: (root) PAM ERROR (User account has expired)
crond: (root) FAILED to authorize user with PAM (User account has expired)

Is their a quick fix? Read about /etc/cron.allow and /etc/security/access.conf but not sure if it will allow the jbs to be run. Thanks.

How are you trying to create the cron job?

Are you putting it into /etc/crontab by editing that file? or are you doing it with sudo crontab -e -u root to put it into the root users individual crontab file?

The syntax is different depending upon which file it is placed in.
The default /etc/crontab looks and is structured like this

# cat /etc/crontab
SHELL=/bin/bash
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=root

# For details see man 4 crontabs

# Example of job definition:
# .---------------- minute (0 - 59)
# |  .------------- hour (0 - 23)
# |  |  .---------- day of month (1 - 31)
# |  |  |  .------- month (1 - 12) OR jan,feb,mar,apr ...
# |  |  |  |  .---- day of week (0 - 6) (Sunday=0 or 7) OR sun,mon,tue,wed,thu,fri,sat
# |  |  |  |  |
# *  *  *  *  * user-name  command to be executed

where ‘user-name’ is the name of the user to be used when running the command.

The individual crontab file is different in that it does not require the entries above the first command (though they are acceptable) and does not ever use the ‘user-name’ in that line. The individual crontab file is stored in a different location and is edited using the crontab command.

If you are putting the entry into a users individual crontab file then it only runs as that user by design.

Please show us which user is to run that task and the structure of the crontab entry as well showing which crontab file being used. The root user does not by default have an expiration on the account though other users may.

Hi Jeff,

Should have explained this earlier… (head-smack-emoji)…
Note. ROOT user disabled on install

  1. ‘sudo su -’ into root from admin account
  2. ‘crontab -e’ to access the root cron file
  3. these are the jobs…
###############################################################################
##  MIN HRS DOM MTH DOW COMMAND
##    0   0   1   1   0
##   59  23  31  12 6,7
###############################################################################
     50  17   *   *   * /usr/bin/rkhunter --update --quiet
     51  17   *   *   * /usr/bin/rkhunter --cronjob

Never had any problems using this process on other Linux systems.
However, the other systems did have ROOT enabled.
The jobs are never run and the log files gives me the flowing output:

Nov 17 17:50:01 F36SE crond[34849]: (root) PAM ERROR (User account has expired)
Nov 17 17:50:01 F36SE crond[34849]: (root) FAILED to authorize user with PAM (User account has expired)
Nov 17 17:51:01 F36SE crond[34864]: (root) PAM ERROR (User account has expired)
Nov 17 17:51:01 F36SE crond[34864]: (root) FAILED to authorize user with PAM (User account has expired)

I’m guessing this is supposed to happen with ROOT disabled to enhance security.
However, I can’t run cron jobs in the background!

Thanks.

Did someone set an expire date on the root password?

This is stored in /etc/shadow like this

root:xxxxxxxxxxxxxxxxx::0:99999:7:::

where “99999” is the expire date

Thanks Villy,

That looks pretty much what I’ve got.
I’m guessing the installer set this when ROOT user disable was set.
I’d rather not change this as who knows what else the installer did.
Thanks.

Then that was a wrong guess and the root password does not expire.

The root password does not normally expire, as noted with the 99999.

However, you are trying to run 2 different rkhunter jobs from the same crontab (not an issue) at the same time (potential issue). (file conflicts, race conditions, etc. are possible)

What happens if you alter the run times so one has additional time to complete before the other starts.
This way you could tell which task has a problem if it still occurs, and may be able to eliminate it entirely by avoiding one task conflicting with the other.

BTW, it is default for fedora to always have the root account locked when installed. This is security related, but does not interfere with tasks running as root.

Just as an fyi
I just installed rkhunter on my F36 laptop and ran it from cron using your exact 2 commands and timing with no errors

Thanks for your help guys.

I’ve been looking into other cron directories and a default daily script is included in /etc/cron.daily/rkhunter. I’ll delete all the old log files and see what happens in the next 24 hours…

Additional…

Looks like the daily cron rkhunter job was run with the other daily jobs…
A new set of rkhunter logs were generated whilst cron was running…
This will do me. Thanks for your help guys! :wink: