P
P
Pavel K2016-09-04 10:13:08
ubuntu
Pavel K, 2016-09-04 10:13:08

pam_mount and cifs in the Permission denied log, how to fix it?

Greetings!
I configure pam_mount:
common-auth :

auth    required                        pam_mount.so
auth    [success=1 default=ignore]      pam_unix.so nullok_secure
auth    requisite                       pam_deny.so
auth    required                        pam_permit.so

common-session:
session [default=1]   pam_permit.so
session requisite       pam_deny.so
session required        pam_permit.so
session optional        pam_umask.so
session required        pam_unix.so
session optional        pam_systemd.so
session required        pam_mount.so

When a user (lightdm) logs in, I get in auth.log

pam_unix(su:session): session opened for user laser1 by (uid=0)
New session c1 of user laser1.
pam_mount 2.14: entering session stage
conv->conv(...): Conversation error
warning: could not obtain password interactively either
Mount info: globalconf, user=laser1 volume fstype="cifs" server="server.suv" path=" LaserWork" mountpoint="/home/laser1/LaserWork" cipher="(null)" fskeypath="(null)" fskeycipher="(null)" f$
Password will be sent to helper as-is.
command: 'mount' '-t' 'cifs' '//server.suv/LaserWork' '/home/laser1/LaserWork' '-o' 'username=laser1,uid=1001,gid=100,sec=ntlm, iocharset=utf8,file_mode=0700,dir_mode=0700,nodev,nosuid'
Refer to the mount.cifs(8) manual page (eg man mount.cifs)

if it connects manually with the same command, everything is OK, i.e. it turns out that an incorrect password is being transmitted, where is it more correct to stick pam_mount.so?
(user and samba password are the same, sure)

Answer the question

In order to leave comments, you need to log in

1 answer(s)
V
vreitech, 2016-09-04
@fzfx

I have the following line in pam_mount.conf.xml:
where DOM is the name of our domain, srv is the domain name of our file server, folders is an initially existing directory on our server with rights to create subdirectories for any domain user.
also get rid of the option <sgrp>if you have it - it might still be a bug.
our common-session looks like this:

session [default=1] pam_permit.so
session requisite pam_deny.so
session required pam_permit.so
session optional pam_krb5.so minimum_uid=1000
session required pam_unix.so
session optional pam_winbind.so
session optional pam_mount.so
session optional pam_systemd.so
session optional pam_mkhomedir.so skel=/etc/skel/ umask=0077

our common-auth looks like this:
auth [success=3 default=ignore] pam_krb5.so minimum_uid=1000
auth [success=2 default=ignore] pam_unix.so nullok_secure try_first_pass
auth [success=1 default=ignore] pam_winbind.so krb5_auth krb5_ccache_type=FILE cached_login try_first_pass
auth requisite pam_deny.so
auth required pam_permit.so
auth optional pam_mount.so

Didn't find what you were looking for?

Ask your question

Ask a Question

731 491 924 answers to any question