У мене є ще одна відповідь на запитання, яке набридло мені ще до того, як я з'ясував це питання. Як пізніше я зрозумів, проблема полягає в помилках в OS 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-сеанс.
EDIT (та інші альтернативні способи вирішення):
Щоб бути максимально повною, інші користувачі заявляли у звіті про помилку, що виправлення вище не працювало для них - це сталося для мене. Ще одна спроба вирішити цю проблему була (я це не вирішував особисто):
# setsebool -P use_nfs_home_dirs 1
Інша людина згадує щось про GDM, про що я маю нульові знання. Якщо це стосується вас, я рекомендую прочитати його повідомлення в BugZilla і побачити, чи означає його коментар для вас щось.
