Як вирішити "Не вказано протокол" для користувача

Я намагаюся використовувати іншого користувача (не адміністратора) для виконання графічного програмного забезпечення в моїй системі. Цьому альтернативному користувачеві присвоєно ім'я UID та GID, щоб відповідати віддаленому користувачеві системи з тим самим іменем. UID - 500, тому я вважаю, що це робить користувача користувачем, який не входить у систему.

Починаючи з Ubuntu, який увійшов у свій основний рахунок, я відкриваю термінал та suіншому користувачеві. Потім я намагаюся виконати команду для запуску програми та отримання "Не вказано протокол".

Це через UID <1000, через suабо через не-адміністратора користувача? Як я можу змусити цього користувача виконати програму за допомогою GUI?

Проблема не виникає через UID користувача. 500 - це просто добре, як UID, і UID не робить його користувачем, який не входить в систему, за винятком налаштувань за замовчуванням деяких кількох менеджерів дисплеїв.

Повідомлення про помилку Не вказаний протокол звучить як повідомлення про помилку, пов’язане з додатком, і непосильне в цьому, але я думаю, що помилка полягає в тому, що програма не може зв’язатися з вашим дисплеєм X11, оскільки не має дозволу робити тому що він працює як інший користувач. Програми потребують "чарівного файлу cookie" (таємного маркера) для того, щоб спілкуватися з сервером X11, щоб інші процеси в системі, що працює під іншими користувачами, не могли втручатися у ваш дисплей, створювати вікна та проводити натискання клавіш. Інший користувач системи не має доступу до цього чарівного файлу cookie, оскільки дозволи встановлені таким чином, що він доступний лише тому користувачеві, який запустив середовище робочого столу (як і належить).

Спробуйте це, працюючи як ваш початковий користувач, скопіювати файл cookie X11 в інший обліковий запис:

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

потім запустіть свою програму. Можливо, вам також знадобиться зняти XAUTHORITYцю оболонку. Ця команда витягує чарівне cookie ( xauth list) з вашого основного користувача та додає його ( xauth add) туди, де його може отримати інший користувач.

Я вважаю, що новий сервер відображення waylandбув проблемою,

просто xhost + local:тоді іншим користувачам (наприклад, root) дозволено запускати програми у вашому сеансі, однак мережеві з'єднання не дозволятимуться.

Якщо ви хочете дозволити клієнтів з будь-якого хоста , ви можете користуватися, xhost +не вказуючи взагалі жодного хоста. Це, однак, небезпечно , було б краще просто вказати хостів, для яких ви хочете надати доступ до свого сеансу.

Спробуйте щось подібне

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

джерело

Пс : прийнята відповідь не працювала для мене

Припустимо, ви хочете, щоб жорстокі сили набули зв’язок із X ...

Припустимо, ви вже виконуєте свої команди на сервері (де працює X), інакше спочатку з цим працюйте, а потім використовуйте 'ssh -X user @ server) від клієнта;).

Можливо, існує кілька способів запуску команд xauth, наприклад, ви можете використовувати "sudo", але це може втратити або змінити змінні середовища. Необхідно зберегти такі змінні середовища: DISPLAY та XAUTHORITY. Щоб перевірити, чи це так, ви можете запустити "echo $ XAUTHORITY" таким же чином, як і команди, але переконайтеся, що ви не розширюєте змінні середовища перед тим, як виконати ці команди. Наприклад, спробуйте: sudo bash -c 'echo "$ XAUTHORITY"', щоб побачити, що насправді XAUTHORITY є після запуску свого судо (якщо воно зникне, можливо, вам доведеться щось додати до файлу sudoers, дивіться в іншому місці).

Зрештою, запустіть таку команду як користувач, до якого ви хочете отримати доступ, на сервері:

xauth info

