Назад | Перейти на главную страницу

сообщение «Файл не найден». при попытке установить nginx / owncloud

Я пытаюсь использовать nginx в качестве веб-сервера для моей установки owncloud. В соответствии с этот учебник, Я создал следующий файл конфигурации:

server {
        listen 59476;
        server_name mydomain.de;

        root /home/owncloud/www/;

        access_log  /home/owncloud/log/nginx.access.log;
        error_log  /home/owncloud/log/nginx.error.log debug;

        client_max_body_size 10G; # set max upload size
        fastcgi_buffers 64 4K;

        rewrite ^/caldav(.*)$ /remote.php/caldav$1 redirect;
        rewrite ^/carddav(.*)$ /remote.php/carddav$1 redirect;
        rewrite ^/webdav(.*)$ /remote.php/webdav$1 redirect;

        index index.php;
        error_page 403 = /core/templates/403.php;
        error_page 404 = /core/templates/404.php;

        location = /robots.txt {
            allow all;
            log_not_found off;
            access_log off;
        }
        location = /favicon.ico {
            access_log off;
            log_not_found off;
        }

        location ~ ^/(data|config|\.ht|db_structure\.xml|README) {
                deny all;
        }

        location / {
                # The following 2 rules are only needed with webfinger
                rewrite ^/.well-known/host-meta /public.php?service=host-meta last;
                rewrite ^/.well-known/host-meta.json /public.php?service=host-meta-json last;

                rewrite ^/.well-known/carddav /remote.php/carddav/ redirect;
                rewrite ^/.well-known/caldav /remote.php/caldav/ redirect;

                rewrite ^(/core/doc/[^\/]+/)$ $1/index.html;

                try_files $uri $uri/ index.php;
        }

        location ~ ^(.+?\.php)(/.*)?$ {
                try_files $1 = 404;

                include fastcgi_params;
                fastcgi_param SCRIPT_FILENAME $document_root$1;
                fastcgi_param PATH_INFO $2;
                fastcgi_pass unix:/var/run/php5-fpm.sock;
        }

        # Optional: set long EXPIRES header on static assets
        location ~* ^.+\.(jpg|jpeg|gif|bmp|ico|png|css|js|swf)$ {
                expires 30d;
                # Optional: Don't log access to assets
                access_log off;
        }
}

Но когда я захожу на сайт http://mydomain.de:59476 Я получаю только сообщение об ошибке «Файл не найден». Поскольку я установил уровень отладки на «отладка», я получаю следующий обширный файл журнала http://pastebin.com/uy7jHQQs. Я думаю, что самая важная линия - это

2013/08/03 17:23:21 [error] 29508#0: *3 FastCGI sent in stderr: "Primary script unknown" while reading response header from upstream, client: 37.24.146.15, server: mydomain.de, request: "GET / HTTP/1.1", upstream: "fastcgi://unix:/var/run/php5-fpm.sock:", host: "mydomain.de:59476"

Что, как я понял nginx, означает, что файл, который пытается выполнить nginx, не существует. Но в журнале также сказано:

2013/08/03 17:23:21 [debug] 29508#0: *3 fastcgi param: "SCRIPT_FILENAME: /home/owncloud/www/index.php"

и файл /home/owncloud/www/index.php существует.

Чтобы проверить, правильно ли работает только nginx, я настроил другой веб-сайт без owncloud, и все работает отлично (включая поддержку PHP) со следующей конфигурацией:

server {
        listen 59477;
        server_name mydomain.net;
                root   /home/born/web/nginx;
                index index.php;

        # Logging --
        access_log  /home/myuser/logs/nginx.access.log;
        error_log  /home/myuser/logs/nginx.error.log notice;

        # serve static files directly
        location ~* ^.+.(jpg|jpeg|gif|css|png|js|ico|html|xml|txt)$ {
            access_log        off;
            expires           max;
        }

        location ~ \.php$ {
            try_files $uri =404;
            fastcgi_pass unix:/var/run/php5-fpm.sock;
            fastcgi_index index.php;
            include /etc/nginx/fastcgi_params;
        }
}

и следующие fastcgi_params

fastcgi_param   QUERY_STRING            $query_string;
fastcgi_param   REQUEST_METHOD          $request_method;
fastcgi_param   CONTENT_TYPE            $content_type;
fastcgi_param   CONTENT_LENGTH          $content_length;

fastcgi_param   SCRIPT_FILENAME         $request_filename;
fastcgi_param   SCRIPT_NAME             $fastcgi_script_name;
fastcgi_param   REQUEST_URI             $request_uri;
fastcgi_param   DOCUMENT_URI            $document_uri;
fastcgi_param   DOCUMENT_ROOT           $document_root;
fastcgi_param   SERVER_PROTOCOL         $server_protocol;

fastcgi_param   GATEWAY_INTERFACE       CGI/1.1;
fastcgi_param   SERVER_SOFTWARE         nginx/$nginx_version;

fastcgi_param   REMOTE_ADDR             $remote_addr;
fastcgi_param   REMOTE_PORT             $remote_port;
fastcgi_param   SERVER_ADDR             $server_addr;
fastcgi_param   SERVER_PORT             $server_port;
fastcgi_param   SERVER_NAME             $server_name;

fastcgi_param   HTTPS                   $https;

# PHP only, required if PHP was built with --enable-force-cgi-redirect
fastcgi_param   REDIRECT_STATUS         200;

После долгих поисков выяснилось, что ни nginx, ни owncloud не являются причиной появления сообщения «Файл не найден». Я нашел это, остановив службу php5-fpm, которая изменила сообщение на 502 Bad Gateway из nginx.

Соответствующие дочерние процессы nginx выполнялись как пользовательское owncloud (не как www-data), но соответствующие дочерние процессы php5-fpm выполнялись как www-data. Добавление нового пула с новым сокетом, использующим пользовательский owncloud, решило проблему. Сообщение было «Файл не найден» вместо отказа в доступе, потому что пользователю не разрешено читать каталог.

Если вы столкнулись с той же причиной этой проблемы, убедитесь, что nginx обращается к правильному сокету.

@Marco: Спасибо, что уделили мне время.

Имеет ли пользователь nginx право читать из "/ home / owncloud / www /"? И есть ли у него права на /var/run/php5-fpm.sock?

проверить попробуйте:

sudo -u nginx ls /var/run/php5-fpm.sock

и

sudo -u nginx ls /home/owncloud/www/index.php

и используйте ps aux | grep nginx, чтобы проверить, действительно ли он работает как "nginx"