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
Respuestas:
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.
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.
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.