No protocol specified не удалось открыть дисплей

Обновлено: 03.07.2024

Здравствуйте.
Не получается настроить нормальный запуск x11vnc до ввода пароля, чтобы получить доступ к текущей сессии и нулевому экрану.

Настроил по этой инструкции, перезагрузил компьютер, все заработало, подключился с телефона. Сегодня включил компьютер и подключиться уже не смог. Пароль пользователя не вводил, зашел по ssh, служба x11vnc работает, но в логах пишется что не удалось подключиться к display :0 (я так понял). Автозапуск демона x11vnc включен.

[Unit]
Description=Start x11vnc at startup.
After=multi-user.target

[Service]
Type=simple
ExecStart=/usr/bin/x11vnc -display :0 -snapfb -rfbport 5900 -forever -rfbauth -loop /etc/x11vnc.pass -o /var/log/x11vnc.log

*** x11vnc was unable to open the X DISPLAY: ":0", it cannot continue.
*** There may be "Xlib:" error messages above with details about the failure.

Some tips and guidelines:

** An X server (the one you wish to view) must be running before x11vnc is
started: x11vnc does not start the X server. (however, see the -create
option if that is what you really want).

** You must use -display , -OR- set and export your $DISPLAY
environment variable to refer to the display of the desired X server.
- Usually the display is simply ":0" (in fact x11vnc uses this if you forget
to specify it), but in some multi-user situations it could be ":1", ":2",
or even ":137". Ask your administrator or a guru if you are having
difficulty determining what your X DISPLAY is.

** Next, you need to have sufficient permissions (Xauthority)
to connect to the X DISPLAY. Here are some Tips:

- Often, you just need to run x11vnc as the user logged into the X session.
So make sure to be that user when you type x11vnc.
- Being root is usually not enough because the incorrect MIT-MAGIC-COOKIE
file may be accessed. The cookie file contains the secret key that
allows x11vnc to connect to the desired X DISPLAY.
- You can explicitly indicate which MIT-MAGIC-COOKIE file should be used
by the -auth option, e.g.:
x11vnc -auth /home/someuser/.Xauthority -display :0
x11vnc -auth /tmp/.gdmzndVlR -display :0
you must have read permission for the auth file.
See also '-auth guess' and '-findauth' discussed below.

** If NO ONE is logged into an X session yet, but there is a greeter login
program like "gdm", "kdm", "xdm", or "dtlogin" running, you will need
to find and use the raw display manager MIT-MAGIC-COOKIE file.
Some examples for various display managers:

gdm: -auth /var/gdm/:0.Xauth
-auth /var/lib/gdm/:0.Xauth
kdm: -auth /var/lib/kdm/A:0-crWk72
-auth /var/run/xauth/A:0-crWk72
xdm: -auth /var/lib/xdm/authdir/authfiles/A:0-XQvaJk
dtlogin: -auth /var/dt/A:0-UgaaXa

Sometimes the command "ps wwwwaux | grep auth" can reveal the file location.

Starting with x11vnc 0.9.9 you can have it try to guess by using:

(see also the x11vnc -findauth option.)

Only root will have read permission for the file, and so x11vnc must be run
as root (or copy it). The random characters in the filenames will of course
change and the directory the cookie file resides in is system dependent.

Пробовал настроить автозапуск x11vnc так, в /etc/init положил файл x11vnc.conf:

Перезапустил комп, подключится к рабочему столу не смог, подключился через ssh, проверил, сервис x11vnc не запущен.
Буду признателен за помощь!

В операционной системе Linux очень жёсткий контроль полномочий для пользователей. Если пользователь не имеет прав администратора, то он не сможет сделать практически ничего дальше своей домашней папки. Но обычно графические приложения запускаются от имени рядового пользователя. Однако время от времени нужно что-то делать в графическом интерфейсе с файлами, которые не принадлежат текущему пользователю.

И тогда новички пытаются запустить нужное графическое приложение через sudo. Как правило, в таких ситуациях они получают ошибку "cannot open display :0 linux" или нечто подобное. В этой статье мы поговорим о том, что означает эта ошибка, а также как её обойти.

Что означает "cannot open display" в Linux?

Эта ошибка может выглядеть по-разному, в зависимости от приложения, которое вы будете запускать:

Gtk warning cannot open display :0;
Unable open display :0;
Can't connect to display :0 No protocol specified;

И так далее. Все эти ошибки означают одно: программа не может подключиться к графической подсистеме. Чтобы понять почему это происходит, возвращаемся к тому, что было сказано в самом начале статьи - в Linux очень жёсткий контроль прав пользователей.

