Nginx: stat () không thành công (13: quyền bị từ chối)

Tôi đang sử dụng cấu hình mặc định trong khi thêm thư mục cụ thể có cài đặt nginx trên máy ubuntu 12.04 của mình.

server {
        #listen   80; ## listen for ipv4; this line is default and implied
        #listen   [::]:80 default ipv6only=on; ## listen for ipv6

        index index.html index.htm;

        # Make site accessible from http://localhost/
        server_name localhost;

        location / {
                # First attempt to serve request as file, then
                # as directory, then fall back to index.html
                root /username/test/static;
                try_files $uri $uri/ /index.html;
                # Uncomment to enable naxsi on this location
                # include /etc/nginx/naxsi.rules
        }
...

...
}

Tôi chỉ muốn một máy chủ nginx tĩnh đơn giản để cung cấp các tệp ra khỏi thư mục đó. Tuy nhiên, kiểm tra error.logtôi thấy

2014/09/10 16:55:16 [crit] 10808#0: *2 stat() "/username/test/static/index.html" failed (13: Permission denied), client:, server: localhost, request: "GET /favicon.ico HTTP/1.1", host: "domain"
2014/09/10 16:55:16 [error] 10808#0: *2 rewrite or internal redirection cycle while internally redirecting to "/index.html

Tôi đã thực hiện chown -R www-data:www-datatrên /username/test/static, tôi đã đặt chúng vào chmod 755. Tôi không biết những gì khác cần được thiết lập.

Nginx hoạt động trong thư mục, vì vậy nếu bạn không thể cdtruy cập thư mục đó từ người dùng nginx thì nó sẽ bị lỗi ( statlệnh trong nhật ký của bạn cũng vậy). Đảm bảo rằng www-usercó thể cdtất cả các cách /username/test/static. Bạn có thể xác nhận rằng statsẽ thất bại hoặc thành công bằng cách chạy

sudo -u www-data stat /username/test/static

Trong trường hợp của bạn, có lẽ /usernamethư mục là vấn đề ở đây. Thường www-datakhông có quyền đối cdvới thư mục chính của người dùng khác.

Giải pháp tốt nhất trong trường hợp đó là thêm www-datavào usernamenhóm:

gpasswd -a www-data username

và đảm bảo rằng usernamenhóm đó có thể nhập tất cả các thư mục dọc theo đường dẫn:

chmod g+x /username && chmod g+x /username/test && chmod g+x /username/test/static

Để các thay đổi của bạn hoạt động, hãy khởi động lại nginx

nginx -s reload

Tôi vừa gặp sự cố tương tự trên hộp CentOS 7.

Có vẻ như tôi đã nhấn selinux. Đặt selinux vào chế độ cho phép ( setenforce permissive) đã giải quyết được vấn đề ngay bây giờ. Tôi sẽ thử và quay lại với một bản sửa lỗi thích hợp.

Nginx cần có quyền truy cập + x trên tất cả các thư mục dẫn đến thư mục gốc của trang web.

Đảm bảo bạn có + x trên tất cả các thư mục trong đường dẫn đến thư mục gốc của trang web. Ví dụ: nếu gốc của trang là / home / username / siteroot:

chmod +x /home/
chmod +x /home/username
chmod +x /home/username/siteroot

Trên CentOS 7.0, tôi gặp sự Access Deinedcố này do SELinux gây ra và các bước sau đã giải quyết được sự cố:

yum install -y policycoreutils-devel
grep nginx /var/log/audit/audit.log | audit2allow -M nginx
semodule -i nginx.pp

Cập nhật: Chỉ là một ghi chú bên lề từ những gì tôi đã học được khi sử dụng máy chủ Linux ảo của digitalocean, hoặc như họ gọi chúng là Giọt . Sử dụng SELinux yêu cầu một lượng RAM kha khá. Rất có thể bạn sẽ không thể chạy và quản lý SELinux trên một giọt có RAM dưới 2GB.

Bạn có thể đang chạy Linux được tăng cường bảo mật, vì vậy hãy thêm quy tắc cho điều đó. Tôi có quyền 13 lỗi, mặc dù quyền đã được đặt và người dùng tồn tại ..

chcon -Rt httpd_sys_content_t /username/test/static

Triệu chứng:

Không thể tải hình ảnh lên Thư viện phương tiện WordPress.

Nguyên nhân:

(CentOS) yum update

Lỗi:

2014/10/22 18:08:50 [crit] 23286#0: *5332 open() "/var/lib/nginx/tmp/client_body/0000000003" failed (13: Permission denied), client: 1.2.3.4, server: _, request: "POST /wp-admin/media-new.php HTTP/1.1", host: "example.com", referrer: "http://example/wp-admin/media-new.php"

