no se puede acceder / dev / null: permiso denegado, aunque crw-rw-rw- 1 root root 1, 3 sep 21 12:05 / dev / null

11

En postgres de usuario:

$ ls -l /dev/null
ls: cannot access /dev/null: Permission denied

Pensado en la raíz del usuario, los permisos son correctos:

# ls -l /dev/null
crw-rw-rw- 1 root root 1, 3 Sep 21 12:05 /dev/null

He intentado recrearlo:

# rm /dev/null && mknod -m 0666 /dev/null c 1 3

Pero el resultado es el mismo. Estoy en un VPS con un debian 7 y kernel 2.6.32 en un x86_64

linux permissions lalebarde
fuente

Respuestas:

18

El problema vino de los permisos a / dev:

# ls -ld /dev
drwx------ 3 root root 4096 Sep 21 12:12 /dev

Entonces / dev no fue accesible por los usuarios.

# chmod a+x /dev
# chmod a+r /dev

Resuelve el problema.

lalebarde
fuente
Así que quiero saber por qué tenía esos permisos. Es posible que desee reinstalar. Todo en / dev está gestionado por el núcleo y es extraño que tenga los permisos incorrectos.
cripto
no, todo en / dev no está "gestionado por el núcleo".
tlund
@tlund por favor revise su libro de kernel favorito. El directorio "/ dev refleja el estado actual del núcleo" doc.opensuse.org/products/draft/SLES/SLES-admin_sd_draft/…
cripto
@ user1048138: Me gustaría saber también. Comencé desde una configuración automática de Debian 7 de mi proveedor de VPS. Luego actualicé, actualicé, usé solo apt-get. Más un paquete a mano con wget some_domain / some_package.deb ; dpkg -i some_package.deb; apt-get -f install. En un momento, / dev / null se cambió a un archivo estándar y los permisos / dev cambiaron. No puedo decir más.
lalebarde
1

Tuve un problema similar y vine aquí buscando los síntomas, pero la solución no se ajustaba a mi caso. Por lo tanto, me gustaría agregar otra posible razón, incluso si no se ajusta exactamente al OP.

En mi caso especial usé proot(un buen chrootenvoltorio). Sin embargo, los permisos eran correctos en /dev/nully /deven sí.

Resultó ser el montaje del chrootdirectorio, lo que hice a través de thunarun usuario normal. Entonces, en este caso, la montura no tenía los permisos correctos.

Tienes un mal momento para encontrar esto, porque no ves estos permisos, solo cuando miras los archivos.

La ruta de solución general sería comenzar a verificar las condiciones en la ubicación del problema ( /dev/null) y avanzar al siguiente nivel (s) ( /dev), luego el montaje, el sistema de archivos, etc., lo que venga después.

En cada paso puede tener varias condiciones previas, cada una con sus propios niveles externos. Por ejemplo, el usuario podría estar en un grupo incorrecto, lo que lleva al archivo de configuración del grupo, que podría tener permisos incorrectos, etc.

Obviamente, tienes que seguir una especie de árbol en general.

Harald
fuente
0

No pude resolver esto yo mismo, así que esto es lo que hice:

mycommand.sh | echo -n

El echocomando no presta atención a la entrada estándar, por lo que se descartará. Y -nes así que una nueva línea inútil no se imprime en stdout.

Mark Stewart
fuente
1
Si bien esto puede responder la pregunta, sería una mejor respuesta si pudiera proporcionar alguna explicación de por qué lo hace.
DavidPostill
1
Sí, pero ¿cómo responde a la pregunta "no se puede acceder / dev / null: permiso denegado, aunque crw-rw-rw- 1 root root 1, 3 sep 21 12:05 / dev / null"?
DavidPostill
1
No responde la pregunta. Pero proporciona una solución alternativa. A veces no hay una respuesta directa ideal.
Mark Stewart
0 
chmod a+rw /dev/null /dev/random /dev/urandom /dev/ptmx /dev/tty /dev/zero /dev/full /dev/fuse /dev/net/tun

Esto es lo que resuelve mi problema en VPS. Tenga en cuenta que después de reiniciar su servidor, ha ejecutado este comando nuevamente

zore
fuente