У меня есть другой ответ на вопрос, который мучил меня, прежде чем я выясню проблему. Проблема заключается в ошибке в ОС Fedora и ее производных, как я позже выяснил. Если проблема не указана в принятом ответе, и / или вы не используете Fedora, RedHat, Korora и т. Д., То это вам не поможет.
Проблема
Как сказал пользователь slm, запуск strace покажет вам проблему, но в данном конкретном случае ошибка будет другой:
$ strace xauth list
...
stat64("/home/USER/.Xauthority-c", 0xbff23280) = -1 ENOENT (No such file or directory)
open("/home/USER/.Xauthority-c", O_WRONLY|O_CREAT|O_EXCL, 0600) = -1 EACCES (Permission denied)
rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
rt_sigaction(SIGCHLD, NULL, {SIG_DFL, [], 0}, 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
nanosleep({2, 0}, 0xbff232c8) = 0
open("/home/USER/.Xauthority-c", O_WRONLY|O_CREAT|O_EXCL, 0600) = -1 EACCES (Permission denied)
rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
rt_sigaction(SIGCHLD, NULL, {SIG_DFL, [], 0}, 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
nanosleep({2, 0}, 0xbff232c8) = 0
open("/home/USER/.Xauthority-c", O_WRONLY|O_CREAT|O_EXCL, 0600) = -1 EACCES (Permission denied)
...
Чтобы было ясно, это говорит о том, что EACCES возвращает код, который запрещен. Это отличается от проблемы пользователя slm, где у него был код возврата EEXIST, что означает, что файл существует. Итак, для кода возврата EACCES, очевидно, первое, что вы проверяете: настроены ли мои домашние разрешения, чтобы я мог писать в свой домашний каталог? Сначала вы должны убедиться, что в вашем домашнем каталоге есть флаг записи для вашего собственного пользователя. Если вы это сделаете, то вы можете стать жертвой ошибки, описанной ниже.
Ошибка
Через пару поисков в Google я наконец смог найти кого-то с подобной проблемой, и это привело меня к сообщению об ошибке в Fedora. Для тех из вас, кто хочет прочитать об этом: https://bugzilla.redhat.com/show_bug.cgi?id=772992
Обходной путь
Обходной путь к проблеме:
#verify you're not crazy
$ xauth list
/usr/bin/xauth: timeout in locking authority file /home/USER/.Xauthority
#use restorecon to reset it all
$ /sbin/restorecon -v -v /home/USER/.Xauthority
$ /sbin/restorecon -v -v -R /home/USER/
#log out of the remote system
$ exit
Когда вы снова включите SSH, все будет хорошо, и вы сможете снова успешно перенести X-сессию.
РЕДАКТИРОВАТЬ (и другие альтернативные обходные пути):
Чтобы быть как можно более полными, другие пользователи указывали в отчете об ошибке, что приведенное выше исправление не работает для них - оно работает для меня. Другая попытка обойти проблему была (я не проверял этот обходной путь лично):
# setsebool -P use_nfs_home_dirs 1
Другой человек упоминает кое-что о GDM, о котором я ничего не знаю. Если это относится к вам, я рекомендую прочитать его пост в BugZilla и посмотреть, что его комментарий что-то значит для вас.