Giải pháp:

chown -R www-data:www-data /var/lib/nginx

Theo mặc định, dữ liệu tĩnh khi bạn cài đặt nginx sẽ nằm trong / var / www / html. Vì vậy, bạn chỉ có thể sao chép thư mục tĩnh của mình vào / var / html / và đặt

root /var/www/<your static folder>

trong ngix.conf (hoặc / etc / nginx / sites-available / default)

Điều này làm việc cho tôi trên ubuntu nhưng tôi đoán nó sẽ không khác nhiều đối với các bản phân phối khác.

Hy vọng nó giúp.

Thay đổi nginx.conf usertài sản của bạn thành người www-staticnợ tệp.

#   * Official English Documentation: http://nginx.org/en/docs/
#   * Official Russian Documentation: http://nginx.org/ru/docs/

user your_user_name;

# same other config

Tôi đã gặp phải vấn đề này, tôi đã giải quyết nó để cấp quyền cho người dùng nginx và nhóm một cái gì đó như sau:

chown -R nginx:nginx /username/test/static

Trong trường hợp của tôi, thư mục phục vụ các tệp là một liên kết tượng trưng đến một thư mục khác, được tạo bằng

ln -sf /origin /var/www/destination

Mặc dù các quyền (người dùng và nhóm) đúng trên thư mục đích (liên kết tượng trưng), tôi vẫn gặp lỗi vì Nginx cũng cần có quyền đối với hệ thống phân cấp của toàn bộ thư mục gốc.

Cuối cùng tôi đã tìm thấy con đường của mình. Tóm lại, giả sử tên người dùng của bạn là gì joevà bạn có một trang web trong hệ thống tệp cá nhân của mình /home/joe/path/to/website.

Bạn thực sự phải nói với hệ thống đó nginxlà bạn của bạn.
Xếp nginxvào joenhóm:

sudo gpasswd -a nginx joe

Sau đó, nếu nó vẫn không hoạt động, hãy kiểm tra quyền truy cập của /home/joethư mục. Đó có lẽ là lý do tại sao nginx không thể truy cập được hồ sơ bởi vì ngay cả khi anh ấy là bạn của bạn thì bây giờ bạn vẫn phải mở cho anh ấy cánh cửa vào nhà của bạn:

sudo chmod g+x /home/joe

Đó là nó. Đó thực sự là tất cả những gì bạn phải làm để cấp cho nginx quyền truy cập vào các tệp cục bộ của bạn :)

Tôi không nghĩ rằng có những lo ngại về bảo mật với phương pháp này vì đây nginxlà phương pháp có thẩm quyền cao và chỉ quản trị viên mới có thể thay đổi nhóm. nginxbây giờ có thể đọc những gì trong joethư mục. Đó chỉ là vi phạm bảo mật nếu chủ sở hữu nginxtài khoản khác với người dùng mà bạn mở quyền truy cập thư mục, nhưng trong trường hợp của tôi, tôi là chủ sở hữu của cả hai bên, đó là trong bối cảnh cục bộ.

Tôi đã gặp vấn đề tương tự, tôi đang sử dụng Plesk Onyx 17 với Centos7. Tôi có thể thấy lỗi này trong proxy_error_log trong nhật ký của miền bị ảnh hưởng. Tất cả các dirs / tệp trong / var / www / vhosts / đều thuộc sở hữu của người dùng tương ứng (chủ sở hữu miền) và bạn có thể thấy rằng tất cả chúng đều nằm trong nhóm psacln. Vì vậy, giải pháp là thêm nginx cũng vào nhóm này, để anh ta có thể thấy những gì anh ta cần:

usermod -aG psacln nginx

Và thực sự, hãy khởi động lại nginx và tải lại trang bằng Ctrl + F5.

Tôi đã tìm thấy một công việc xung quanh: Đã chuyển thư mục vào thư mục cấu hình nginx, trong trường hợp của tôi là "/ etc / nginx / my-web-app". Và sau đó thay đổi quyền đối với người dùng root "sudo chown -R root: root" my-web-app ".

Bạn cũng có thể thêm người dùng nào sẽ chạy nginx. Trong tệp nginx.conf, hãy thực hiện các thay đổi sau:

user root;

Bạn có thể thêm dòng trên làm dòng đầu tiên trong tâm sự nginx của mình. Bạn có thể viết tên của bất kỳ người dùng nào có quyền ghi vào thư mục đó.

Đây thường là vấn đề đặc quyền ... Đối với tôi, vì tôi sử dụng / root / ** làm gốc nginx, nó cần đặc quyền cao hơn. Một cách dễ dàng là chỉ cần di chuyển dự án vào một thư mục do chính bạn tạo.