The issue occurs when make_homedir is set to true, and the user's home directory exists, but is currently not "visible" in the autofs mount due to no prior access.
When make_homedir is true, ThinLinc will always attempt to create the home directory during session startup. Normally, if this directory already exists, then we get EEXIST and carry on. But in the autofs case, if the directory is not "visible" yet, we get EPERM back instead. This is fatal and session creation fails.
Perhaps we can stat() the directory before trying to create it, in order to trigger the mount.
There is a discussion of this behaviour in Python with regards to autofs here: https://bugs.python.org/issue14702
Cendio bugs 2358 and 4621 are also related.
So this has changed wildly over the years.
Before bug 2358 this feature was disabled by default and so didn't affect most users. Rationale is unfortunately hidden in kom somewhere, so it is unknown why we considered this a better default. One guess is that many of the customers back then were using ThinLinc as a Windows front end without centralised home directories. Unsure why pam_mkhomedir wasn't a better idea.
Then on bug 4621 we changed the logic a bit to deal with /home that root wasn't allowed to access. As part of that restructuring we added compatibility code to deal with automount on Solaris. It also had the side effect of improving compatibility with automount on Linux as well. So at that point we didn't have any issue with autofs as mentioned on this bug.
But then on bug 3614 we removed support for Solaris and so the workaround for automount also went away as we weren't aware that it also had a purpose on Linux.