В отличие от Windows, где графический интерфейс тесно интегрирован в операционную систему, в Linux это просто ещё одна программа, запущенная от имени обычного пользователя. Эта программа - графический сервер, на данный момент чаще всего используется Xorg.

Ещё одно отличие от Windows - это то, что вы можете запустить несколько графических серверов, и они будут работать не мешая друг другу, потому что каждый из них имеет свой адрес, по которому к нему можно подключиться. Эти серверы доступны глобально во всей системе (почти), но чтобы программы знали, к какому адресу им обращаться при запуске X-сервера, для текущего пользователя создаётся переменная DISPLAY с адресом графического сервера. По умолчанию для первого сервера присваивается адрес :0, для второго :1 и так далее.

Начнём с того, что для запуска графических приложений от имени суперпользователя существуют специальные утилиты. Программа sudo для этого не предназначена. Изначально для таких целей использовались kdesudo в KDE и gksu в Gnome. Сейчас они считаются устаревшими и поставляются по умолчанию далеко не всегда. В Ubuntu вы можете установить gksu командой:

sudo apt install gksu

А затем запустить с помощью неё своё приложение:

Но надо заметить, что с дисплейным сервером Wayland эта утилита работать не будет. А полноценных альтернатив gksu не существует.

1. Использование PlicyKit

Есть утилита pkexec. Она достаточно удобная, но для каждой программы, которую вы хотите запустить с помощью неё надо создавать отдельно файл настройки. Например, чтобы запустить Nautilus, надо открыть файл ниже и добавить в него такой текст:

sudo vi /usr/share/polkit-1/actions/org.freedesktop.policykit.pkexec.policy

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE policyconfig PUBLIC
"-//freedesktop//DTD PolicyKit Policy Configuration 1.0//EN"
"http://www.freedesktop.org/standards/PolicyKit/1/policyconfig.dtd">
<policyconfig>
<action >
<description>Run Nautilus</description>
<message>Authentication is required to run Nautilus</message>
<defaults>
<allow_any>no</allow_any>
<allow_inactive>no</allow_inactive>
<allow_active>auth_admin_keep</allow_active>
</defaults>
<annotate key="org.freedesktop.policykit.exec.path">/usr/sbin/nautilus</annotate>
<annotate key="org.freedesktop.policykit.exec.allow_gui">TRUE</annotate>
</action>
</policyconfig>

Это значит, что для каждого приложения нам необходимо включить параметр org.freedesktop.policykit.exec.allow_gui=true, иначе переменная DISPLAY экспортирована не будет. Теперь мы можем запустить nautilus:

Это очень неудобно для запуска новых приложений, поэтому есть ещё несколько путей. Другой вариант - вручную передать утилите нужные переменные:

pkexec env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY nautilus

2. Использование sudo

Можно попросить sudo передать все переменные нашего пользователя во временное окружение суперпользователя с помощью опции -E:

sudo -E nautilus

Тогда программа запускается.

3. Использование gvfs

Gnome Virtual Filesystem тоже позволяет получить доступ к файлам с правами администратора. Особенно если вам надо только отредактировать файл. Для этого просто добавьте в начале пути admin://. Например, так можно открыть файл /etc/group для редактирования с помощью gedit:

Смысл здесь в том, что программа запускается от имени обычного пользователя, а файл доступен ей через виртуальную файловую систему.

4. Снимаем ограничение доступа к Xorg

Обычно если переменная $XAUTHORITY содержит адрес файла аутентификации Xorg, то программа использует его для аутентификации в Xorg. Но если значение переменной не установлено, то сервер не позволит установить соединение. Например, если вы получаете ошибку подключения к Display :0, это значит, что адрес дисплейного сервера известен, но к нему нет доступа. Надо разрешить подключаться к Xorg суперпользователю. Для этого используйте команду:

Эта команда действует только до перезагрузки, чтобы сделать её постоянной, добавьте команду в конец

Выводы

Я пытаюсь ssh на сервер (myserver), установленный с RHEL 5.8, из настольного клиента (mydesktop) с RHEL 6.2. Я уже установил X Window на удаленном сервере, переменная DISPLAY на удаленном сервере также установлена на localhost:0.0, но я все еще не могу запустить firefox. Команда для подключения.

Я пытаюсь установить Ganib (инструмент управления проектами) , который использует tomcat. После установки я пытаюсь выполнить Start_ganib.sh, который в конечном итоге пытается запустить tomcat и терпит неудачу со следующей ошибкой: Using CATALINA_BASE: /tmp/download/Ganib-1.3_with_jre/tomcat Using.

