Na postgres użytkownika:
$ ls -l /dev/null
ls: cannot access /dev/null: Permission denied
Uprawnienia użytkownika root są poprawne:
# ls -l /dev/null
crw-rw-rw- 1 root root 1, 3 Sep 21 12:05 /dev/null
Próbowałem go odtworzyć:
# rm /dev/null && mknod -m 0666 /dev/null c 1 3
Ale wynik jest taki sam. Jestem na VPS z debian 7 i jądrem 2.6.32 na x86_64
Odpowiedzi:
Problem pochodzi z uprawnień do / dev:
# ls -ld /dev
drwx------ 3 root root 4096 Sep 21 12:12 /dev
Tak więc / dev nie był dostępny dla użytkowników.
# chmod a+x /dev
# chmod a+r /dev
Rozwiązać problem.
Miałem podobny problem i przyjechałem tutaj, szukając objawów, ale rozwiązanie nie pasowało do mojego przypadku. Chciałbym więc dodać kolejny możliwy powód, nawet jeśli nie pasuje dokładnie do OP.
W moim specjalnym przypadku użyłem proot (miły chroot obwoluta). Ale uprawnienia były poprawne /dev/null i /dev samo.
Tak się złożyło, że to góra chroot katalog, który zrobiłem przez thunar jako zwykły użytkownik. W tym przypadku mount nie miał poprawnych uprawnień.
Nie możesz tego znaleźć, ponieważ nie widzisz tych uprawnień, tylko patrząc na pliki.
Ogólną ścieżką rozwiązania byłoby rozpoczęcie sprawdzania warunków w lokalizacji problemu ( /dev/null ) i przejdź do następnego poziomu (poziomów) ( /dev ), następnie mount, system plików itp., cokolwiek będzie dalej.
Na każdym kroku możesz mieć kilka warunków wstępnych, z których każdy ma własne poziomy zewnętrzne. Na przykład. użytkownik może znajdować się w niewłaściwej grupie, co prowadzi do pliku konfiguracyjnego grupy, który może mieć nieprawidłowe uprawnienia itp.
Oczywiście, musisz podążać za rodzajem drzewa w ogóle.
Sam nie mogłem rozwiązać tego, więc to właśnie zrobiłem:
mycommand.sh | echo -n
The echo polecenie nie zwraca uwagi na standardowe wejście, więc zostanie odrzucone. I -n jest tak, że niepotrzebny znak nowej linii nie jest drukowany na standardowe wyjście.