Come risolvere "Nessun protocollo specificato" per l'utente su

Sto cercando di utilizzare un utente alternativo (non amministratore) per eseguire software grafico sul mio sistema. A questo utente alternativo è stato assegnato un nome e UID e GID per corrispondere a un utente di sistema remoto con lo stesso nome. L'UID è 500, quindi credo che renda l'utente un utente 'non-login'.

A partire da Ubuntu ho effettuato l'accesso al mio account principale, ho aperto un terminale e sul'utente alternativo. Quindi tento di eseguire il comando per avviare l'applicazione e ricevere "Nessun protocollo specificato".

È a causa dell'UID <1000, a causa suo a causa del non amministratore dell'utente? Come posso ottenere questo utente per eseguire l'applicazione con una GUI?

Il problema non si verifica a causa dell'UID dell'utente. 500 va bene come UID e quell'UID non lo rende un utente "non-login" se non agli occhi delle impostazioni predefinite di alcuni gestori display.

Il messaggio di errore Nessun protocollo specificato suona come un messaggio di errore specifico dell'applicazione, ma inutile, ma suppongo che l'errore sia che l'applicazione non è in grado di contattare il display X11 perché non dispone dell'autorizzazione per farlo quindi perché funziona come un altro utente. Le applicazioni hanno bisogno di un "cookie magico" (token segreto) per comunicare con il server X11 in modo che altri processi sul sistema in esecuzione sotto altri utenti non possano intromettersi sul display, creare finestre e bloccare le sequenze di tasti. L'altro utente del sistema non ha accesso a questo cookie magico perché le autorizzazioni sono impostate in modo che sia accessibile solo all'utente che ha avviato l'ambiente desktop (che è come dovrebbe essere).

Prova questo, eseguendo come utente originale, per copiare il cookie X11 sull'altro account:

su - <otheruser> -c "unset XAUTHORITY; xauth add $(xauth list)"

quindi esegui la tua applicazione. Potrebbe anche essere necessario disinserire anche XAUTHORITYquella shell. Questo comando estrae il cookie magico ( xauth list) dal tuo utente principale e lo aggiunge ( xauth add) a dove l'altro utente può ottenerlo.

Nel mio caso il nuovo display server waylandera il problema,

basta fare xhost + local:quindi ad altri utenti (es. root) è consentito eseguire Programmi nella sessione, tuttavia le connessioni di rete non saranno consentite.

Se si desidera consentire ai client di qualsiasi host , è possibile utilizzare xhost +senza specificare alcun host. Tuttavia , ciò non è sicuro , sarebbe meglio specificare semplicemente l'host o gli host per i quali si desidera concedere l'accesso alla sessione.

Supponiamo che tu voglia forzare la forza per ottenere una connessione con X ...

Supponiamo che tu stia già eseguendo i tuoi comandi sul server (dove X viene eseguito), altrimenti fallo funzionare prima e poi usa 'ssh -X user @ server) dal client in seguito;).

Potrebbero esserci diversi modi per eseguire i comandi xauth, ad esempio, potresti usare "sudo", ma ciò potrebbe perdere o cambiare le variabili di ambiente. È necessario conservare le seguenti variabili di ambiente: DISPLAY e XAUTHORITY. Per verificare se è così, puoi eseguire 'echo $ XAUTHORITY' nello stesso modo in cui esegui i tuoi comandi, ma assicurati di non espandere le variabili di ambiente prima di eseguire quei comandi. Ad esempio, prova: sudo bash -c 'echo "$ XAUTHORITY"' per vedere cosa è realmente XAUTHORITY dopo aver eseguito il tuo sudo (se scompare potresti aver bisogno di aggiungere qualcosa al tuo file sudoers, vedi altrove).

Alla fine, esegui il seguente comando come l'utente con cui desideri accedere, sul server:

xauth info

Questo mostrerà il 'File di autorità' che verrà usato (/root/.Xauthority di default, per root, o qualcosa come /home/theuser/.Xauthority). Se mostra il file .Xauthority corretto, allora non devi preoccuparti della variabile di ambiente XAUTHORITY in realtà (in realtà, non saprei quando non lo farebbe, tranne se vuoi manipolare un posto non standard di quel file ).

Rimuovi quel file (se esiste):

rm /root/.Xauthority

Sostituisci /root/.Xauthoritycon il file XAUTHORITY corretto per il tuo caso.

Ricrealo, ma vuoto (questo è necessario per molti comandi):

touch /root/.Xauthority

A questo punto otterrai l' errore Nessun protocollo specificato , anche se in precedenza hai ricevuto MIT-MAGIC-COOKIE-1 non valido . Trova il file di autorità che il server X sta utilizzando al momento:

ps aux | grep Xorg

Questo dovrebbe mostrare qualcosa come:

