> # and here are more per-package modules (the "Additional" block)
> authoptional pam_mount.so
> authoptionalpam_smbpass.so migrate
that the pam_smbpass.so is a relative path, so the code path 2(b)
should be taken, so the error you see shouldn't
Sven Hartge writes:
> Joe Pfeiffer wrote:
>
>> I'm seeing a large number of entries in my /var/log/syslog that look
>> like this:
>
>> Feb 16 09:07:31 snowball auth: PAM unable to dlopen(pam_smbpass.so):
>> /lib/security/pam_smbpass.so: cannot open
# 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
authrequired pam_permit.so
# and
Hi,
On 02/17/2016 05:11 PM, Joe Pfeiffer wrote:
> Christian Seiler writes:
>> [Suggesting journalctl -o verbose to debug this]
> I'm running a current Debian testing installation, and journal is
> enabled.
>
> It turns out it's only coming from /usr/lib/dovecot/auth. What's
> weird is in /etc/pa
Joe Pfeiffer wrote:
> I'm seeing a large number of entries in my /var/log/syslog that look
> like this:
> Feb 16 09:07:31 snowball auth: PAM unable to dlopen(pam_smbpass.so):
> /lib/security/pam_smbpass.so: cannot open shared object file: No such file or
> directory
> F
I'm seeing a large number of entries in my /var/log/syslog that look
like this:
Feb 16 09:07:31 snowball auth: PAM unable to dlopen(pam_smbpass.so):
/lib/security/pam_smbpass.so: cannot open shared object file: No such file or
directory
Feb 16 09:07:31 snowball auth: PAM adding faulty m
6 matches
Mail list logo