사용자 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
그러나 결과는 같습니다. x86_64에서 데비안 7 및 커널 2.6.32가있는 VPS를 사용하고 있습니다.
답변:
문제는 / dev에 대한 권한에서 비롯된 것입니다.
# ls -ld /dev
drwx------ 3 root root 4096 Sep 21 12:12 /dev
따라서 사용자가 / dev에 액세스 할 수 없었습니다.
# chmod a+x /dev
# chmod a+r /dev
문제를 해결했습니다.
비슷한 문제가 있었고 증상을 찾아서 여기에 왔지만 해결책이 내 경우에 맞지 않았습니다. 따라서 OP에 정확히 맞지 않더라도 가능한 다른 이유를 추가하고 싶습니다.
내 특별한 경우에는 proot(멋진 chroot포장지)를 사용했습니다. 그러나 권한에 대한 정확 /dev/null하고 /dev자체.
그것은 일반 사용자로서 chroot했던 디렉토리 의 마운트였습니다 thunar. 따라서이 경우 마운트에 올바른 권한이 없습니다.
파일을 볼 때만 이러한 권한이 표시되지 않기 때문에이 파일을 찾는 데 시간이 없습니다.
일반적인 솔루션 경로는 문제 위치 ( /dev/null) 에서 상태 확인을 시작 하고 다음 단계 ( ), 단계 ( /dev마운트, 파일 시스템 등)로 나아갑니다.
각 단계마다 여러 가지 전제 조건이있을 수 있으며 각 전제 조건에는 자체 외부 레벨이 있습니다. 예를 들어, 사용자가 잘못된 그룹에있을 수 있으며, 이로 인해 그룹 구성 파일이 생성되어 권한이 잘못 될 수 있습니다.
분명히, 당신은 일반적으로 일종의 나무를 따라야합니다.
나는 이것을 스스로 해결할 수 없었으므로 이것이 내가 한 일이다.
mycommand.sh | echo -n
이 echo명령은 표준 입력에주의를 기울이지 않으므로 폐기됩니다. 그리고 -n쓸모없는 줄 바꿈이 표준 출력으로 인쇄되지 않도록합니다.