All commands in my crontab fail with "Permission denied"

Solution 1:

PAM bad jump in stack is a big clue.

Your /etc/pam.d/cron differs from the stock version with the addition of one extra line at the end:

session [success=1 default=ignore] pam_succeed_if.so service in cron quiet use_uid

The success=1 bit means "if this module succeeds, skip the next rule". Only there's no next rule, as this is the last line in your PAM configuration.

Solution 2:

Your PAM configuration is out of sorts. This is common if you have used "external" authentication methods like fingerprint scanners, LDAP accounts, USB Keys or the sort. Basically cron can't work a fingerprint scanner so it can't login as you.

You need to remove the offending configuration from /etc/pam.d/common-* though tracking it down can be a bit difficult, specially if you didn't enable something manually (for example if a Finger print scanner setup script turned something on).

I can't help much with telling you what should be in those files. A lot of things could be different depending on your setup. But disabling "required" auth methods till your left with just "Unix Authentication" may be a good first step.

You can do this by running pam-auth-update as root and un-checking the other boxes. Be very very careful as this can leave you with a system you can not login to if done incorrectly. Disable them one at a time, reboot for safety, and test. NEVER DISABLE "Unix Authentication"

Solution 3:

We were trying to schedule cron from a LDAP user (non machine user) and getting the same permission denied for even putting basic echo command or script in crontab, while it was working completely file from machines users (who have entries in /etc/passwd). Taking help from the detailed troubleshooting comments added by OP, we checked file /var/log/auth.log where we found this line:

pam_sss(cron:account): Access denied for user my_username: 6 (Permission denied)

A bit of Google search took me to this answer which worked for us. Adding the details here as well.

In /etc/sssd/sssd.conf, under our domain, we added an entry (see last line) like this.

[domain/my.domain.com]
....
ad_gpo_map_interactive = +cron

And then just did sudo service sssd restart and it works like a charm.