Ich habe eine andere Antwort auf die Frage, die mich plagte, bevor ich das Problem herausgefunden habe. Das Problem ist ein Fehler in Fedora OS und seinen Derivaten, wie ich später herausgefunden habe. Wenn das Problem nicht mit der akzeptierten Antwort übereinstimmt und / oder Sie nicht mit Fedora, RedHat, Korora usw. arbeiten, hilft Ihnen dies nicht weiter.
Das Problem
Wie der Benutzer slm sagte, gibt Ihnen das Ausführen von strace einen Hinweis auf das Problem. In diesem speziellen Fall ist die Ausgabe jedoch anders:
$ 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)
...
Um klar zu sein, besagt dies, dass der EACCES-Rückgabecode, dem die Berechtigung verweigert wurde. Dies unterscheidet sich vom Problem des Benutzers slm, bei dem er den EEXIST-Rückkehrcode hatte, was bedeutet, dass die Datei vorhanden ist. Für den EACCES-Rückkehrcode ist das erste, was Sie überprüfen, offensichtlich: Sind meine Home-Berechtigungen so eingerichtet, dass ich in mein Home-Verzeichnis schreiben kann? Sie sollten zunächst überprüfen, ob Sie das Schreibflag für Ihren eigenen Benutzer in Ihrem Ausgangsverzeichnis haben. Wenn Sie dies tun, sind Sie möglicherweise ein Opfer des nachfolgend beschriebenen Fehlers.
Der Käfer
Durch ein paar Google-Suchen konnte ich endlich jemanden mit einem ähnlichen Problem finden, und es führte mich zum Fedora-Fehlerbericht. Für diejenigen unter Ihnen, die darüber lesen möchten: möchten https://bugzilla.redhat.com/show_bug.cgi?id=772992
Die Problemumgehung
Die Problemumgehung für das Problem:
#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
Wenn Sie SSH wieder aktivieren, sollte dies zu diesem Zeitpunkt in Ordnung sein und Sie sollten in der Lage sein, Ihre X-Sitzung erneut erfolgreich zu übertragen.
EDIT (und andere alternative Problemumgehungen):
Um so vollständig wie möglich zu sein, gaben andere Benutzer im Fehlerbericht an, dass das oben genannte Update für sie nicht funktioniert hat - es hat für mich zufällig funktioniert. Ein weiterer Versuch, das Problem zu umgehen, war (ich habe diese Problemumgehung nicht persönlich überprüft):
# setsebool -P use_nfs_home_dirs 1
Eine andere Person erwähnt etwas über GDM, von dem ich nichts weiß. In diesem Fall empfehle ich, seinen Beitrag in BugZilla zu lesen und zu prüfen, ob sein Kommentar etwas für Sie bedeutet.
