Ho un'altra risposta alla domanda che mi ha afflitto prima di capire il problema. Il problema è un bug nel sistema operativo Fedora ed è derivato, come ho capito in seguito. Se il problema non è come indicato dalla risposta accettata e / o non sei su Fedora, RedHat, Korora, ecc., Questo non ti aiuterà.
Il problema
Come ha detto l'utente slm, l'esecuzione di strace ti darà un'indicazione del problema, ma nel caso di questo particolare bug, l'output è diverso:
$ 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)
...
Per essere chiari, questo sta affermando che il codice di ritorno EACCES, che è stato negato l'autorizzazione. Questo è diverso dal problema dell'utente slm, in cui aveva il codice di ritorno EEXIST, il che significa che esiste un file. Quindi, per il codice di ritorno EACCES, ovviamente la prima cosa che controlli è: i miei permessi di casa sono impostati in modo da poter scrivere nella mia directory di casa? Dovresti prima verificare di avere il flag di scrittura nella tua home directory per il tuo utente. In tal caso, potresti essere vittima del bug descritto di seguito.
Il bug
Attraverso un paio di ricerche su Google sono stato finalmente in grado di trovare qualcuno con un problema simile, e questo mi ha portato alla segnalazione di bug di Fedora. Per quelli di voi che vogliono leggerlo: https://bugzilla.redhat.com/show_bug.cgi?id=772992
La soluzione alternativa
La soluzione alternativa al problema:
#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
Quando rientri in SSH, dovrebbe andare bene a questo punto e dovresti essere in grado di trasferire nuovamente la tua X-session.
EDIT (e altre soluzioni alternative):
Per essere il più completo possibile, altri utenti hanno dichiarato nella segnalazione di bug che la correzione sopra non ha funzionato per loro - è successo per me. Un altro tentativo di aggirare il problema è stato (non ho verificato personalmente questa soluzione alternativa):
# setsebool -P use_nfs_home_dirs 1
Un'altra persona menziona qualcosa su GDM, di cui non ho conoscenza. Se questo è per te, ti consiglio di leggere il suo post su BugZilla e di vedere se il suo commento significa qualcosa per te.
