Nginx возвращает 404 при новой установке

Nginx возвращает 404 при новой установке

На Linux Mint 20.3 у меня была рабочая настройка для локальной разработки веб-сайта:

server {
    listen 80;
    listen [::]:80;

    server_name cbp.local;

    root /home/gacek/html/cbp/public;

    index           index.php;

    location / {
        try_files   $uri $uri/ /index.php?$query_string;
    }

    if (!-d $request_filename) {
            rewrite     ^/(.+)/$ /$1 permanent;
    }

    location ~ \.php$ {
                include snippets/fastcgi-php.conf;
                fastcgi_pass unix:/var/run/php/php8.2-fpm.sock;
        }
}

Это приложение Laravel, расположенное в /home/gacek/html/cbpкаталоге, а index.phpточка входа находится в /publicподпапке.

После новой установки Linux Mint 21.1 та же конфигурация nginx выдает мне ошибку 404 not found:

404 Не найдено nginx/1.18.0 (Ubuntu)

Я пытался:

  • настройка права собственности на каталог: sudo chown -R gacek:www-data /home/gacek/html/cbp

  • расширение разрешений:sudo chmod -R 776 /home/gacek/html/cbp

  • создание символической ссылки и настройка файла конфигурации nginxsudo ln -s /home/gacek/html/cbp /var/www/

Последнее, что я попробовал, так как следующая конфигурация работает отлично:

server {
    listen 80;
    listen [::]:80;

    server_name example.local;

    root /var/www/test;
    index index.php;

    location / {
        try_files   $uri $uri/ /index.php?$query_string;
    }

    location ~ \.php$ {
                include snippets/fastcgi-php.conf;
                fastcgi_pass unix:/var/run/php/php8.2-fpm.sock;
    }
}

Почему эта конфигурация сайта nginx не работает? В чем разница между ними?

РЕДАКТИРОВАТЬ

Я изменил конфигурацию, используяруководство по документации Laravel:

server {
    listen 80;
    listen [::]:80;
    server_name cbp.local;
    root /home/gacek/html/cbp/public;
 
    add_header X-Frame-Options "SAMEORIGIN";
    add_header X-Content-Type-Options "nosniff";
 
    index index.php;
 
    charset utf-8;
 
    location / {
        try_files $uri $uri/ /index.php?$query_string;
    }
 
    location = /favicon.ico { access_log off; log_not_found off; }
    location = /robots.txt  { access_log off; log_not_found off; }
 
    error_page 404 /index.php;
 
    location ~ \.php$ {
        include fastcgi_params;
        fastcgi_pass unix:/var/run/php/php8.2-fpm.sock;
        fastcgi_param SCRIPT_FILENAME /home/gacek/html/cbp/public$fastcgi_script_name;
    }
 
    location ~ /\.(?!well-known).* {
        deny all;
    }
}

После этого изменения ошибка, отображаемая на странице, изменилась на:

File not found.

И теперь я получаю следующие ошибки в журнале ошибок nginx:

введите описание изображения здесь

решение1

Мне кажется, что вы уже почти все сделали — вы создали специальный каталог для размещения контента и применили к нему соответствующие разрешения, хотя вы и не подтвердили, под каким пользователем запущен nginx и является ли этот пользователь членом группы на www-dataхосте.

Я бы предложил добавить пользователя, под управлением которого запущен nginx, в www-dataгруппу и убедиться, что у этой группы есть соответствующие разрешения.

На самом деле я бы рекомендовал вам не делать каталог содержимого доступным для записи по умолчанию, как вы это сделали, если у вас нет особой причины для этого. А если у вас есть особая причина для этого, я бы, вероятно, создал специальный подкаталог, который будет доступен для записи, в то время как корневой — нет.

Итак, вкратце, вероятно:

usermod -aG nginx www-data
chmod -R 755 /home/gacek/html/cbp

На самом деле вы можете пойти еще дальше и ужесточить права доступа к каталогам, применив вышеизложенное только к каталогам/подкаталогам и применив chmod 644ко всем файлам.

Редактировать:выполнив поиск в Интернете от вашего именив другом месте, это кажется хорошим кандидатом на потенциальную проблему: у вас может быть ProtectHome=trueв файле инициализации systemd для php-fpm.service.

  1. Установить ProtectHome=falseв/etc/systemd/system/multi-user.target.wants/php-fpm.service
  2. systemctl daemon-reload
  3. systemctl restart nginx.service
  4. systemctl restart php-fpm.service

По иронии судьбы, я лично отметил странность того, что вы изначально поместили код в домашнюю папку, а не, например, /var/www/html/но решил оставить это при себе — оказалось, это было важно!

Связанный контент