При выполнении команды xhost вы , вероятно, получаете

Проблема в том, что вашему пользователю не разрешен доступ к X-серверу.

Вы можете использовать xhost для ограничения доступа к X-серверу по соображениям безопасности.

Переключитесь обратно на пользователя по умолчанию и снова запустите xhost. Вы должны увидеть что-то вроде

Решение состоит в том, чтобы добавить oracle в список контроля доступа

Теперь вернитесь к исходному пользователю "youruser". Теперь это должно сработать.

Используете ли вы Putty & Xming для подключения к этой машине?
Если нет, проверьте сервер Xorg на вашем клиенте.
Вы также можете проверить переменную $DISPLAY

Следуйте этому при запуске Xming :

Запустите Xming и выберите стиль, в котором вы хотите отобразить выходные данные X-сервера. Подсказка:

Это позволит быстро запустить Xming позже.

Это позволит устранить ошибку "No protocol specified" .

ОТОБРАЖЕНИЕ и ВЛАСТЬ

Программе X требуется две части информации для подключения к дисплею X.

Ему нужен адрес дисплея, который обычно равен :0 , когда вы вошли в систему локально, или :10 , :11 и т.д., Когда вы вошли в систему удаленно (но число может меняться в зависимости от того, сколько активных X-соединений). Адрес дисплея обычно указывается в переменной окружения DISPLAY .

Требуется пароль для отображения. Пароли X-дисплея называются волшебными куки . Магические куки не указываются напрямую: они всегда хранятся в авторитетных файлах X, которые представляют собой набор записей вида "display :42 содержит cookie 123456 ". Файл полномочий X обычно указывается в переменной среды XAUTHORITY . Если $XAUTHORITY не установлен, программы используют

Вы пытаетесь действовать на окнах, которые отображаются на вашем рабочем столе. Если вы единственный, кто использует ваш настольный компьютер, вполне вероятно, что отображаемое имя - :0 . Найти местоположение авторитетного файла X сложнее, потому что с gdm, настроенным в Debian squeeze или Ubuntu 10.04, он находится в файле со случайно сгенерированным именем. (У вас не было проблем раньше, потому что в более ранних версиях gdm использовалась настройка по умолчанию, то есть файлы cookie, хранящиеся в

Получение значений переменных

Вот несколько способов получить значения DISPLAY и XAUTHORITY :

Вы можете систематически запускать сеанс экрана со своего рабочего стола, возможно, автоматически в сценариях входа в систему (из

/.profile ; но делать это только при входе в систему под X: проверьте, установлено ли для DISPLAY значение, начинающееся с : (которое должно охватите все случаи, с которыми вы можете столкнуться)). В

Затем в сеансе SSH:

Вы также можете сохранить значения DISPLAY и XAUTHORITY в файле и вызвать их. В

Вы можете обнаружить значения DISPLAY и XAUTHORITY из запущенного процесса. Это сложнее автоматизировать. Вы должны выяснить PID процесса, который подключен к дисплею, с которым вы хотите работать, а затем получить переменные окружения из /proc/$pid/environ ( eval export $(</proc/$pid/environ tr \\0 \\n | grep -E '^(DISPLAY|XAUTHORITY)=') ¹).

Копирование куки

Другой подход (следуя предложению Arrowmaster ) состоит в том, чтобы не пытаться получить значение $XAUTHORITY в сеансе ssh, а вместо этого заставить сеанс X копировать свои куки в

/.Xauthority . Поскольку файлы cookie генерируются при каждом входе в систему, это не проблема, если вы сохраняете устаревшие значения в

Может быть проблема безопасности, если ваш домашний каталог доступен через NFS или другую сетевую файловую систему, что позволяет удаленным администраторам просматривать его содержимое. Им все равно нужно каким-то образом подключаться к вашей машине, если только вы не включили соединения X TCP (у Debian они отключены по умолчанию)). Поэтому для большинства людей это либо неприменимо (нет NFS) или не является проблемой (нет X TCP соединения).

Чтобы скопировать файлы cookie при входе в сеанс X рабочего стола, добавьте следующие строки в

/.profile (или в какой-либо другой сценарий, который читается при входе в систему):

¹ _{В принципе, здесь не хватает правильного цитирования, но в этом конкретном случае $DISPLAY и $XAUTHORITY не будут содержать метасимвол Shell.}

Читайте также: