Почему является pcmanfm такой головной болью когда дело доходит до монтирования файловых систем?
Это характерно для твердого кода такие ссылки во время компиляции, и, возможно, обеспечьте параметр командной строки или переменную среды для переопределения значения по умолчанию времени компиляции. Часто программа просто помнит местоположение одного конфигурационного файла (обычно под /etc) где любые значения по умолчанию времени компиляции могут быть переопределены. Этот подход имеет большую часть смысла для программного обеспечения с открытым исходным кодом, которое компилируется теми же людьми, которые делают операционную систему как часть портов BSD или дистрибутива Linux.
Для приложений, распределенных в двоичной форме, обычный подход должен определить местоположение двоичного файла приложения от своего нулевого аргумента. Условно, нулевой аргумент execve (т.е. argv[0]) путь к двоичному файлу (это до вызывающей стороны, часто оболочка, для уважения конвенции). Если argv[0] не содержит никого /, приложение должно работать $PATH поиск на нем.
Во-первых, удостоверьтесь это dbus и consolekit работают - обычно это означает предварительно ожидать ck-launch-session dbus-launch к Вашему exec оператор.
Вы также захотите проверить, что Ваш пользователь находится в storage группа (можно свериться groups). Большинство дистрибутивов поставлется с storage политики группы настроили на установке, но в случае, если они не, можно хотеть попытаться прокрутить собственную политику (возможно, что это было удалено/изменено когда udev был обновлен).
[[ -d /etc/polkit-1/localauthority/50-local.d ]] || mkdir -p /etc/polkit-1/localauthority/50-local.d
cat > /etc/polkit-1/localauthority/50-local.d/99-allow_storage_mount.pkla << 'EOF'
[Storage Permissions]
Identity=unix-group:storage
Action=org.freedesktop.udisks.filesystem-mount;org.freedesktop.udisks.drive-eject;org.freedesktop.udisks.drive-detach;org.freedesktop.udisks.luks-unlock;org.freedesktop.udisks.inhibit-polling;org.freedesktop.udisks.drive-set-spindown
ResultAny=yes
ResultActive=yes
ResultInactive=no
EOF
У меня недавно была та же проблема с LXDE на тестировании Debian.
В конце @jw013 показал мне ошибку (см. этот вопрос), где можно понять, что проблема состоит в том, что XDM и некоторый другой менеджер по оформлению не говорят с ConsoleKit и не устанавливают корректную информацию для PoliciKit (в особенности результаты сессии как неактивную).
Я решил все свои проблемы авторизации, переключающиеся на другого менеджера по оформлению в моем случае LightDM, но я уверен, что также GDM хорош для этого.
Нижняя часть этого, люди пишут программное обеспечение своими собственными способами, делая их собственные предположения. Когда предположения, сделанные одним приложением, отличаются от приложения другого приложения, эти два приложения не будут работать из поля друг с другом. Вот почему существуют специалисты по обслуживанию пакета для каждого распределения ОС. Одна из задач специалиста по обслуживанию состоит в том, чтобы исправить приложения так, чтобы они сотрудничали. Предположения могут и изменяться, таким образом, вещи будут время от времени повреждаться, прежде чем у специалистов по обслуживанию есть время для исправления его.
В Вашем случае я думал бы, что специалисты по обслуживанию (там специалисты по обслуживанию или Вы склеиваете вещи вместе сами?) пропустил изменение в файле конфигурации XML, или что тестеры пропустили этот вариант использования. В зависимости от ситуации можно или ожидать, пока специалисты по обслуживанию не узнают и фиксируют ее, или фиксируют ее и забывают это или сообщают об этом средству отслеживания ошибки, если это доступно, или получите исходный код и кодируйте патч :)
ck-launch-sessionот моего~/.xinitrcизбавиться от окна "Not Authorized". – Thorbjørn Lindeijer 13.05.2012, 12:15