Impossible de se connecter au serveur X: 0,0 en tant que superutilisateur

10

Lorsque je suis en ligne, j'obtiens l'erreur suivante et l'outil ne démarre pas:

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

Mais tout va bien quand je ne suis pas super-utilisateur. Pourquoi ça?

Éditer

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

toute suggestion?

Aussi

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

x11 su xauth

— msz
source

Ceci est un classique. Vous pouvez faire export $(dbus-launch)ou utiliser xhost [+]pour pouvoir lancer des programmes en utilisant X et votre compte superutilisateur.

— 41754

A fait les deux, voir la modification ci

— msz

Il peut s'agir $ xhostde voir l'accès actuel et $ xhost +de permettre l'accès à partir de n'importe quel hôte. Vous le faites souvent à partir d'un terminal virtuel que vous connaissez avec certitude qui peut générer des programmes en utilisant X.

— 41754

@galegosimpatico: pourquoi le lancement d'un serveur dbus résoudrait-il ce problème?

— Bananguin

Lorsque vous n'êtes pas super-utilisateur, qu'est-ce qui echo $DISPLAYs'affiche? À quel utilisateur le processus xserver appartient-il? (vous pouvez découvrir ce dernier en utilisant par exemple ps faux)

— Bananguin

12

Un programme X a besoin de deux informations pour se connecter à un écran X.

Il a besoin de l'adresse de l'écran, qui est généralement :0lorsque vous êtes connecté localement ou :10, :11etc. lorsque vous êtes connecté à distance (mais le nombre peut changer en fonction du nombre de connexions X actives). L'adresse de l'affichage est normalement indiquée dans la DISPLAYvariable d'environnement.
Il a besoin du mot de passe pour l'affichage. Les mots de passe d'affichage X sont appelés cookies magiques . Les cookies magiques ne sont pas spécifiés directement: ils sont toujours stockés dans des fichiers d'autorité X, qui sont une collection d'enregistrements de la forme «afficher :42avec cookie 123456». Le fichier d'autorité X est normalement indiqué dans la XAUTHORITYvariable d'environnement. Si $XAUTHORITYn'est pas défini, les programmes utilisent ~/.Xauthority.

Voir Ouvrir une fenêtre sur un écran X distant (pourquoi "Impossible d'ouvrir l'écran")? pour plus de détails.

Dans votre cas, DISPLAYest défini mais les programmes ne peuvent évidemment pas trouver le fichier cookie. Vérifiez la valeur de XAUTHORITYdans votre session et sous su.

Si XAUTHORITYn'est pas défini dans votre session et sudéfinit la HOMEvariable d'environnement dans le répertoire de root, vous devez définir XAUTHORITYà /home/msz/.Xauthorityoù /home/mszest votre répertoire personnel.

S'il est susupprimé XAUTHORITYde l'environnement, remettez-le en place ou configurez-le supour ne pas le faire.

Si votre répertoire personnel se trouve sur certains systèmes de fichiers comme NFS, root ne pourra peut-être pas le lire directement. Dans ce cas, vous pouvez copier le .Xauthorityfichier vers un emplacement différent sur un système de fichiers non NFS:

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

— Gilles 'SO- arrête d'être méchant'
source

1

J'ai créé un lien symbolique et cela a aussi fonctionné. Le voici:ln -s /home/otheruser/.Xauthority ~

— Can Geliş

XAUTHORITY pour moi a été défini comme un fichier qui n'existait plus:

— pbhj

5

Vous exécutez xhost en tant que root!

exécutez xhost en tant qu'utilisateur normal xhost +, puis devenez root, puis réessayez.

btw comme d'autres l'ont souligné xhost +permet à tout utilisateur de tout hôte

— X Tian
source

De nombreux systèmes modernes sont configurés pour que xhostcela ne fonctionne pas. Si c'est le cas, courez au moins xhost +localhost, non xhost +!

— Gilles 'SO- arrête d'être méchant'

Comprenez, c'est un bon point. Merci pour vos conseils.

— X Tian

C'était mon problème! Merci, ça a tout résolu! Je l'ai simplement exécuté à partir de non-root.

— Quidam Il y a

0

XAUTHORITY pour moi a été défini comme un fichier qui n'existait plus:

$ echo $XAUTHORITY

/tmp/xauth-1000-_0

J'ai donc fait

unset XAUTHORITY

et a ensuite pu se connecter à mon application en tant que root en utilisant kdesudo (dans ce cas kdesudo bleachbit)

— pbhj
source

0

Exécuter en tant qu'utilisateur normal

xhost + localhost

puis activez le super utilisateur en

sudo su

aller enfin à l'exemple du serveur

cd /usr/local/Ampps

enfin exécuter ./Ampps

merci en 2020

— Mr Mash
source

0

Cela a fonctionné pour moi dans fedora 30

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

— Gang
source