Cómo resolver 'Sin protocolo especificado' para su usuario

Estoy tratando de usar un usuario alternativo (no administrador) para ejecutar software gráfico en mi sistema. Este usuario alternativo ha sido nombrado y se le ha dado un UID y GID para que coincida con un usuario del sistema remoto con el mismo nombre. El UID es 500, por lo que creo que eso convierte al usuario en un usuario que no está conectado.

A partir de que Ubuntu inició sesión en mi cuenta principal, abro un terminal y suel usuario alternativo. Luego intento ejecutar el comando para iniciar la aplicación y recibir 'No hay protocolo especificado'.

¿Es esto por el UID <1000, por el suo por el no administrador del usuario? ¿Cómo puedo hacer que este usuario ejecute la aplicación con una GUI?

El problema no se produce debido al UID del usuario. 500 está bien como UID, y ese UID no lo convierte en un usuario 'sin inicio de sesión', excepto a los ojos de la configuración predeterminada de algunos pocos administradores de pantalla.

El mensaje de error Ningún protocolo especificado suena como un mensaje de error específico de la aplicación, y no sirve de nada, pero supongo que el error es que la aplicación no puede comunicarse con su pantalla X11 porque no tiene permiso para hacerlo entonces porque se está ejecutando como un usuario diferente. Las aplicaciones necesitan una "cookie mágica" (token secreto) para comunicarse con el servidor X11 para que otros procesos en el sistema que se ejecutan bajo otros usuarios no puedan entrometerse en su pantalla, crear ventanas y espiar las teclas. El otro usuario del sistema no tiene acceso a esta cookie mágica porque los permisos están configurados para que solo sea accesible para el usuario que inició el entorno de escritorio (que es como debería ser).

Intente esto, ejecutándose como su usuario original, para copiar la cookie X11 a la otra cuenta:

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

luego ejecuta tu aplicación. Es posible que también deba desarmar XAUTHORITYese shell. Ese comando extrae la cookie mágica ( xauth list) de su usuario principal y la agrega ( xauth add) a donde el otro usuario pueda obtenerla.

En mi caso, el nuevo servidor de visualización waylandfue el problema,

simplemente haga que xhost + local:otros usuarios (por ejemplo, root) puedan ejecutar programas en su sesión; sin embargo, no se permitirán conexiones de red.

Si desea permitir clientes desde cualquier host , puede usarlo xhost +sin especificar ningún host. Sin embargo , esto no es seguro , sería mejor simplemente especificar los hosts para los que desea otorgar acceso a su sesión.

Supongamos que quiere fuerza bruta, consiga una conexión con X ...

Supongamos que ya está ejecutando sus comandos en el servidor (donde se ejecuta X), de lo contrario, haga que eso funcione primero y luego use 'ssh -X user @ server) del cliente después;).

Puede haber varias formas de ejecutar los comandos xauth, por ejemplo, puede estar usando 'sudo', pero eso puede perder o cambiar las variables de entorno. Deben preservarse las siguientes variables de entorno: DISPLAY y XAUTHORITY. Para probar si ese es el caso, podría ejecutar 'echo $ XAUTHORITY' de la misma manera que ejecuta sus comandos, pero asegúrese de no expandir las variables de entorno antes de ejecutar esos comandos. Por ejemplo, intente: sudo bash -c 'echo "$ XAUTHORITY"' para ver qué es realmente XAUTHORITY después de ejecutar sudo (si desaparece, es posible que deba agregar algo a su archivo de sudoers, ver en otro lugar).

Finalmente, ejecute el siguiente comando como el usuario con el que desea obtener acceso en el servidor:

xauth info

Esto mostrará el 'Archivo de autoridad' que se usará (/root/.Xauthority por defecto, para root, o algo así como /home/theuser/.Xauthority). Si muestra el archivo .Xauthority correcto, entonces no tiene que preocuparse por la variable de entorno XAUTHORITY en realidad (en realidad, no sabría cuándo no lo haría, excepto si desea manipular un lugar no estándar de ese archivo )

