Unable to mount CIFS share using AutoFS and Kerberos












1















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.










share|improve this question

























  • 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 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











  • @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


















1















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.










share|improve this question

























  • 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 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











  • @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
















1












1








1








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.










share|improve this question
















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






share|improve this question















share|improve this question













share|improve this question




share|improve this question








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











  • @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













  • 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













  • 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












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
});


}
});














draft saved

draft discarded


















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
















draft saved

draft discarded




















































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.




draft saved


draft discarded














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





















































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







Popular posts from this blog

How to change which sound is reproduced for terminal bell?

Can I use Tabulator js library in my java Spring + Thymeleaf project?

Title Spacing in Bjornstrup Chapter, Removing Chapter Number From Contents