/usr/bin/xauth cannot lock .Xauthority?

It was reported as BUG 649550 on Redhat Bugzilla that some users complained that they could not establish a graphical connection to their servers since when they log in with ssh -X or ssh -Y, the terminal spitted out an error that it cannot lock ~/.Xauthority file.
This issue has been out there for years and many ways like relabelling selinux, remove .Xauthority, updating the xclient software so that it won’t need .Xauthourity-c file, etc., however always there are people who complained that nothing worked.
It is sure that this is a selinux issue since once you disable selinux and reboot the server, this issue always resolves.
However, this is not an acceptable solution since selinux has its reason to be enabled.
The problem is, that such denial was never caught by the auditing mechanism of selinux, you are clueless what new rules should be added in the local policy.
After intensive debugging, I found a new cause of this. Here is the detail.
On a scalable system, you have multiple servers, and your user profiles might have been scattered on multiple file servers. For the convenience of maintenance, you created links in /home/ to redirect user profiles to their actual location. You are sure that the selinux labeling of user profiles and user directories are correct. However, the links are out of your radar. They were left as default_t although their targets are user_home_dir_t. The selinux was puzzled by this inconsistency and refused to proceed as well did not report this denial, leaving an unuseable system. However, except for on the file server, all nfs maps system will be fine since selinux allows xauth to go through nfs_t.
Now the solution is obvious:
Do
chcon -h -t user_home_dir_t /home/*
to reassign all links in /home/ to their rightful labels.
Problem solved.