I have the same issue. Here is a related RedHat bug. It seems they fixed it, twice, and pushed two? patches upstream. The first attempt got merged, but their second more complete patch (that seems to address this scenario) seems to have gone missing.
In my case, the KRB5CCNAME variable in the user's calling process is not available, presumably due to the autofs intermediary?
Thus the environment scraping for the KRB5CCNAME fails, and as the ticket's filename has a random session specific suffix added to its filename, it cannot be found by cifs.upcall.
i.e, due to GSSAPI authentication via sshd, the ticket's filename is: KRB5CCNAME=FILE:/tmp/krb5cc_1001_XXXX9aLKwo. However, it is expected to be: FILE:/tmp/krb5cc_1001
Edited: While following up, I realized that while the RedHat bug's commentary implies there was a later, more complete fix, I could not find any such patch attached to that bug report.
I have the same issue. Here is a related RedHat bug. It seems they fixed it, twice, and pushed two? patches upstream. The first attempt got merged, but their second more complete patch (that seems to address this scenario) seems to have gone missing.
In my case, the KRB5CCNAME variable in the user's calling process is not available, presumably due to the autofs intermediary?
Thus the environment scraping for the KRB5CCNAME fails, and as the ticket's filename has a random session specific suffix added to its filename, it cannot be found by cifs.upcall.
i.e, due to GSSAPI authentication via sshd, the ticket's filename is: KRB5CCNAME= FILE:/tmp/ krb5cc_ 1001_XXXX9aLKwo . However, it is expected to be: FILE:/tmp/ krb5cc_ 1001
Here is the RedHat bug report: https:/ /bugzilla. redhat. com/show_ bug.cgi? id=517195
Edited: While following up, I realized that while the RedHat bug's commentary implies there was a later, more complete fix, I could not find any such patch attached to that bug report.