Impossibile connettersi al server X: 0.0 come superutente

Quando sono online, visualizzo il seguente errore e lo strumento non si avvia:

[root@dhcppc9 lin64]# ./ise
No protocol specified
_pn: cannot connect to X server :0.0

Ma va tutto bene quando non sono un superutente. Perché quel?

modificare

[root@dhcppc9 lin64]# export $(dbus-launch)
No protocol specified

qualche suggerimento?

Anche

[root@dhcppc9 lin64]# xhost [+]
No protocol specified
xhost:  unable to open display ":0.0"

Un programma X necessita di due informazioni per connettersi a un display X.

• Richiede l'indirizzo del display, che in genere è :0quando si è connessi localmente o :10, :11ecc. Quando si è effettuato l'accesso in remoto (ma il numero può cambiare a seconda di quante connessioni X sono attive). L'indirizzo del display è normalmente indicato nella DISPLAYvariabile d'ambiente.

• Ha bisogno della password per il display. Le password di visualizzazione X sono chiamate cookie magici . I cookie magici non vengono specificati direttamente: sono sempre memorizzati in file di autorità X, che sono una raccolta di record del modulo "display :42has cookie 123456". Il file di autorità X viene normalmente indicato nella XAUTHORITYvariabile di ambiente. Se $XAUTHORITYnon impostato, i programmi usano ~/.Xauthority.

Vedere Apri una finestra su un display X remoto (perché "Impossibile aprire il display")? per ulteriori dettagli.

Nel tuo caso, DISPLAYè impostato ma i programmi evidentemente non riescono a trovare il file cookie. Controlla il valore di XAUTHORITYnella sessione e sotto su.

Se XAUTHORITYnon è impostato nella sessione e suimposta la HOMEvariabile di ambiente home directory di root, quindi è necessario impostare XAUTHORITYa /home/msz/.Xauthoritydove /home/mszè la vostra directory home.

Se viene surimosso XAUTHORITYdall'ambiente, ripristinalo o configura di sunon farlo.

Se la tua home directory si trova su alcuni filesystem come NFS, root potrebbe non essere in grado di leggerlo direttamente. In tal caso, è possibile copiare il .Xauthorityfile in una posizione diversa su un filesystem non NFS:

XAUTHORITY_COPY=$(umask 077; mktemp)
cat "${XAUTHORITY:-~/.Xauthority}" "$XAUTHORITY_COPY"
XAUTHORITY="$XAUTHORITY_COPY" su
rm "$XAUTHORITY_COPY"
unset XAUTHORITY_COPY

Stai eseguendo xhost come root!

eseguire xhost come utente normale xhost +, radice quindi diventare riprovare.

tra l'altro, come altri hanno sottolineato, xhost +consente a qualsiasi utente di qualsiasi host

XAUTHORITY per me è stato impostato come un file che non esisteva più:

$ echo $XAUTHORITY

/tmp/xauth-1000-_0

Così ho fatto

unset XAUTHORITY

ed è stato quindi in grado di connettermi alla mia app come root usando kdesudo (in questo caso kdesudo bleachbit)

Esegui come utente normale

xhost + localhost

quindi abilitare il superutente entro

sudo su 

finalmente vai all'esempio del server

cd /usr/local/Ampps

finalmente eseguito ./Ampps

grazie nel 2020

Questo ha funzionato per me in fedora 30

xhost local:root
sudo QT_X11_NO_MITSHM=1 /usr/bin/unetbootin