I found a number of threads such as this, but the scenarios are all a little different so I'm starting my own. I'm wondering if this is a permissions thing...Here is the scenario (forgive me if my terminology is off):

Under /var/spool/cron there is an admin crontab with a script that is set to run at 4am every day. The script itself and the content aren't important I don't think because the job itself never runs, but here it is in case it helps:

.

I followed the troubleshooting tips at http://aplawrence.com/Unixart/crontab_not_running.html: I verified mail can be sent, I checked the logs, made sure crond was running, I added a test script to the admin and root crontabs to write "foobar" to the cron.test document (the second line in the above crontab). The root crontab worked as expected (same script, different directory), and the results of /var/log/cron shows the command running every minute as it should. There is no such result for the same thing for the admin crontab. It shows crontab being reloaded after I make the changes to the file, but that's it. It never appears to run. The article I referenced above mentions something about permissions on the crontab.

Could this be my problem? Here are the permissions for the admin crontab:

Do I need to chown and chgrp to admin for this to run?

Thanks in advance for your assistance.

Maybe just two silly questions but... here we go:
1) Is "admin" an actual user of your system (is it listed in /etc/passwd)?
2) Have you checked the content of /etc/cron.deny?

Not silly at all. Yes, admin is a user on the system (checked /etc/passwd), and there's no content in /etc/cron.deny.

/var/spool/cron/crontab/<user> should be owned by the user it runs as.

Therefore you need to make /var/spool/cron/crontab/admin owned by user "admin" not user "root".

The admonition about /etc/crontab was not meant to cover all of /var/spool/cron/crontab files. If you had a root file in /var/spool/cron/crontab it should be owned by root but only because root is the user for that file.

No user other than the owner should be able to write to any of the /var/spool/cron/crontab files. Anyone that could write to them could make jobs run as that user.

If the first job fails to run due to a cron issue, root or the job owner should get an email as to why.
Try mailx from the cmd line as both users.
Incidentally, is amalgamaton.sh really spelt like that and not amalgamation.sh ?

Sorry for the radio silence. Unfortunately, this is a client that I only see about once a week so I haven't been back until today.

Yes, amalgamaton.sh is the correct spelling. I checked and made sure that the path indicated in the script is correct as well. I also get no mail for the root user pertaining to this job, nor does the Admin user whose script it is receive any email that the job has failed.

I thought I had changed the ownership after jlightner's post, but after checking permissions again it still shows as owned by user root. I have changed it to admin (again) and will see how that pans out.

Thanks for the advice!

Well, I changed the permissions and they stuck and the job is still not running, at all. It's as if crond doesn't even see it. I'm out of ideas other than adding this script to cron.daily and letting it run from there.

Did you restart cron after changing the permissions?

Can I add one more thing to this that maybe someone can confirm may or may not be related?

The environment uses Likewise/Samba for authentication. There is a Windows group defined in ADUC, Linux Admins. There is a line in the Likewise config file saying that a user must be a member of this group to log in to the system. The admin account is not a member and therefore cannot directly ssh into the system (this is on purpose). Users can sudo to admin once logged in and run commands however. I also notice that around 4am every day (the same time the cronjob should run for the user admin) /var/log/messages has this entry:

I'm grabbing at straws and trying to make a connection. I don't see how denying an account the ability to ssh would affect its ability to run a cronjob, especially since users are able to kick off the desired script manually once sudoed to the admin account, but the fact that the error is logged around the same time as the job is supposed to run makes me wonder...

@jlightner: nope, sure didn't! Will do now.

Since it is an "Error" and occurs at the time the cron job runs it seems extremely likely this is your issue. The good news is that it tends to confirm your cron is trying to run.

You might want to set a different time (e.g. 5 minutes from now) on your foobar test line in admin's cron and see if gives the error when that tries to run. If so it confirms it is the issue.

The error suggests the fix is to add admin to the restricted login list.

Well, that is indeed the problem! I checked that log and the same message is being reported every minute, right along schedule with the cron job that is trying to run. I have the problem, now I will work on the solution (starting with figuring out what this restricted login list is). Thanks so much for your help!