2

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.

  • 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 get same problem on my ubuntu 18.04, For some unknown reason when systemd mount/automount try to mount the cifs destination, form:

get_cachename_from_process_env: pathname =
get_cachename_from_process_env: cachename =

get krb file with format

FILE:/tmp/krb5cc_%U

while system is using

FILE:/tmp/krb5cc_%U_XXXX (secure format)

If the template ends with 'XXXXXX' mkstemp(3) is used to create a unique filename in a safe way. 
Default: FILE:%d/krb5cc_%U_XXXXXX

SSSD Manual pages

As workaround on my system i using sssd as security Orchestrator and i for the system tu use FILE:%d/krb5cc_%U format, Modding sssd.config adding krb5_ccname_template=FILE:%d/krb5cc_%U inside [domain/DOMAIN.EXT] section.

  • +1 Thanks, this fixed our problem. Was the cause of our woes with Kubuntu 18.04 LTS and we weren't able to roll out a Kubuntu upgrade until this issue with AutoFS was fixed. – Bastion May 28 at 6:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.