У користувацьких postgres:
$ ls -l /dev/null
ls: cannot access /dev/null: Permission denied
Думаючи про користувальницький корінь, дозволи є правильними:
# 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) та перейти до наступного рівня (s) ( /dev), потім монтувати, файлову систему тощо, що далі буде.
На кожному кроці у вас може бути кілька передумов, у кожного є свої зовнішні рівні. Наприклад, користувач може бути в неправильній групі, що призводить до файлу конфігурації групи, який може мати неправильні дозволи тощо
Очевидно, що вам слід загалом слідувати за різновидом дерева.
Я не міг самостійно вирішити цю проблему, тож ось що я зробив:
mycommand.sh | echo -n
echoКоманда не звертає уваги на стандартний ввід, тому він буде відкинутий. І -nце так, що маркований новий рядок не друкується для stdout.