Comment résoudre «Aucun protocole spécifié» pour l'utilisateur su
J'essaie d'utiliser un autre utilisateur (non administrateur) pour exécuter un logiciel graphique sur mon système. Cet autre utilisateur a été nommé et a reçu un UID et un GID pour correspondre à un utilisateur du système distant du même nom. L'UID est de 500, donc je crois que cela fait de l'utilisateur un utilisateur "sans connexion".
À partir d'Ubuntu connecté à mon compte principal, j'ouvre un terminal et su à l'autre utilisateur. J'essaie ensuite d'exécuter la commande pour démarrer l'application et recevoir "Aucun protocole spécifié".
Est-ce à cause de l'UID <1000, à cause de su ou à cause du non-administrateur de l'utilisateur? Comment puis-je demander à cet utilisateur d'exécuter l'application avec une interface graphique?
Le problème ne se produit pas en raison de l'UID de l'utilisateur. 500 est très bien en tant qu'UID, et cet UID n'en fait pas un utilisateur "sans connexion", sauf aux yeux des paramètres par défaut de quelques gestionnaires d'affichage.
Le message d'erreur Aucun protocole spécifié ressemble à un message d'erreur spécifique à l'application, et inutile à cela, mais je vais deviner que l'erreur est que l'application est incapable de contacter votre écran X11 car il n'est pas autorisé à le faire car il s'exécute en tant qu'utilisateur différent. Les applications ont besoin d'un "cookie magique" (jeton secret) pour parler au serveur X11 afin que les autres processus du système exécutés par d'autres utilisateurs ne puissent pas empiéter sur votre affichage, créer des fenêtres et espionner vos frappes. L'autre utilisateur du système n'a pas accès à ce cookie magique car les autorisations sont définies de sorte qu'il n'est accessible qu'à l'utilisateur qui a démarré l'environnement de bureau (ce qui devrait être le cas).
Essayez ceci, en tant qu'utilisateur d'origine, pour copier le cookie X11 sur l'autre compte:
su - <otheruser> -c "unset XAUTHORITY; xauth add $(xauth list)"
puis exécutez votre application. Vous devrez peut-être également désactiver XAUTHORITY dans ce shell. Cette commande extrait le cookie magique (xauth list) de votre utilisateur principal et l'ajoute (xauth add) à l'endroit où l'autre utilisateur peut l'obtenir.
Dans mon cas, le nouveau serveur d'affichage wayland était le problème,
fais juste xhost + local: alors les autres utilisateurs (par exemple root) sont autorisés à exécuter Programms dans votre session, les connexions réseau ne seront cependant pas autorisées.
Si vous souhaitez autoriser les clients de tout hôte, vous pouvez utiliser xhost + sans spécifier d'hôte du tout. Ceci n'est cependant pas sûr, il serait préférable de simplement spécifier le ou les hôtes pour lesquels vous souhaitez accorder l'accès à votre session.
Supposons que vous vouliez utiliser la force brute pour obtenir une connexion avec X ...
Supposons que vous exécutez déjà vos commandes sur le serveur (où X s'exécute), sinon faites en sorte que cela fonctionne d'abord, puis utilisez 'ssh -X user @ server) depuis le client;).
Il peut y avoir plusieurs façons d'exécuter les commandes xauth, par exemple, vous pouvez utiliser "Sudo", mais cela peut perdre ou modifier les variables d'environnement. Les variables d'environnement suivantes doivent être préservées: DISPLAY et XAUTHORITY. Pour tester si c'est le cas, vous pouvez exécuter 'echo $ XAUTHORITY' de la même manière que vous exécutez vos commandes, mais assurez-vous de ne pas étendre les variables d'environnement avant d'exécuter ces commandes. Par exemple, essayez: Sudo bash -c 'echo "$ XAUTHORITY"' pour voir ce qu'est vraiment XAUTHORITY après avoir exécuté votre Sudo (s'il disparaît, vous devrez peut-être ajouter quelque chose à votre fichier sudoers, voir ailleurs).
Finalement, exécutez la commande suivante en tant qu'utilisateur avec lequel vous souhaitez accéder, sur le serveur:
xauth info
Cela montrera le "fichier d'autorité" qui sera utilisé (/root/.Xauthority par défaut, pour root, ou quelque chose comme /home/theuser/.Xauthority). S'il affiche le fichier .Xauthority correct, vous n'avez pas à vous soucier de la variable d'environnement XAUTHORITY en fait (en fait, je ne saurais pas quand il ne le ferait pas, sauf si vous voulez manipuler un emplacement non standard de ce fichier ).
Supprimez ce fichier (s'il existe même):
rm /root/.Xauthority
Remplacer /root/.Xauthority avec le fichier XAUTHORITY correspondant à votre cas.
Recréez-le, mais vide (cela est nécessaire pour de nombreuses commandes):
touch /root/.Xauthority
À ce stade, vous obtiendrez l'erreur Aucun protocole spécifié, même si vous avez Invalid MIT-MAGIC-COOKIE-1 avant. Recherchez le fichier d'autorité que le serveur X utilise actuellement:
ps aux | grep Xorg
Cela devrait montrer quelque chose comme:
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
Le nom du fichier après -auth est ce dont vous avez besoin dans la prochaine commande. Exécutez ceci en tant que root:
Sudo xauth -f '/var/run/sddm/{ef18c483-7891-4e82-80ef-2c8f9bd79711}' list
Cela répertorie une clé hexadécimale à 32 chiffres. Par exemple, la sortie pourrait être:
hostname/unix:0 MIT-MAGIC-COOKIE-1 c0eaf749aa252101a0f57d5087089db7
Utilisez-le pour générer votre fichier .Xauthority (en tant qu'utilisateur qui doit se reconnecter):
xauth add $DISPLAY MIT-MAGIC-COOKIE-1 c0eaf749aa252101a0f57d5087089db7
remplacez "c0eaf749aa252101a0f57d5087089db7" par ce qui vous a été renvoyé par la commande list. Votre .Xauthority devrait maintenant avoir une taille de 51 octets et vous pouvez vous connecter au serveur X (à nouveau).
Essayez quelque chose comme ça
$ export LOGIN_USER="Math"
$ su - $LOGIN_USER
$ Sudo xhost local:$LOGIN_USER &>/dev/null
Ps : la réponse acceptée n'a pas fonctionné pour moi
J'ai eu cette erreur "Aucun protocole spécifié" lorsque j'ai démarré une instance de Selenium 3.3.1 à partir d'un script parvenu puis utilisé le pilote Chrome dans Selenium. Selenium fonctionnait comme le même utilisateur que X11, et la variable d'environnement DISPLAY Shell a été définie correctement. Ce qui est intéressant, c'est que cette erreur ne s'est pas produite lorsque j'ai utilisé le pilote Firefox. Définition de la variable d'environnement XAUTHORITY Shell dans le script upstart pour pointer vers la valeur de $ XAUTHORITY de l'utilisateur X11 actif a corrigé le erreur pour le pilote Chrome.
Par ailleurs, l'erreur "Aucun protocole spécifié" a été complètement enterrée par le pilote Chrome/Chrome et n'était en aucun cas facile à trouver. J'ai remarqué que Chrome continuait de créer des répertoires dans le modèle de /tmp/.org.chromium.Chromium.*, mais ils disparaissaient rapidement. J'ai réussi à remarquer qu'ils contenaient un fichier chrome_debug.log qui contenait le message "Impossible d'ouvrir l'affichage". J'ai pensé que c'était plutôt étrange car j'ai vérifié que le processus de sélénium avait le bon AFFICHAGE dans /proc/$pid/environ et a examiné plus en détail la sortie de strace sur le processus Selenium, qui a révélé "Aucun protocole spécifié", ce qui m'a finalement amené à cette question.
Cette erreur peut être reproduite en désactivant XAUTHORITY et en essayant d'exécuter un client X11. Par exemple:
$ XAUTHORITY= xeyes
No protocol specified
Error: Can't open display: :0.0
C'était simple. Le problème se produit lorsque vous êtes en état racine et que vous souhaitez utiliser gks Juste exit l'état racine et réessayez
Tapez simplement ceci dans votre terminal xhost +SI:localuser:root après avoir tapé export DISPLAY=:0.0 puis réessayez
En utilisant des indices dans les réponses acceptées, j'ai pu résoudre le problème différemment:
- Recherchez le fichier Xauth dans le compte qui fonctionne (Xauth1)
- Recherchez le fichier Xauth dans le compte qui ne le fait pas (Xauth2)
- Copier Xauth1 vers Xauth2
- Modifier les autorisations de Xauth2
Dans du code:
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
Disons que vous essayez d'accéder à l'interface graphique en tant que tilisateur2 ( utilisateur normal ), alors vous devez charger l'interface utilisateur d'installation en tant que - tilisateur2.
Essayez de suivre ceci:
Connectez-vous en tant que root:
Sudo su
Testez le serveur x:
xclock
Si vous pouvez voir une horloge fonctionner, c'est bon, essayez maintenant d'exécuter ceci:
xhost
Le résultat devrait ressembler à ceci:
xhost SI:localuser:tri
# tri is my user name
Maintenant, laissez ser2 accéder à xhost
xhost +SI:localuser:user2
essayez maintenant de vous reconnecter à ser2 et essayez d'ouvrir n'importe quel programme GUI.