root 1153 0.0 1.0 149560 44464 tty7 Ss+ dec02 0:00 /usr/lib/xorg/Xorg -nolisten tcp -auth /var/run/sddm/{ef18c483-7891-4e82-80ef-2c8f9bd79711} -background none -noreset -displayfd 17 vt7

Il nome del file dopo -authè quello che ti serve nel prossimo comando. Esegui come root:

sudo xauth -f '/var/run/sddm/{ef18c483-7891-4e82-80ef-2c8f9bd79711}' list

Questo elenca una chiave esadecimale a 32 cifre. Ad esempio, l'output potrebbe essere:

hostname/unix:0 MIT-MAGIC-COOKIE-1 c0eaf749aa252101a0f57d5087089db7

Usalo per generare il tuo file .Xauthority (come utente che deve accedere di nuovo):

xauth add $DISPLAY MIT-MAGIC-COOKIE-1 c0eaf749aa252101a0f57d5087089db7

sostituisci 'c0eaf749aa252101a0f57d5087089db7' con quello che ti è stato restituito dal comando list. Ora la tua .Xauthority dovrebbe avere una dimensione di 51 byte e puoi connetterti al server X (di nuovo).

Prova qualcosa del genere

$ export LOGIN_USER="Math"
$ su - $LOGIN_USER
$ sudo xhost local:$LOGIN_USER &>/dev/null

fonte

Ps : la risposta accettata non ha funzionato per me

Ho avuto questo errore "Nessun protocollo specificato" quando ho avviato un'istanza di Selenium 3.3.1 da uno script upstart e quindi ho utilizzato il driver Chrome in Selenium. Selenium ha funzionato come lo stesso utente di X11 e la variabile di ambiente shell DISPLAY è stata impostata correttamente. La cosa interessante è che questo errore non si è verificato quando ho usato il driver di Firefox. L'impostazione della variabile di ambiente della shell XAUTHORITY all'interno dello script upstart per puntare al valore di $ XAUTHORITY dell'utente X11 attivo ha corretto l'errore per il driver Chrome.

In una nota a margine, l'errore "Nessun protocollo specificato" è stato completamente sepolto dal driver Chrome / Chrome e non è stato affatto facile da trovare. Ho notato che Chrome ha continuato a creare directory nel modello di /tmp/.org.chromium.Chromium.*, ma stavano rapidamente scomparendo. Sono riuscito a notare che contenevano un file con il chrome_debug.logmessaggio "Impossibile aprire il display". Ho pensato che fosse piuttosto strano dato che ho verificato che il processo di selenio aveva il DISPLAY corretto /proc/$pid/environe ho esaminato l'output del straceprocesso di selenio in modo più approfondito, il che ha rivelato che "nessun protocollo specificato" mi ha portato alla fine a questa domanda.

Questo errore può essere riprodotto annullando XAUTHORITY e tentando di eseguire alcuni client X11. Per esempio:

$ XAUTHORITY= xeyes
No protocol specified
Error: Can't open display: :0.0

Questo è stato semplice. Il problema si verifica quando si è in stato di root e si desidera utilizzare gksu Basta uscire dallo stato di root e riprovare

Digita questo nel tuo terminale xhost +SI:localuser:rootdopo aver digitato, export DISPLAY=:0.0quindi riprova

Utilizzando gli indizi nelle risposte accettate, sono stato in grado di risolvere il problema in modo diverso:

1. Individua il file Xauth nell'account che funziona (Xauth1)
2. Individua il file Xauth nell'account che non lo fa (Xauth2)
3. Copia Xauth1 in Xauth2
4. Modifica le autorizzazioni di Xauth2

Nel codice:

root@45c4933a8f1a:~# xauth info
Authority file:       /headless/.Xauthority
<snip>
root@45c4933a8f1a:~# su OtherUser
OtherUser@45c4933a8f1a:/headless$ xauth info
Authority file:       /home/OtherUser/.Xauthority
<snip>
OtherUser@45c4933a8f1a:/headless$ exit
exit
root@45c4933a8f1a:~# cp /headless/.Xauthority /home/OtherUser/.Xauthority 
root@45c4933a8f1a:~# chown OtherUser:OtherUser /home/OtherUser/.Xauthority
root@45c4933a8f1a:~# su OtherUser

Supponiamo che provi ad accedere alla GUI come utente2 ( utente normale ), quindi devi caricare l'interfaccia utente di installazione come utente2 .

Prova a seguire questo:

Accedi come root :

sudo su

Prova il server x:

xclock

Se riesci a vedere un orologio in esecuzione, va bene, ora prova a eseguire questo:

xhost

Il risultato dovrebbe essere così:

xhost SI:localuser:tri
# tri is my user name

Ora lascia che user2 acceda a xhost

xhost +SI:localuser:user2

ora prova ad accedere nuovamente a user2 e prova ad aprire uno qualsiasi dei programmi della GUI.