Ask Ubuntu is a question and answer site for Ubuntu users and developers. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Update: This issue will not be answered conclusively; I have moved to another distro and have not observed this problem since. I was never able to fix it with the insightful answers available at the time, but your fuel efficiency may vary (YMMV).

crontab -e and crontab -l work just fine:

$ crontab -l | grep -v '^#'
* * * * * /usr/bin/env
* * * * * echo 'Hello from crontab'

However, I see two messages like this every minute in /var/log/syslog:

Mon DD hh:mm:01 username CRON[PID]: Permission denied

So the crontab is being read, but somehow it can't execute anything at all (of course I verified the commands when logged in as the same user). Any idea why?

/etc/cron.allow and /etc/cron.deny do not exist.

crontab is set group setuid:

$ stat --format '%A %U %G' /usr/bin/crontab
-rwxr-sr-x root crontab

The crontabs directory seems to have the right permissions:

$ stat --format '%A %U %G' /var/spool/cron/crontabs
drwx-wx--T root crontab

The crontab itself is owned by me (not surprisingly, since I'm able to edit it):

$ sudo stat --format '%A %U %G' /var/spool/cron/crontabs/$USER
-rw------- username crontab

I am not a member of the crontab group.

These lines appear in /var/log/auth.log every minute (thanks @Alaa):

Mon DD hh:mm:01 username CRON[1752]: pam_unix(cron:session): session opened for user username by (uid=0)
Mon DD hh:mm:01 username CRON[1752]: PAM bad jump in stack

Maybe PAM is broken? pam-auth-update (thanks @coteyr) lists all of these, and all of them are enabled:

  • Unix authentication
  • GNOME Keyring Daemon - Login keyring management
  • eCryptfs Key/Mount Management
  • ConsoleKit Session Management
  • Inheritable Capabilities Management

Can any of them be safely disabled? I'm not using any encrypted filesystems.

Based on a Debian bug entry I tried running debconf-show libpam-runtime, and I got the following error message:

debconf: DbDriver "passwords" warning: could not open /var/cache/debconf/passwords.dat: Permission denied

The contents of /etc/pam.d/cron:

# The PAM configuration file for the cron daemon

@include common-auth

# Read environment variables from pam_env's default files, /etc/environment
# and /etc/security/pam_env.conf.
session       required

# In addition, read system locale information
session       required envfile=/etc/default/locale

@include common-account
@include common-session-noninteractive 

# Sets up user limits, please define limits for cron tasks
# through /etc/security/limits.conf
session    required

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

The files mentioned (/etc/environment,, /etc/default/locale,, are all readable by my user.

On another host with Ubuntu 13.04, with the same user crontab, no /etc/cron.{allow,deny}, same permissions as above, and not being a member of the crontab group, it works just fine (logs the commands but not the output in /var/log/syslog).

By changing the first crontab line:

* * * * * /usr/bin/env >/tmp/env.log 2>&1

and checking that /tmp is world writeable:

$ sudo -u nobody touch /tmp/test
$ ls /tmp/test
$ ls -ld /tmp
drwxrwxrwt 15 root root 12288 May 27 10:18 /tmp

I've verified that the crontab commands are not run at all: The Permission denied messages still show up in /var/log/syslog, but /tmp/env.log is not created.

Based on a random listing of /etc/pam.d settings I found the following discrepancies:

$ grep '^[^#]' /etc/pam.d/sshd 
@include common-auth
account    required
@include common-account
@include common-session
session    optional # [1]
session    optional standard noenv # [1]
session    required
session    required # [1]
session    required user_readenv=1 envfile=/etc/default/locale
@include common-password
$ grep '^[^#]' /etc/pam.d/common-session
session [default=1]
session requisite 
session required  
session optional  
session required 
session optional unwrap
session optional   nox11
$ grep '^[^#]' /etc/pam.d/common-account
account [success=1 new_authtok_reqd=done default=ignore] 
account requisite 
account required  
$ grep '^[^#]' /etc/pam.d/common-session-noninteractive 
session [default=1]
session requisite 
session required  
session optional  
session required 
session optional unwrap

PAM packages installed:

$ dpkg --get-selections | grep --invert-match deinstall | cut --fields 1 | grep pam

I tried reinstalling these - didn't help:

$ sudo apt-get install --reinstall $(dpkg --get-selections | grep --invert-match deinstall | cut --fields 1 | grep pam)

I can't purge and then reinstall these because of unmet dependencies.

share|improve this question
Did you tried to log in as cron and execute the commands? – NotFromBrooklyn May 21 '13 at 9:40
@l0b0, what about the permissions of the crontab file itself, inside the crontabs folder, i.e. /var/spool/cron/crontabs/username? – Alaa Ali May 21 '13 at 9:56
Hmm. What does /var/log/auth.log say about CRON? – Alaa Ali May 21 '13 at 10:30
@NotFromBrooklyn id cron -> id: cron: No such user – l0b0 May 21 '13 at 14:24
@ssoto How do I find out? I am a local user, if that's what you mean. – l0b0 May 22 '13 at 8:03

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"

share|improve this answer
I should be clear, a finger print scanner should normally be "optional" not "required". Making it "required" means that things without your fingerprint can't "login". Because of a configuration error like that you could end up with a issue like this. However, normally a finger print scanner (or USB or LDAP or SMB or whatever) would not cause the issue. – coteyr May 22 '13 at 12:40
I have not connected any fingerprint scanners or USB drives. Do you perhaps know somewhere I can check what the default content of /etc/pam.d/common-* would be? – l0b0 May 27 '13 at 8:12
sudo dpkg-reconfigure pam is the best way. However, you can use sudo dpkg -i --force-confmiss after deleting the file (CAREFUL) and it will put one back see this link:… – coteyr May 27 '13 at 14:25
/usr/sbin/dpkg-reconfigure: pam is not installed. I also tried sudo dpkg-reconfigure libpam-runtime, but that didn't help. – l0b0 May 27 '13 at 15:08
I do not think it's a missing package. I think it's a messed up config. The error "PAM bad jump in stack" means that, for some reason, a required pam module could not authenticate. As I said this is normally caused by people messing with their pam files either knowingly or incidently and adding a required module that is not working. Some examples would be SMB authentication, LDAP authentication, hardware based authentication, etc. Keep in mind, some package may have added a file that is causing the problem. Pam is working, cause you can login, but it's also not working because cron can't – coteyr May 27 '13 at 19:38

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] 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.

share|improve this answer
I had the same line (must have got it from somewhere on the interwebs), commented it out and everything started working again. – Mike Nov 19 '14 at 1:34

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.