-bash: / dev / null: в доступе отказано

30

Я пытаюсь создать нового пользователя в системе Centos 6.

Во-первых, я делаю

useradd kevin

Затем я попытался запустить команды от имени этого пользователя

su - kevin

Тем не менее, я получаю следующие сообщения об ошибках

-bash: /dev/null: Permission denied
-bash: /dev/null: Permission denied
-bash: /dev/null: Permission denied
-bash: /dev/null: Permission denied
-bash: /dev/null: Permission denied
-bash: /dev/null: Permission denied
[kevin@gazelle ~]$

И я не могу сделать так много, как этот пользователь.

Разрешения на /dev/nullследующие:

-rwxr-xr-x  1 root root           9 Jul 25 17:07 null

Примерно так же, как они на моем Mac,

crw-rw-rw-   1 root   wheel         3,   2 Jul 25 14:08 null

Это возможно , но на самом деле маловероятно, что я прикоснулся Dev.

Как пользователь root, я попытался добавить kevinв rootгруппу:

usermod -a -G root kevin

Однако я все еще получаю /dev/nullразрешение на отказ в ошибках.

Почему новый пользователь не может писать /dev/null?
В какие группы должен входить новый пользователь?
Я не выдает себя за пользователя правильно?
Существует ли руководство для начинающих по настройке пользователей / разрешений в Linux?

permissions

— Кевин Берк
источник

1

Похоже, что / dev / null был изменен на обычный файл длиной 9 байт; это должен быть файл устройства ('c' в начале поля типа файла / разрешения). Если вы cat /dev/null, это похоже на то, что вы недавно использовали?

— Марк Плотник

ах. да, это так. "* мастер". Вы хотите добавить это как ответ, и я отмечу это?

— Кевин Берк

Вы можете перезагрузиться и / dev / null будет переделан, но знаете ли вы, что случилось, чтобы изменить / dev / null в файл? Было бы больно, если бы это случилось снова.

— Марк Плотник

1

Я предполагаю, что я переместил вывод «git branch» в / dev / null вместо того, чтобы писать, или у меня был плохой сценарий или что-то в этом роде

— Кевин Берк

56

Кто-то явно переместил обычный файл в / dev / null. Перезагрузка воссоздаст его или сделает

rm -f /dev/null; mknod -m 666 /dev/null c 1 3

Как отметил @Flow в комментарии, вы должны rootсделать это.

— Марк Плотник
источник

12

Если под «кем-то» вы подразумеваете «я», то да :)

— Кевин Берк

Даже я побежал в ту же проблему на сервере. Убунту 14.04 LTS. Но я не менял разрешения. Есть ли возможность, где я могу отслеживать, какой процесс изменил разрешения?

— Мани,

@Mani Linux по умолчанию не регистрирует такие небольшие изменения, но вы можете включить аудит, чтобы видеть их отныне. Как обнаружить в Linux chmod файла

— Марк Плотник,

1

Решение устраняет проблему, но проблема повторяется. Зачем?

— Абхишек Сони

@AbhishekSoni Вы можете попробовать одитинг, как описано в разделе « Показать историю файла (список пользователей, которые изменили файл)»

— Марк Плотник,

13

Это должно решить проблему (как root):

rm /dev/null
mknod /dev/null c 1 3
chmod 666 /dev/null

— jlliagre
источник

2

Этот также работает на Mac / BSD

— redolent

3

Решение, предложенное Марком, не работает на OpenBSD. тем не мение

mknod -m 666 /dev/null -c 2 2

сделал свое дело. Я проверил это на OpenBSD 5.6. Когда принятый ответ будет выполнен / dev / null заблокирует и закрутит любой код, считывающий его, довольно сильно

— meschi
источник

Разве OP не использовал CentOS, а не OpenBSD?

— ot--

3

К сожалению, разные операционные системы используют разные старшие / младшие номера для /dev/null, и нет никакого стандарта. OP вопрос о CentOS 6. Linux использует 1,3для / DEV / нуль происходит назад , по крайней мере , 2001 На FreeBSD, я видел 0,6, 15,0, 17,0и 20,0. OpenBSD использует 2,2. В OpenBSD вам на самом деле не нужно знать числа; ты можешь бежать # cd /dev; ./MAKEDEV std.

— Марк Плотник

Основные и второстепенные номера нельзя переносить между операционными системами. То, что работает в Linux, обычно не работает на * BSD или Mac OS X (или Solaris, AIX, HP-UX,…) и наоборот. Вы должны найти правильные числа для использования в mknodкоманде, изучив руководства (если вам повезет, информация там есть) или изучив заголовки ядра.

— Джонатан Леффлер

1

Это случилось со мной в Windows в приложении Ubuntu, когда я пытался запустить скрипт, который записывал в него /dev/null. Разрешения были правильными как для, так /devи для /dev/null.

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

dos2unix.exe c:\path\to\script.sh

Решил проблему для меня.

— Arthur.V
источник

0

Выкладываю ответ Mac OS X для потомков ...

sudo su \
&& rm -rf /dev/null \
&& mknod /dev/null c 3 2 \
&& chmod 666 /dev/null

— юлианский
источник