Це покаже 'файл файла', який буде використовуватися (/root/.Xauthority за замовчуванням, для root, або щось на кшталт /home/theuser/.Xauthority). Якщо він показує правильний .Xauthority файл, то вам не потрібно турбуватися про змінну середовища XAUTHORITY насправді (насправді я не знаю, коли це не стане, за винятком випадків, якщо ви хочете маніпулювати нестандартним місцем цього файлу ).

Видаліть цей файл (якщо він навіть існує):

rm /root/.Xauthority

Замініть /root/.Xauthorityправильний файл XAUTHORITY для вашої справи.

Відтворіть його, але порожнє (це потрібно для багатьох команд):

touch /root/.Xauthority

У цей момент ви отримаєте помилку, вказану в протоколі , навіть якщо раніше ви невірні MIT-MAGIC-COOKIE-1 . Знайдіть файл авторитету, який використовує X-сервер на даний момент:

ps aux | grep Xorg

Це повинно показувати щось на кшталт:

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

Назва файлу після -auth- це те, що вам потрібно в наступній команді. Запустити це як корінь:

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

Тут перелічено 32-значний шістнадцятковий ключ. Наприклад, вихід може бути:

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

Використовуйте це для створення файлу .Xauthority (як користувача, якому потрібно знову ввійти):

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

замініть 'c0eaf749aa252101a0f57d5087089db7' тим, що було повернуто командою list для вас. Тепер ваш .Xauthority повинен бути розміром 51 байт, і ви можете підключитися до X-сервера (знову).

У мене була помилка "Не вказано протокол", коли я запускав екземпляр Selenium 3.3.1 з початкового сценарію, а потім використовував драйвер Chrome у Selenium. Selenium працював тим самим користувачем, що і X11, і змінна середовища оболонки DISPLAY була встановлена ​​правильно. Цікаво, що ця помилка не сталася, коли я використовував драйвер Firefox. Встановлення змінної середовища оболонки XAUTHORITY всередині сценарію на початку, щоб вказати на значення $ XAUTHORITY активного користувача X11, виправила помилку для драйвера Chrome.

У бічній примітці, помилка "Не вказано протокол" була ретельно захована драйвером Chrome / Chrome і її жодним чином легко знайти. Я помітив, що Chrome продовжував створювати каталоги за зразком /tmp/.org.chromium.Chromium.*, але вони швидко зникали. Мені вдалося помітити, що вони містять файл chrome_debug.logіз повідомленням "Не вдається відкрити дисплей". Я подумав, що це досить дивно, оскільки я переконався, що процес Selenium має правильний DISPLAY /proc/$pid/environі straceбільш ретельно вивчив результати процесу селену, що виявило "Жоден протокол не вказаний", що призвело в підсумку до цього питання.

Цю помилку можна відтворити, якщо встановити XAUTHORITY та спробувати запустити якогось клієнта X11. Наприклад:

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

Це було просто. Проблема виникає, коли ви перебуваєте в root-саті і хочете використовувати gksu. Просто вийдіть із стану кореня та повторіть спробу

Просто введіть це у свій термінал, xhost +SI:localuser:rootпісля цього введіть export DISPLAY=:0.0і повторіть спробу

Використовуючи підказки у прийнятих відповідях, я зміг вирішити питання по-різному:

1. Знайдіть файл Xauth у тому обліковому записі, який працює (Xauth1)
2. Знайдіть файл Xauth в обліковому записі, який не є (Xauth2)
3. Скопіюйте Xauth1 в Xauth2
4. Змінення дозволів Xauth2

У коді:

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

Нехай говорить, що ви намагаєтеся отримати доступ до GUI як user2 ( звичайний користувач ), тоді вам потрібно завантажити інтерфейс установки як user2 .

Спробуйте дотримуватися цього:

Вхід як корінь :

sudo su

Перевірте x-сервер:

xclock

Якщо ви бачите годинник, що працює, це добре, зараз спробуйте запустити це:

xhost

Результат повинен бути таким:

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

Тепер дозвольте user2 отримати доступ до xhost

xhost +SI:localuser:user2

тепер спробуйте знову увійти до user2 та спробуйте відкрити будь-яку програму GUI.