No postgres do usuário:
$ ls -l /dev/null
ls: cannot access /dev/null: Permission denied
Pensado na raiz do usuário, as permissões estão corretas:
# ls -l /dev/null
crw-rw-rw- 1 root root 1, 3 Sep 21 12:05 /dev/null
Eu tentei recriá-lo:
# rm /dev/null && mknod -m 0666 /dev/null c 1 3
Mas o resultado é o mesmo. Estou em um VPS com um debian 7 e o kernel 2.6.32 em um x86_64
Respostas:
O problema veio das permissões para / dev:
# ls -ld /dev
drwx------ 3 root root 4096 Sep 21 12:12 /dev
Portanto, o / dev não estava acessível aos usuários.
# chmod a+x /dev
# chmod a+r /dev
Resolveu o problema.
Eu tive um problema semelhante e vim aqui pesquisando os sintomas, mas a solução não se encaixava no meu caso. Então, gostaria de adicionar outro motivo possível, mesmo que não seja exatamente adequado ao OP.
No meu caso especial, usei proot(um bom chrootinvólucro). Mas as permissões estavam corretas /dev/nulle por /devsi só.
Por acaso era a montagem do chrootdiretório, que eu fazia thunarcomo usuário normal. Portanto, nesse caso, a montagem não tinha as permissões corretas.
Você tem um momento ruim para encontrar isso, porque não vê essas permissões ao olhar apenas os arquivos.
O caminho geral da solução seria começar a verificar as condições no local do problema ( /dev/null) e passar para o próximo nível (s) ( /dev), depois a montagem, o sistema de arquivos etc., o que vier a seguir.
Em cada etapa, você pode ter várias pré-condições, cada uma com seus próprios níveis externos. Por exemplo, o usuário pode estar em um grupo errado, o que leva ao arquivo de configuração do grupo, que pode ter permissões erradas etc.
Obviamente, você tem que seguir um tipo de árvore em geral.
Eu não consegui resolver isso sozinho, então foi isso que fiz:
mycommand.sh | echo -n
O echocomando não presta atenção à entrada padrão e, portanto, será descartado. E -nisso é para que uma nova linha inútil não seja impressa em stdout.