Nginx 403 bị cấm đối với tất cả các tệp


191

Tôi đã cài đặt nginx với PHP-FPM trên hộp CentOS 5, nhưng tôi đang cố gắng để nó phục vụ bất kỳ tệp nào của tôi - cho dù là PHP hay không.

Nginx đang chạy dưới dạng www-data: www-data và trang web "Chào mừng bạn đến nginx trên EPEL" (được sở hữu bởi root: root với 644 quyền) tải tốt.

Tệp cấu hình nginx có một lệnh bao gồm cho /etc/nginx/sites-enables/*.conf và tôi có một tệp cấu hình example.com.conf , do đó:

server {
 listen 80;

 Virtual Host Name
 server_name www.example.com example.com;


 location / {
   root /home/demo/sites/example.com/public_html;
   index index.php index.htm index.html;
 }

 location ~ \.php$ {
  fastcgi_pass   127.0.0.1:9000;
  fastcgi_index  index.php;
  fastcgi_param  PATH_INFO $fastcgi_script_name;
  fastcgi_param  SCRIPT_FILENAME  /home/demo/sites/example.com/public_html$fastcgi_script_name;
  include        fastcgi_params;
 }
}

Mặc dù public_html được sở hữu bởi dữ liệu www: dữ liệu www với quyền truy cập tệp 2777, trang web này không cung cấp bất kỳ nội dung nào -

 [error] 4167#0: *4 open() "/home/demo/sites/example.com/public_html/index.html" failed (13: Permission denied), client: XX.XXX.XXX.XX, server: www.example.com, request: "GET /index.html HTTP/1.1", host: "www.example.com"

Tôi đã tìm thấy nhiều bài đăng khác với người dùng nhận 403 từ nginx, nhưng hầu hết những gì tôi thấy đều liên quan đến các thiết lập phức tạp hơn với Ruby / Pasbah (trước đây tôi thực sự đã thành công) hoặc chỉ nhận được lỗi khi PHP ngược dòng -FPM có liên quan, vì vậy họ dường như rất ít giúp đỡ.

Tôi đã làm điều gì đó ngớ ngẩn ở đây?


kiểm tra câu trả lời này stackoverflow.com/questions/16808813/ từ
sandes

Câu trả lời:


333

Một yêu cầu cấp phép thường bị bỏ qua là người dùng cần x quyền trong mọi thư mục mẹ của tệp để truy cập tệp đó. Kiểm tra các quyền trên /, / home, / home / demo, v.v. để truy cập www-data x. Tôi đoán là / nhà có lẽ là 770 và dữ liệu www không thể truy cập thông qua nó để đến bất kỳ thư mục con nào. Nếu có, hãy thử chmod o + x / home (hoặc bất kỳ thư mục nào đang từ chối yêu cầu).

EDIT: Để dễ dàng hiển thị tất cả các quyền trên một đường dẫn, bạn có thể sử dụng namei -om /path/to/check


6
Tương tự ở đây. Khi tôi cài đặt CentOS 6, các thư mục / home / user được đặt thành 700 theo mặc định.
jjt

2
Anh chàng này cũng nói về nó: ( chmod -4 +x /mypathlàm việc cho tôi) nginxl Library.com/403-forbidden-error
Peter Ehrlich

1
Ai đó có thể giải thích tại sao hành vi này khác với apache mà KHÔNG yêu cầu mọi thư mục mẹ phải có quyền "x" không?!?
JoshuaDavid

3
Nó không có gì khác biệt. Lý do duy nhất apache sẽ không yêu cầu quyền x trên các thư mục mẹ là nếu nó chạy bằng root.
kolbyjack

Cuối cùng tôi đã thêm người dùng dữ liệu www vào nhóm người dùng cá nhân của mình và thực hiện chmod 710 vào thư mục người dùng gốc của mình. Làm việc như người ở. (Trên một distro dựa trên Debian)
basicdays

298

Nếu bạn vẫn thấy permission deniedsau khi xác minh quyền của các thư mục mẹ, thì đó có thể là TỰ ĐỘNG hạn chế quyền truy cập.

Để kiểm tra xem Selinux có đang chạy hay không:

# getenforce

Để vô hiệu hóa SELinux cho đến khi khởi động lại tiếp theo:

# setenforce Permissive

Khởi động lại Nginx và xem nếu vấn đề vẫn còn. Để cho phép nginx phục vụ thư mục www của bạn (đảm bảo bạn bật lại Selinux trước khi kiểm tra điều này. Tức là setenforce Enforcing)

# chcon -Rt httpd_sys_content_t /path/to/www

Xem câu trả lời của tôi ở đây để biết thêm chi tiết


1
Tôi không thể hiểu tại sao bất cứ khi nào tôi bắt đầu nginx, nó nói open() "/usr/share/nginx/logs/xxxxxx.com-error_log" failed (13: Permission denied)sau khi tôi kiểm tra các quyền và đảm bảo rằng nó đã được bắt đầu như root. Tôi đã xem qua điều này và phát hiện ra Selinux đã được bật. Tôi đã vô hiệu hóa nó và bây giờ nó hoạt động không có vấn đề. Cảm ơn!
ub3rst4r

1
Cảm ơn! Tôi vẫn gặp sự cố với quyền bị từ chối vì người dùng sở hữu ổ cắm FPM của riêng họ vì vậy tôi có thể khắc phục sự cố đó bằng cách thay đổi usertừ nginx sang root trong /var/nginx/nginx.conf- có lẽ điều đó sẽ giúp người khác gặp phải vấn đề này. S / O đến DataPsyche cho phần thứ hai.
Mùa đông

11
Đây là hành vi mặc định trên CentOS 7.
timss 14/2/2015

4
Tôi với mọi người khác mà bình luận. Tôi đã sẵn sàng để ném máy tính của tôi ra khỏi cửa sổ. Nginx đã được cấu hình đúng, quyền được đặt đúng, tôi thậm chí đã đi xa để tạo mọi thứ 777 và vẫn bị lỗi từ chối.
DOfficial

2
Trên Centos 7 (đã bật tính năng SELinux), cách khắc phục đơn giản nhất đối với tôi là setsebool httpd_read_user_content on(Đối với các tệp tĩnh được lưu trữ từ thư mục chính, có thể đọc được trên thế giới) - Mặc dù tôi đoán phương pháp của @ KapiteinWitbaard ở trên an toàn hơn.
TimStaley

61

Tôi đã giải quyết vấn đề này bằng cách thêm cài đặt người dùng.

trong nginx.conf

worker_processes 4;
user username;

thay đổi 'tên người dùng' với tên người dùng linux.


4
Tôi tin rằng câu trả lời này là bảo mật tốt hơn khôn ngoan hơn câu trả lời được chấp nhận. Bạn không cần phải loay hoay với các quyền trên thư mục nhà của mình (có thể chứa thông tin nhạy cảm) và nếu bạn đang phát triển với nginx, nó sẽ giúp bạn không phải tải các quyền của tệp lạ lên SCM.
CamelBlues

Các quyền được thêm vào thư mục chính được thực thi, không được đọc, do đó, không có thông tin nhạy cảm nào (về lý thuyết) được tiết lộ (ngoại trừ, trong trường hợp này, có lẽ là một tập lệnh PHP độc hại đệ quy lên trên và biết vị trí của các tệp nhạy cảm trong thư mục khác có thể truy cập dữ liệu www). Bạn cũng sẽ nhận thấy rằng trong câu hỏi ban đầu, nginx của tôi đang chạy dưới dạng "dữ liệu www" - các giá trị cấu hình ở đây đã được đặt như mong muốn.
Angus Ireland

2
Phải thêm nhóm người dùng: người dùng usegroup.
Gabriel A. Zorrilla

Làm việc cho tôi là tốt (giống như chmodding dir đến nginx: nginx). Tôi thích giải pháp này hơn vì vậy tôi có thể sở hữu tài liệu gốc của mình bởi một người dùng khác ngoài nginx. Cảm ơn Anderson đã chỉ ra điều này.
kvv

đã cứu ngày của tôi. Nhân tiện, nếu máy có nhiều người dùng và mỗi người dùng có trang web riêng, tôi phải xử lý như thế nào?
psychok7

38

Tôi đã gặp lỗi này và cuối cùng tôi đã giải quyết nó bằng lệnh bên dưới.

restorecon -r /var/www/html

Vấn đề được gây ra khi bạn mv một cái gì đó từ nơi này đến nơi khác. Nó bảo tồn bối cảnh selinux của bản gốc khi bạn di chuyển nó, vì vậy nếu bạn gỡ bỏ một cái gì đó trong / home hoặc / tmp, nó sẽ được cung cấp một bối cảnh selinux phù hợp với vị trí của nó. Bây giờ bạn mv rằng / var / www / html và nó lấy bối cảnh nói rằng nó thuộc / tmp hoặc / home với nó và httpd không được chính sách cho phép truy cập vào các tệp đó.

Nếu bạn cp các tệp thay vì mv chúng, bối cảnh selinux sẽ được chỉ định theo vị trí bạn đang sao chép, không phải nơi nó đến. Chạy restorecon đặt bối cảnh trở lại mặc định của nó và cũng sửa nó.


1
Cảm ơn @jsina, điều này đã giúp tôi rất nhiều
Pankaj Garg

1
Chết tiệt, +1 , tôi cũng vậy.
jww

24

Tôi đã thử các trường hợp khác nhau và chỉ khi chủ sở hữu được đặt thành nginx ( chown -R nginx:nginx "/var/www/myfolder") - nó mới bắt đầu hoạt động như mong đợi.


1
Làm việc cho tôi là tốt. Tôi nghi ngờ điều này xảy ra bởi vì mặc dù nginx được bắt đầu bằng root, nhưng nó sinh ra các tiến trình theo người dùng được chỉ định trong tệp nginx.conf, đó là "user nginx;" theo mặc định Thay đổi người dùng thành người dùng sở hữu tài liệu gốc của bạn cũng sẽ hoạt động như Anderson đề xuất.
kvv

Ông Anderson? Không! Andron;)
Andron

Xin lỗi ông Andron;) Tôi dường như không thể chỉnh sửa bình luận trước đó nữa ...
kvv

Chắc chắn, không phải là một vấn đề. Bây giờ tôi đã là Anderson :) và cần viết một số truyện cổ tích ...
Andron

1
Đây không phải là một vấn đề bảo mật?
Gontard

6

Nếu bạn đang sử dụng SELinux, chỉ cần gõ:

sudo chcon -v -R --type=httpd_sys_content_t /path/to/www/

Điều này sẽ khắc phục vấn đề cho phép.


1

Câu hỏi cũ, nhưng tôi đã có cùng một vấn đề. Tôi đã thử mọi câu trả lời ở trên, không có gì hiệu quả. Điều đã sửa nó cho tôi mặc dù đã xóa tên miền và thêm nó một lần nữa. Tôi đang sử dụng Plesk và tôi đã cài đặt Nginx SAU tên miền đã ở đó.

Đã sao lưu cục bộ thành / var / www / sao lưu trước. Vì vậy, tôi có thể dễ dàng sao chép lại các tập tin.

Vấn đề kỳ lạ ....


1

Chúng tôi có cùng một vấn đề, sử dụng Plesk Onyx 17. Thay vì gây rối với các quyền, v.v., giải pháp là thêm người dùng nginx vào nhóm psacln, trong đó tất cả các chủ sở hữu tên miền (người dùng) khác là:

usermod -aG psacln nginx

Bây giờ nginx có quyền truy cập .htaccess hoặc bất kỳ tệp nào khác cần thiết để hiển thị đúng nội dung.

Mặt khác, cũng đảm bảo rằng Apache nằm trong nhóm psaserv, để phục vụ nội dung tĩnh:

usermod -aG psaserv apache

Và đừng quên khởi động lại cả Apache và Nginx trong Plesk sau! (và tải lại các trang bằng Ctrl-F5)


Đây là câu trả lời đúng và rất có thể usermod -aG username www-datatrên hầu hết các thiết lập.
Dario Zadro

0

Tôi tự đào sâu vào một biến thể nhỏ của vấn đề này bằng cách chạy nhầm setfacllệnh. Tôi đã chạy

sudo setfacl -m user:nginx:r /home/foo/bar

Tôi đã từ bỏ tuyến đường này để ủng hộ việc thêm nginxvào foonhóm, nhưng ACL tùy chỉnh đó đã cản trở nỗ lực truy cập tệp của nginx. Tôi xóa nó bằng cách chạy:

sudo setfacl -b /home/foo/bar

Và sau đó nginx đã có thể truy cập các tập tin.


0

Nếu bạn đang sử dụng PHP, hãy đảm bảo lệnh indexNGINX trong khối máy chủ chứa index.php:

index index.php index.html;

Để biết thêm thông tin, hãy kiểm tra chỉ thị trong tài liệu chính thức.


0

Tôi đã phải đối mặt với cùng một vấn đề nhưng các giải pháp trên không giúp được gì.

Vì vậy, sau rất nhiều cuộc đấu tranh, tôi phát hiện ra rằng sestatus đã được thiết lập để thực thi việc chặn tất cả các cổng và bằng cách đặt nó cho phép tất cả các vấn đề đã được giải quyết.

sudo setenforce 0

Hy vọng điều này sẽ giúp một người như tôi.


Trong khi điều đó có thể đã khắc phục vấn đề của bạn - xin chúc mừng! - đó là một chút buồn :-( Xem stopdisablingselinux.com - bạn có thể tìm thấy một cách giải quyết khác không?
Angus Ireland
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.