Trên postgres người dùng:
$ ls -l /dev/null
ls: cannot access /dev/null: Permission denied
Suy nghĩ về root người dùng, quyền là chính xác:
# ls -l /dev/null
crw-rw-rw- 1 root root 1, 3 Sep 21 12:05 /dev/null
Tôi đã cố gắng tạo lại nó:
# rm /dev/null && mknod -m 0666 /dev/null c 1 3
Nhưng kết quả là như nhau. Tôi đang sử dụng VPS với debian 7 và kernel 2.6.32 trên x86_64
Câu trả lời:
Vấn đề xuất phát từ quyền cho / dev:
# ls -ld /dev
drwx------ 3 root root 4096 Sep 21 12:12 /dev
Vì vậy, người dùng không thể truy cập / dev.
# chmod a+x /dev
# chmod a+r /dev
Đã giải quyết vấn đề.
Tôi đã có một vấn đề tương tự, và đã đến đây bằng cách tìm kiếm các triệu chứng, nhưng giải pháp không phù hợp với trường hợp của tôi. Vì vậy, tôi muốn thêm một lý do có thể khác ngay cả khi nó không phù hợp với OP.
Trong trường hợp đặc biệt của tôi, tôi đã sử dụng proot(một chroottrình bao bọc đẹp ). Nhưng các quyền đã được chính xác /dev/nullvà /devchính nó.
Nó tình cờ là sự gắn kết của chrootthư mục, mà tôi đã làm thông qua thunarnhư một người dùng bình thường. Vì vậy, trong trường hợp này, mount không có quyền chính xác.
Bạn có một thời gian tồi tệ để tìm thấy điều này, bởi vì bạn không thấy các quyền này, khi chỉ nhìn vào các tệp.
Đường dẫn giải pháp chung sẽ là bắt đầu kiểm tra các điều kiện tại vị trí sự cố ( /dev/null) và bước ra cấp độ tiếp theo (s) ( /dev), sau đó gắn kết, hệ thống tệp, v.v., bất cứ điều gì tiếp theo.
Ở mỗi bước bạn có thể có một số điều kiện tiên quyết, mỗi điều kiện có cấp độ bên ngoài của riêng nó. Ví dụ: người dùng có thể ở trong một nhóm sai, dẫn đến tệp cấu hình nhóm, có thể có quyền sai, v.v.
Rõ ràng, bạn phải theo một loại cây nói chung.
Tôi không thể tự giải quyết vấn đề này, vì vậy đây là những gì tôi đã làm:
mycommand.sh | echo -n
Các echolệnh không chú ý đến đầu vào tiêu chuẩn, vì vậy nó sẽ bị loại bỏ. Và -nđó là để một dòng mới vô dụng không được in ra thiết bị xuất chuẩn.