Nie można połączyć się z serwerem X: 0.0 jako administrator

Kiedy jestem online, pojawia się następujący błąd i narzędzie nie uruchamia się:

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

Ale wszystko jest w porządku, gdy nie jestem superużytkownikiem. Dlaczego to?

Edytować

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

jakieś sugestie?

Również

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

Program X potrzebuje dwóch informacji, aby połączyć się z wyświetlaczem X.

• Potrzebuje adresu wyświetlacza, który zazwyczaj :0jest zalogowany lokalnie lub :10, :11itp., Gdy logujesz się zdalnie (ale liczba może ulec zmianie w zależności od liczby aktywnych połączeń X). Adres wyświetlacza jest zwykle wskazywany w DISPLAYzmiennej środowiskowej.

• Potrzebuje hasła do wyświetlacza. Hasła wyświetlania X nazywane są magicznymi ciasteczkami . Magiczne pliki cookie nie są określane bezpośrednio: zawsze są przechowywane w plikach autoryzacji X, które są zbiorem zapisów w formie „display :42ma ciasteczko 123456”. Plik uprawnień X jest zwykle wskazywany w XAUTHORITYzmiennej środowiskowej. Jeśli $XAUTHORITYnie jest ustawiony, programy używają ~/.Xauthority.

Zobacz Otwieranie okna na zdalnym wyświetlaczu X (dlaczego „Nie można otworzyć wyświetlacza”)? po więcej szczegółów.

W twoim przypadku DISPLAYjest ustawiony, ale programy najwyraźniej nie mogą znaleźć pliku cookie. Sprawdź wartość XAUTHORITYw sesji i poniżej su.

Jeśli XAUTHORITYnie jest ustawiona w sesji i suustawia HOMEzmienną środowiskową do katalogu domowego roota, to trzeba ustawić XAUTHORITYsię /home/msz/.Xauthoritygdzie /home/mszjest twój katalog domowy.

Jeśli zostanie suusunięty XAUTHORITYze środowiska, odłóż go z powrotem lub skonfiguruj, suaby tego nie robić.

Jeśli twój katalog domowy znajduje się w niektórych systemach plików, takich jak NFS, root może nie być w stanie odczytać go bezpośrednio. W takim przypadku możesz skopiować .Xauthorityplik do innej lokalizacji w systemie plików innym niż NFS:

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

Używasz xhosta jako root!

uruchom xhost jako normalny użytkownik xhost +, następnie zrób root, a następnie spróbuj ponownie.

btw, jak zauważyli inni, xhost +zezwala każdemu użytkownikowi z dowolnego hosta

XAUTHORITY dla mnie został ustawiony jako plik, który już nie istniał:

$ echo $XAUTHORITY

/tmp/xauth-1000-_0

Więc zrobiłem

unset XAUTHORITY

i był w stanie połączyć się z moją aplikacją jako root za pomocą kdesudo (w tym przypadku kdesudo bleachbit)

Uruchom jako zwykły użytkownik

xhost + localhost

następnie włącz superużytkownika przez

sudo su 

w końcu przejdź do przykładu serwera

cd /usr/local/Ampps

w końcu uruchom ./Ampps

dziękuję mi w 2020 roku

To działało dla mnie w Fedorze 30

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