Mam inną odpowiedź na pytanie, które nękało mnie, zanim zrozumiałem problem. Problemem jest błąd w systemie operacyjnym Fedory i jego pochodnych, jak się później zorientowałem. Jeśli problem nie jest taki, jak wskazano w zaakceptowanej odpowiedzi i / lub nie korzystasz z Fedory, RedHat, Korory itp., To ci to nie pomoże.
Problem
Jak powiedział slm użytkownika, uruchomienie strace da ci wskazanie problemu, ale w tym konkretnym przypadku błędu, wynik jest inny:
$ 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)
...
Żeby było jasne, oznacza to, że kod powrotu EACCES, który jest odmowa zgody. Różni się to od problemu użytkownika slm, w którym miał kod powrotu EEXIST, co oznacza, że plik istnieje. Tak więc, w przypadku kodu powrotu EACCES, pierwszą rzeczą, którą sprawdzasz, jest: czy skonfigurowano moje uprawnienia do domu, aby móc pisać w moim katalogu domowym? Najpierw powinieneś sprawdzić, czy masz flagę zapisu w swoim katalogu domowym dla własnego użytkownika. Jeśli to zrobisz, możesz być ofiarą opisanego poniżej błędu.
Bug
Przez kilka wyszukiwań w Google udało mi się w końcu znaleźć kogoś z podobnym problemem, co doprowadziło mnie do zgłoszenia błędu Fedory. Dla tych z Was, którzy chcą o tym przeczytać: https://bugzilla.redhat.com/show_bug.cgi?id=772992
Obejście
Obejście problemu:
#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
Gdy ponownie włączysz SSH, w tym momencie powinno być w porządku i powinieneś być w stanie ponownie pomyślnie przenieść sesję X.
EDYCJA (i inne alternatywne obejścia):
Aby być jak najbardziej kompletnym, inni użytkownicy stwierdzili w raporcie o błędzie, że powyższa poprawka nie działała dla nich - zdarzyło się, że zadziałało dla mnie. Kolejną próbą obejścia tego problemu (osobiście nie zweryfikowałem tego obejścia):
# setsebool -P use_nfs_home_dirs 1
Inna osoba wspomina coś o GDM, o którym nie mam żadnej wiedzy. Jeśli to dotyczy ciebie, polecam przeczytanie jego postu w BugZilli i sprawdzenie, czy jego komentarz coś dla ciebie znaczy.
