CRON[83463]: Failure setting user credentials

us flag

I have a number of docker containers, all set up mostly identically, which successfully use cron to run nightly backup jobs.

I have another container, set up mostly identically, which tries, and fails, to use cron to run a nightly backup job.

I installed rsyslog to get more information, and when cron runs root's crontab I see the following entry in the syslog file:

CRON[83463]: Failure setting user credentials

The one difference between this container and all the others is that this one allows users to log in using LDAP. It has the following extra lines in the Dockerfile:

RUN echo '*;*;*;Al0000-2400;svn' >> /etc/security/group.conf
COPY pam_group /usr/share/pam-configs/groups
RUN echo "session required skel=/etc/skel umask=077" >> /etc/pam.d/common-session
RUN sed -i 's#\(.**\)#auth    required\n\1#' /etc/pam.d/common-auth
RUN sed -i 's#^passwd:.*#passwd:  files ldap systemd#;s#^group:.*#group:   files ldap systemd#;s#^shadow:.*#shadow:  files ldap#' /etc/nsswitch.conf

The pam_group file looks like:

Name: activate /etc/security/group.conf
Default: yes

Priority: 900
Auth-Type: Primary Auth:

Clearly, something about setting up the LDAP, and trying to ensure that all users get added to the svn group (which doesn't work at all) broke the root user session for cron.

I have looked all over the internet, but not found this specific error. I have tried related solutions, but nothing works.


pam.d/common-auth looks like:

auth    [success=2 default=ignore] nullok_secure
auth    required
auth    [success=1 default=ignore] use_first_pass
# here's the fallback if no module succeeds
auth    requisite 
# prime the stack with a positive return value if there isn't one already;
# this avoids us returning an error just because nothing sets a success code
# since the modules above will each just jump around
auth    required  
# and here are more per-package modules (the "Additional" block)
auth    optional   

pam.d/cron looks like:

@include common-auth

# Sets the loginuid process attribute
session    required

# 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
pk flag

Your problem is probably that the root user isn't in LDAP; you'll need to include in /etc/pam.d/cron somehow.

For example:

auth    [success=2 default=ignore] nullok_secure
@include common-auth

Assuming that common-auth begins something like this:

auth    [success=1 default=ignore]
auth    requisite             
auth    required              

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.