На пользователя postgres:
$ ls -l /dev/null
ls: cannot access /dev/null: Permission denied
Мысль о пользователе root, разрешения правильные:
# ls -l /dev/null
crw-rw-rw- 1 root root 1, 3 Sep 21 12:05 /dev/null
Я попытался воссоздать его:
# rm /dev/null && mknod -m 0666 /dev/null c 1 3
Но результат тот же. Я на VPS с Debian 7 и ядра 2.6.32 на x86_64
Ответы:
Проблема связана с разрешениями для / dev:
# ls -ld /dev
drwx------ 3 root root 4096 Sep 21 12:12 /dev
Так что / dev не был доступен пользователям.
# chmod a+x /dev
# chmod a+r /dev
Решил проблему.
У меня была похожая проблема, и я пришел сюда в поисках симптомов, но решение не подошло к моему случаю. Поэтому я хотел бы добавить еще одну возможную причину, даже если она не совсем соответствует ОП.
В моем особом случае я использовал proot(хорошая chrootобертка). Но разрешения были правильными /dev/nullи по /devсебе.
Это было монтирование chrootкаталога, которое я сделал thunarкак обычный пользователь. Таким образом, в этом случае монтирование не имело правильных разрешений.
У вас плохое время, чтобы найти это, потому что вы не видите эти разрешения, когда смотрите только на файлы.
Общий путь решения будет состоять в том, чтобы начать проверку условий в расположении проблемы ( /dev/null) и перейти на следующий уровень (уровни) ( /dev), затем монтировать, файловую систему и т. Д., Что будет дальше.
На каждом шаге у вас может быть несколько предварительных условий, каждое из которых имеет свои внешние уровни. Например, пользователь может быть в неправильной группе, что приводит к файлу конфигурации группы, который может иметь неправильные разрешения и т. Д.
Очевидно, что вы должны следовать своего рода дереву в целом.
Я не мог решить это сам, вот что я сделал:
mycommand.sh | echo -n
Команда echoне обращает внимания на стандартный ввод, поэтому она будет отброшена. И -nэто так, что бесполезный перевод строки не выводится на стандартный вывод.