Elimina ese archivo (si es que existe):

rm /root/.Xauthority

Reemplace /root/.Xauthoritycon el archivo XAUTHORITY correcto para su caso.

Recree, pero vacío (esto es necesario para muchos comandos):

touch /root/.Xauthority

En este punto, obtendrá el error Sin protocolo especificado , incluso si recibió MIT-MAGIC-COOKIE-1 no válido anteriormente. Encuentre el archivo de autoridad que el servidor X está usando en este momento:

ps aux | grep Xorg

Esto debería mostrar algo como:

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

El nombre del archivo después -authes el que necesita en el siguiente comando. Ejecuta esto como root:

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

Eso enumera una clave hexadecimal de 32 dígitos. Por ejemplo, la salida podría ser:

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

Use eso para generar su archivo .Xauthority (como usuario que necesita iniciar sesión nuevamente):

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

reemplace 'c0eaf749aa252101a0f57d5087089db7' con lo que le devolvió el comando de lista. Ahora su .Xauthority debe tener un tamaño de 51 bytes y puede conectarse al servidor X (nuevamente).

Intenta algo así

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

fuente

Ps : la respuesta aceptada no funcionó para mí

Tuve este error "No se especificó ningún protocolo" cuando comencé una instancia de Selenium 3.3.1 desde un script inicial y luego usé el controlador de Chrome en Selenium. Selenium se ejecutó como el mismo usuario que X11, y la variable de entorno de shell DISPLAY se configuró correctamente. Lo interesante es que este error no ocurrió cuando utilicé el controlador de Firefox. La configuración de la variable de entorno de shell XAUTHORITY dentro del script de inicio para que apunte al valor de $ XAUTHORITY del usuario X11 activo solucionó el error para el controlador Chrome.

En una nota al margen, el error "No se especificó ningún protocolo" fue completamente oculto por el controlador de Chrome / Chrome y de ninguna manera fue fácil de encontrar. Noté que Chrome seguía creando directorios en el patrón de /tmp/.org.chromium.Chromium.*, pero estaban desapareciendo rápidamente. Me las arreglé para notar que contenían un archivo chrome_debug.logque tenía un mensaje "No se puede abrir la pantalla". Pensé que esto era bastante extraño ya que verifiqué que el proceso de selenio tenía la PANTALLA correcta /proc/$pid/environy examiné la salida destrace proceso de selenio más a fondo, lo que reveló "No se especificó ningún protocolo", lo que finalmente me llevó a esta pregunta.

Este error puede reproducirse desarmando XAUTHORITY e intentando ejecutar algún cliente X11. Por ejemplo:

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

Esto fue simple. El problema ocurre cuando está en estado raíz y quiere usar el gksu. Simplemente salga del estado raíz e intente nuevamente

Simplemente escriba esto en su terminal xhost +SI:localuser:rootdespués de eso, export DISPLAY=:0.0luego vuelva a intentarlo

Utilizando pistas en las respuestas aceptadas, pude resolver el problema de manera diferente:

1. Busque el archivo Xauth en la cuenta que funciona (Xauth1)
2. Ubique el archivo Xauth en la cuenta que no funciona (Xauth2)
3. Copiar Xauth1 a Xauth2
4. Cambiar los permisos de Xauth2

En codigo:

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

Let dice que intenta acceder a la GUI como usuario2 ( usuario normal ), luego debe cargar la interfaz de usuario de instalación como usuario2 .

Intenta seguir esto:

Inicie sesión como root :

sudo su

Probar el servidor x:

xclock

Si puede ver un reloj funcionando, está listo, ahora intente ejecutar esto:

xhost

El resultado debería ser así:

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

Ahora deje que user2 acceda a xhost

xhost +SI:localuser:user2

ahora intente iniciar sesión nuevamente en user2 e intente abrir cualquiera de los programas GUI.