Unable to mount CIFS share using AutoFS and Kerberos
I can mount a CIFS share using mount
directly from my terminal:
sudo mount -t cifs -o multiuser,cruid=1395409773,vers=3.0,sec=krb5 //fileserver2.mba.ac.uk/Z Drive /mnt
shows the following in /var/log/syslog
:
Dec 14 10:58:36 L21SC646 cifs.upcall: key description: cifs.spnego;0;0;39010000;ver=0x2;host=fileserver2.mba.ac.uk;ip4=192.171.193.80;sec=krb5;uid=0x0;creduid=0x532c436d;user=root;pid=0x148d
Dec 14 10:58:36 L21SC646 cifs.upcall: ver=2
Dec 14 10:58:36 L21SC646 cifs.upcall: host=fileserver2.mba.ac.uk
Dec 14 10:58:36 L21SC646 cifs.upcall: ip=192.171.193.80
Dec 14 10:58:36 L21SC646 cifs.upcall: sec=1
Dec 14 10:58:36 L21SC646 cifs.upcall: uid=0
Dec 14 10:58:36 L21SC646 cifs.upcall: creduid=1395409773
Dec 14 10:58:36 L21SC646 cifs.upcall: user=root
Dec 14 10:58:36 L21SC646 cifs.upcall: pid=5261
Dec 14 10:58:36 L21SC646 cifs.upcall: get_cachename_from_process_env: pathname=/proc/5261/environ
Dec 14 10:58:36 L21SC646 cifs.upcall: get_cachename_from_process_env: cachename = FILE:/tmp/krb5cc_1395409773_yINoep
Dec 14 10:58:36 L21SC646 cifs.upcall: get_existing_cc: default ccache is FILE:/tmp/krb5cc_1395409773_yINoep
Dec 14 10:58:36 L21SC646 cifs.upcall: handle_krb5_mech: getting service ticket for fileserver2.mba.ac.uk
Dec 14 10:58:36 L21SC646 cifs.upcall: handle_krb5_mech: obtained service ticket
Dec 14 10:58:36 L21SC646 cifs.upcall: Exit status 0
But ls /cifs/Z
which should automount the same share:
Dec 14 10:58:53 L21SC646 automount[4910]: attempting to mount entry /cifs/Z
Dec 14 10:58:53 L21SC646 cifs.upcall: key description: cifs.spnego;0;0;39010000;ver=0x2;host=fileserver2.mba.ac.uk;ip4=192.171.193.80;sec=krb5;uid=0x0;creduid=0x532c436d;user=root;pid=0x149f
Dec 14 10:58:53 L21SC646 cifs.upcall: ver=2
Dec 14 10:58:53 L21SC646 cifs.upcall: host=fileserver2.mba.ac.uk
Dec 14 10:58:53 L21SC646 cifs.upcall: ip=192.171.193.80
Dec 14 10:58:53 L21SC646 cifs.upcall: sec=1
Dec 14 10:58:53 L21SC646 cifs.upcall: uid=0
Dec 14 10:58:53 L21SC646 cifs.upcall: creduid=1395409773
Dec 14 10:58:53 L21SC646 cifs.upcall: user=root
Dec 14 10:58:53 L21SC646 cifs.upcall: pid=5279
Dec 14 10:58:53 L21SC646 cifs.upcall: get_cachename_from_process_env: pathname=/proc/5279/environ
Dec 14 10:58:53 L21SC646 cifs.upcall: get_existing_cc: default ccache is FILE:/tmp/krb5cc_1395409773
Dec 14 10:58:53 L21SC646 cifs.upcall: get_tgt_time: unable to get principal
Dec 14 10:58:53 L21SC646 cifs.upcall: krb5_get_init_creds_keytab: -1765328378
Dec 14 10:58:53 L21SC646 cifs.upcall: Exit status 1
Dec 14 10:58:53 L21SC646 automount[4910]: >> mount error(126): Required key not available
Dec 14 10:58:53 L21SC646 automount[4910]: >> Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)
Dec 14 10:58:53 L21SC646 automount[4910]: mount(generic): failed to mount //fileserver2.mba.ac.uk/Z Drive (type cifs) on /cifs/Z
Dec 14 10:58:53 L21SC646 automount[4910]: failed to mount /cifs/Z
Dec 14 10:58:53 L21SC646 automount[4910]: re-reading map for /cifs
Dec 14 10:58:53 L21SC646 kernel: [ 4190.521151] CIFS VFS: Send error in SessSetup = -126
Dec 14 10:58:53 L21SC646 kernel: [ 4190.521164] CIFS VFS: cifs_mount failed w/return code = -126
It is quite obvious what's happening. The working mount reports:
get_cachename_from_process_env: cachename = FILE:/tmp/krb5cc_1395409773_yINoep
get_existing_cc: default ccache is FILE:/tmp/krb5cc_1395409773_yINoep
while the failing mount reports:
get_existing_cc: default ccache is FILE:/tmp/krb5cc_1395409773
Implying that it didn't find that environment variable. I'm at a loss, though, to figure what needs to be modified to make the AutoFS mount add that little bit of sugar after the UID in the temp file name. After all, the correct filename is in the environment of the bash process that issued both the working mount, and the ls
command that failed to mount.
automount cifs kerberos
add a comment |
I can mount a CIFS share using mount
directly from my terminal:
sudo mount -t cifs -o multiuser,cruid=1395409773,vers=3.0,sec=krb5 //fileserver2.mba.ac.uk/Z Drive /mnt
shows the following in /var/log/syslog
:
Dec 14 10:58:36 L21SC646 cifs.upcall: key description: cifs.spnego;0;0;39010000;ver=0x2;host=fileserver2.mba.ac.uk;ip4=192.171.193.80;sec=krb5;uid=0x0;creduid=0x532c436d;user=root;pid=0x148d
Dec 14 10:58:36 L21SC646 cifs.upcall: ver=2
Dec 14 10:58:36 L21SC646 cifs.upcall: host=fileserver2.mba.ac.uk
Dec 14 10:58:36 L21SC646 cifs.upcall: ip=192.171.193.80
Dec 14 10:58:36 L21SC646 cifs.upcall: sec=1
Dec 14 10:58:36 L21SC646 cifs.upcall: uid=0
Dec 14 10:58:36 L21SC646 cifs.upcall: creduid=1395409773
Dec 14 10:58:36 L21SC646 cifs.upcall: user=root
Dec 14 10:58:36 L21SC646 cifs.upcall: pid=5261
Dec 14 10:58:36 L21SC646 cifs.upcall: get_cachename_from_process_env: pathname=/proc/5261/environ
Dec 14 10:58:36 L21SC646 cifs.upcall: get_cachename_from_process_env: cachename = FILE:/tmp/krb5cc_1395409773_yINoep
Dec 14 10:58:36 L21SC646 cifs.upcall: get_existing_cc: default ccache is FILE:/tmp/krb5cc_1395409773_yINoep
Dec 14 10:58:36 L21SC646 cifs.upcall: handle_krb5_mech: getting service ticket for fileserver2.mba.ac.uk
Dec 14 10:58:36 L21SC646 cifs.upcall: handle_krb5_mech: obtained service ticket
Dec 14 10:58:36 L21SC646 cifs.upcall: Exit status 0
But ls /cifs/Z
which should automount the same share:
Dec 14 10:58:53 L21SC646 automount[4910]: attempting to mount entry /cifs/Z
Dec 14 10:58:53 L21SC646 cifs.upcall: key description: cifs.spnego;0;0;39010000;ver=0x2;host=fileserver2.mba.ac.uk;ip4=192.171.193.80;sec=krb5;uid=0x0;creduid=0x532c436d;user=root;pid=0x149f
Dec 14 10:58:53 L21SC646 cifs.upcall: ver=2
Dec 14 10:58:53 L21SC646 cifs.upcall: host=fileserver2.mba.ac.uk
Dec 14 10:58:53 L21SC646 cifs.upcall: ip=192.171.193.80
Dec 14 10:58:53 L21SC646 cifs.upcall: sec=1
Dec 14 10:58:53 L21SC646 cifs.upcall: uid=0
Dec 14 10:58:53 L21SC646 cifs.upcall: creduid=1395409773
Dec 14 10:58:53 L21SC646 cifs.upcall: user=root
Dec 14 10:58:53 L21SC646 cifs.upcall: pid=5279
Dec 14 10:58:53 L21SC646 cifs.upcall: get_cachename_from_process_env: pathname=/proc/5279/environ
Dec 14 10:58:53 L21SC646 cifs.upcall: get_existing_cc: default ccache is FILE:/tmp/krb5cc_1395409773
Dec 14 10:58:53 L21SC646 cifs.upcall: get_tgt_time: unable to get principal
Dec 14 10:58:53 L21SC646 cifs.upcall: krb5_get_init_creds_keytab: -1765328378
Dec 14 10:58:53 L21SC646 cifs.upcall: Exit status 1
Dec 14 10:58:53 L21SC646 automount[4910]: >> mount error(126): Required key not available
Dec 14 10:58:53 L21SC646 automount[4910]: >> Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)
Dec 14 10:58:53 L21SC646 automount[4910]: mount(generic): failed to mount //fileserver2.mba.ac.uk/Z Drive (type cifs) on /cifs/Z
Dec 14 10:58:53 L21SC646 automount[4910]: failed to mount /cifs/Z
Dec 14 10:58:53 L21SC646 automount[4910]: re-reading map for /cifs
Dec 14 10:58:53 L21SC646 kernel: [ 4190.521151] CIFS VFS: Send error in SessSetup = -126
Dec 14 10:58:53 L21SC646 kernel: [ 4190.521164] CIFS VFS: cifs_mount failed w/return code = -126
It is quite obvious what's happening. The working mount reports:
get_cachename_from_process_env: cachename = FILE:/tmp/krb5cc_1395409773_yINoep
get_existing_cc: default ccache is FILE:/tmp/krb5cc_1395409773_yINoep
while the failing mount reports:
get_existing_cc: default ccache is FILE:/tmp/krb5cc_1395409773
Implying that it didn't find that environment variable. I'm at a loss, though, to figure what needs to be modified to make the AutoFS mount add that little bit of sugar after the UID in the temp file name. After all, the correct filename is in the environment of the bash process that issued both the working mount, and the ls
command that failed to mount.
automount cifs kerberos
It's interesting to note that RedHat appears to have madecifs.upcall
scan the whole krb5 cache directory to avoid this sort of problem years ago (in 2010! bugzilla.redhat.com/show_bug.cgi?id=517195).
– Auspex
Dec 14 '18 at 16:54
Is it possible you are trying to do that while logged in through ssh with ticket forwarding enabled?
– Sebastian Stark
Dec 17 '18 at 8:34
@SebastianStark No, this is a desktop GUI (usinglxdm
as the login manager, because I can't make eitherlightdm
orsddm
work with Active Directory authentication andsssd
). The simple solution would seem to be to change thesssd
config to usekrb5_ccname_template=FILE:%d/krb5cc_%U
, but I figure there's probably a good reason why that's not the default :-)
– Auspex
Dec 17 '18 at 11:56
I am doing exactly that (krb5_ccname... in sssd.conf), but sshd won't follow it, so ssh-forwarded tickets won't work for smb automounts, that's why I was asking.
– Sebastian Stark
Dec 17 '18 at 12:38
@SebastianStark Good to know that. I'm not in need of smb automounts on my sssh'd machines, yet: but that's next!
– Auspex
Dec 17 '18 at 12:56
add a comment |
I can mount a CIFS share using mount
directly from my terminal:
sudo mount -t cifs -o multiuser,cruid=1395409773,vers=3.0,sec=krb5 //fileserver2.mba.ac.uk/Z Drive /mnt
shows the following in /var/log/syslog
:
Dec 14 10:58:36 L21SC646 cifs.upcall: key description: cifs.spnego;0;0;39010000;ver=0x2;host=fileserver2.mba.ac.uk;ip4=192.171.193.80;sec=krb5;uid=0x0;creduid=0x532c436d;user=root;pid=0x148d
Dec 14 10:58:36 L21SC646 cifs.upcall: ver=2
Dec 14 10:58:36 L21SC646 cifs.upcall: host=fileserver2.mba.ac.uk
Dec 14 10:58:36 L21SC646 cifs.upcall: ip=192.171.193.80
Dec 14 10:58:36 L21SC646 cifs.upcall: sec=1
Dec 14 10:58:36 L21SC646 cifs.upcall: uid=0
Dec 14 10:58:36 L21SC646 cifs.upcall: creduid=1395409773
Dec 14 10:58:36 L21SC646 cifs.upcall: user=root
Dec 14 10:58:36 L21SC646 cifs.upcall: pid=5261
Dec 14 10:58:36 L21SC646 cifs.upcall: get_cachename_from_process_env: pathname=/proc/5261/environ
Dec 14 10:58:36 L21SC646 cifs.upcall: get_cachename_from_process_env: cachename = FILE:/tmp/krb5cc_1395409773_yINoep
Dec 14 10:58:36 L21SC646 cifs.upcall: get_existing_cc: default ccache is FILE:/tmp/krb5cc_1395409773_yINoep
Dec 14 10:58:36 L21SC646 cifs.upcall: handle_krb5_mech: getting service ticket for fileserver2.mba.ac.uk
Dec 14 10:58:36 L21SC646 cifs.upcall: handle_krb5_mech: obtained service ticket
Dec 14 10:58:36 L21SC646 cifs.upcall: Exit status 0
But ls /cifs/Z
which should automount the same share:
Dec 14 10:58:53 L21SC646 automount[4910]: attempting to mount entry /cifs/Z
Dec 14 10:58:53 L21SC646 cifs.upcall: key description: cifs.spnego;0;0;39010000;ver=0x2;host=fileserver2.mba.ac.uk;ip4=192.171.193.80;sec=krb5;uid=0x0;creduid=0x532c436d;user=root;pid=0x149f
Dec 14 10:58:53 L21SC646 cifs.upcall: ver=2
Dec 14 10:58:53 L21SC646 cifs.upcall: host=fileserver2.mba.ac.uk
Dec 14 10:58:53 L21SC646 cifs.upcall: ip=192.171.193.80
Dec 14 10:58:53 L21SC646 cifs.upcall: sec=1
Dec 14 10:58:53 L21SC646 cifs.upcall: uid=0
Dec 14 10:58:53 L21SC646 cifs.upcall: creduid=1395409773
Dec 14 10:58:53 L21SC646 cifs.upcall: user=root
Dec 14 10:58:53 L21SC646 cifs.upcall: pid=5279
Dec 14 10:58:53 L21SC646 cifs.upcall: get_cachename_from_process_env: pathname=/proc/5279/environ
Dec 14 10:58:53 L21SC646 cifs.upcall: get_existing_cc: default ccache is FILE:/tmp/krb5cc_1395409773
Dec 14 10:58:53 L21SC646 cifs.upcall: get_tgt_time: unable to get principal
Dec 14 10:58:53 L21SC646 cifs.upcall: krb5_get_init_creds_keytab: -1765328378
Dec 14 10:58:53 L21SC646 cifs.upcall: Exit status 1
Dec 14 10:58:53 L21SC646 automount[4910]: >> mount error(126): Required key not available
Dec 14 10:58:53 L21SC646 automount[4910]: >> Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)
Dec 14 10:58:53 L21SC646 automount[4910]: mount(generic): failed to mount //fileserver2.mba.ac.uk/Z Drive (type cifs) on /cifs/Z
Dec 14 10:58:53 L21SC646 automount[4910]: failed to mount /cifs/Z
Dec 14 10:58:53 L21SC646 automount[4910]: re-reading map for /cifs
Dec 14 10:58:53 L21SC646 kernel: [ 4190.521151] CIFS VFS: Send error in SessSetup = -126
Dec 14 10:58:53 L21SC646 kernel: [ 4190.521164] CIFS VFS: cifs_mount failed w/return code = -126
It is quite obvious what's happening. The working mount reports:
get_cachename_from_process_env: cachename = FILE:/tmp/krb5cc_1395409773_yINoep
get_existing_cc: default ccache is FILE:/tmp/krb5cc_1395409773_yINoep
while the failing mount reports:
get_existing_cc: default ccache is FILE:/tmp/krb5cc_1395409773
Implying that it didn't find that environment variable. I'm at a loss, though, to figure what needs to be modified to make the AutoFS mount add that little bit of sugar after the UID in the temp file name. After all, the correct filename is in the environment of the bash process that issued both the working mount, and the ls
command that failed to mount.
automount cifs kerberos
I can mount a CIFS share using mount
directly from my terminal:
sudo mount -t cifs -o multiuser,cruid=1395409773,vers=3.0,sec=krb5 //fileserver2.mba.ac.uk/Z Drive /mnt
shows the following in /var/log/syslog
:
Dec 14 10:58:36 L21SC646 cifs.upcall: key description: cifs.spnego;0;0;39010000;ver=0x2;host=fileserver2.mba.ac.uk;ip4=192.171.193.80;sec=krb5;uid=0x0;creduid=0x532c436d;user=root;pid=0x148d
Dec 14 10:58:36 L21SC646 cifs.upcall: ver=2
Dec 14 10:58:36 L21SC646 cifs.upcall: host=fileserver2.mba.ac.uk
Dec 14 10:58:36 L21SC646 cifs.upcall: ip=192.171.193.80
Dec 14 10:58:36 L21SC646 cifs.upcall: sec=1
Dec 14 10:58:36 L21SC646 cifs.upcall: uid=0
Dec 14 10:58:36 L21SC646 cifs.upcall: creduid=1395409773
Dec 14 10:58:36 L21SC646 cifs.upcall: user=root
Dec 14 10:58:36 L21SC646 cifs.upcall: pid=5261
Dec 14 10:58:36 L21SC646 cifs.upcall: get_cachename_from_process_env: pathname=/proc/5261/environ
Dec 14 10:58:36 L21SC646 cifs.upcall: get_cachename_from_process_env: cachename = FILE:/tmp/krb5cc_1395409773_yINoep
Dec 14 10:58:36 L21SC646 cifs.upcall: get_existing_cc: default ccache is FILE:/tmp/krb5cc_1395409773_yINoep
Dec 14 10:58:36 L21SC646 cifs.upcall: handle_krb5_mech: getting service ticket for fileserver2.mba.ac.uk
Dec 14 10:58:36 L21SC646 cifs.upcall: handle_krb5_mech: obtained service ticket
Dec 14 10:58:36 L21SC646 cifs.upcall: Exit status 0
But ls /cifs/Z
which should automount the same share:
Dec 14 10:58:53 L21SC646 automount[4910]: attempting to mount entry /cifs/Z
Dec 14 10:58:53 L21SC646 cifs.upcall: key description: cifs.spnego;0;0;39010000;ver=0x2;host=fileserver2.mba.ac.uk;ip4=192.171.193.80;sec=krb5;uid=0x0;creduid=0x532c436d;user=root;pid=0x149f
Dec 14 10:58:53 L21SC646 cifs.upcall: ver=2
Dec 14 10:58:53 L21SC646 cifs.upcall: host=fileserver2.mba.ac.uk
Dec 14 10:58:53 L21SC646 cifs.upcall: ip=192.171.193.80
Dec 14 10:58:53 L21SC646 cifs.upcall: sec=1
Dec 14 10:58:53 L21SC646 cifs.upcall: uid=0
Dec 14 10:58:53 L21SC646 cifs.upcall: creduid=1395409773
Dec 14 10:58:53 L21SC646 cifs.upcall: user=root
Dec 14 10:58:53 L21SC646 cifs.upcall: pid=5279
Dec 14 10:58:53 L21SC646 cifs.upcall: get_cachename_from_process_env: pathname=/proc/5279/environ
Dec 14 10:58:53 L21SC646 cifs.upcall: get_existing_cc: default ccache is FILE:/tmp/krb5cc_1395409773
Dec 14 10:58:53 L21SC646 cifs.upcall: get_tgt_time: unable to get principal
Dec 14 10:58:53 L21SC646 cifs.upcall: krb5_get_init_creds_keytab: -1765328378
Dec 14 10:58:53 L21SC646 cifs.upcall: Exit status 1
Dec 14 10:58:53 L21SC646 automount[4910]: >> mount error(126): Required key not available
Dec 14 10:58:53 L21SC646 automount[4910]: >> Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)
Dec 14 10:58:53 L21SC646 automount[4910]: mount(generic): failed to mount //fileserver2.mba.ac.uk/Z Drive (type cifs) on /cifs/Z
Dec 14 10:58:53 L21SC646 automount[4910]: failed to mount /cifs/Z
Dec 14 10:58:53 L21SC646 automount[4910]: re-reading map for /cifs
Dec 14 10:58:53 L21SC646 kernel: [ 4190.521151] CIFS VFS: Send error in SessSetup = -126
Dec 14 10:58:53 L21SC646 kernel: [ 4190.521164] CIFS VFS: cifs_mount failed w/return code = -126
It is quite obvious what's happening. The working mount reports:
get_cachename_from_process_env: cachename = FILE:/tmp/krb5cc_1395409773_yINoep
get_existing_cc: default ccache is FILE:/tmp/krb5cc_1395409773_yINoep
while the failing mount reports:
get_existing_cc: default ccache is FILE:/tmp/krb5cc_1395409773
Implying that it didn't find that environment variable. I'm at a loss, though, to figure what needs to be modified to make the AutoFS mount add that little bit of sugar after the UID in the temp file name. After all, the correct filename is in the environment of the bash process that issued both the working mount, and the ls
command that failed to mount.
automount cifs kerberos
automount cifs kerberos
edited Dec 14 '18 at 14:00
Auspex
asked Dec 14 '18 at 11:21
AuspexAuspex
397312
397312
It's interesting to note that RedHat appears to have madecifs.upcall
scan the whole krb5 cache directory to avoid this sort of problem years ago (in 2010! bugzilla.redhat.com/show_bug.cgi?id=517195).
– Auspex
Dec 14 '18 at 16:54
Is it possible you are trying to do that while logged in through ssh with ticket forwarding enabled?
– Sebastian Stark
Dec 17 '18 at 8:34
@SebastianStark No, this is a desktop GUI (usinglxdm
as the login manager, because I can't make eitherlightdm
orsddm
work with Active Directory authentication andsssd
). The simple solution would seem to be to change thesssd
config to usekrb5_ccname_template=FILE:%d/krb5cc_%U
, but I figure there's probably a good reason why that's not the default :-)
– Auspex
Dec 17 '18 at 11:56
I am doing exactly that (krb5_ccname... in sssd.conf), but sshd won't follow it, so ssh-forwarded tickets won't work for smb automounts, that's why I was asking.
– Sebastian Stark
Dec 17 '18 at 12:38
@SebastianStark Good to know that. I'm not in need of smb automounts on my sssh'd machines, yet: but that's next!
– Auspex
Dec 17 '18 at 12:56
add a comment |
It's interesting to note that RedHat appears to have madecifs.upcall
scan the whole krb5 cache directory to avoid this sort of problem years ago (in 2010! bugzilla.redhat.com/show_bug.cgi?id=517195).
– Auspex
Dec 14 '18 at 16:54
Is it possible you are trying to do that while logged in through ssh with ticket forwarding enabled?
– Sebastian Stark
Dec 17 '18 at 8:34
@SebastianStark No, this is a desktop GUI (usinglxdm
as the login manager, because I can't make eitherlightdm
orsddm
work with Active Directory authentication andsssd
). The simple solution would seem to be to change thesssd
config to usekrb5_ccname_template=FILE:%d/krb5cc_%U
, but I figure there's probably a good reason why that's not the default :-)
– Auspex
Dec 17 '18 at 11:56
I am doing exactly that (krb5_ccname... in sssd.conf), but sshd won't follow it, so ssh-forwarded tickets won't work for smb automounts, that's why I was asking.
– Sebastian Stark
Dec 17 '18 at 12:38
@SebastianStark Good to know that. I'm not in need of smb automounts on my sssh'd machines, yet: but that's next!
– Auspex
Dec 17 '18 at 12:56
It's interesting to note that RedHat appears to have made
cifs.upcall
scan the whole krb5 cache directory to avoid this sort of problem years ago (in 2010! bugzilla.redhat.com/show_bug.cgi?id=517195).– Auspex
Dec 14 '18 at 16:54
It's interesting to note that RedHat appears to have made
cifs.upcall
scan the whole krb5 cache directory to avoid this sort of problem years ago (in 2010! bugzilla.redhat.com/show_bug.cgi?id=517195).– Auspex
Dec 14 '18 at 16:54
Is it possible you are trying to do that while logged in through ssh with ticket forwarding enabled?
– Sebastian Stark
Dec 17 '18 at 8:34
Is it possible you are trying to do that while logged in through ssh with ticket forwarding enabled?
– Sebastian Stark
Dec 17 '18 at 8:34
@SebastianStark No, this is a desktop GUI (using
lxdm
as the login manager, because I can't make either lightdm
or sddm
work with Active Directory authentication and sssd
). The simple solution would seem to be to change the sssd
config to use krb5_ccname_template=FILE:%d/krb5cc_%U
, but I figure there's probably a good reason why that's not the default :-)– Auspex
Dec 17 '18 at 11:56
@SebastianStark No, this is a desktop GUI (using
lxdm
as the login manager, because I can't make either lightdm
or sddm
work with Active Directory authentication and sssd
). The simple solution would seem to be to change the sssd
config to use krb5_ccname_template=FILE:%d/krb5cc_%U
, but I figure there's probably a good reason why that's not the default :-)– Auspex
Dec 17 '18 at 11:56
I am doing exactly that (krb5_ccname... in sssd.conf), but sshd won't follow it, so ssh-forwarded tickets won't work for smb automounts, that's why I was asking.
– Sebastian Stark
Dec 17 '18 at 12:38
I am doing exactly that (krb5_ccname... in sssd.conf), but sshd won't follow it, so ssh-forwarded tickets won't work for smb automounts, that's why I was asking.
– Sebastian Stark
Dec 17 '18 at 12:38
@SebastianStark Good to know that. I'm not in need of smb automounts on my sssh'd machines, yet: but that's next!
– Auspex
Dec 17 '18 at 12:56
@SebastianStark Good to know that. I'm not in need of smb automounts on my sssh'd machines, yet: but that's next!
– Auspex
Dec 17 '18 at 12:56
add a comment |
0
active
oldest
votes
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "89"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f1100841%2funable-to-mount-cifs-share-using-autofs-and-kerberos%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
0
active
oldest
votes
0
active
oldest
votes
active
oldest
votes
active
oldest
votes
Thanks for contributing an answer to Ask Ubuntu!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f1100841%2funable-to-mount-cifs-share-using-autofs-and-kerberos%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
It's interesting to note that RedHat appears to have made
cifs.upcall
scan the whole krb5 cache directory to avoid this sort of problem years ago (in 2010! bugzilla.redhat.com/show_bug.cgi?id=517195).– Auspex
Dec 14 '18 at 16:54
Is it possible you are trying to do that while logged in through ssh with ticket forwarding enabled?
– Sebastian Stark
Dec 17 '18 at 8:34
@SebastianStark No, this is a desktop GUI (using
lxdm
as the login manager, because I can't make eitherlightdm
orsddm
work with Active Directory authentication andsssd
). The simple solution would seem to be to change thesssd
config to usekrb5_ccname_template=FILE:%d/krb5cc_%U
, but I figure there's probably a good reason why that's not the default :-)– Auspex
Dec 17 '18 at 11:56
I am doing exactly that (krb5_ccname... in sssd.conf), but sshd won't follow it, so ssh-forwarded tickets won't work for smb automounts, that's why I was asking.
– Sebastian Stark
Dec 17 '18 at 12:38
@SebastianStark Good to know that. I'm not in need of smb automounts on my sssh'd machines, yet: but that's next!
– Auspex
Dec 17 '18 at 12:56