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

давайте рассмотрим, что мы устраняем неполадки в следующей строке:

require "/path/to/file"

памятка

1. Проверьте путь к файлу для опечаток

• либо проверьте вручную (визуально проверив путь)

• или переместить все вызывается require* или include* в свою собственную переменную, повторите ее, скопируйте и попробуйте получить доступ к ней с терминала:

  $path = "/path/to/file";
  
  echo "Path : $path";
  
  require "$path";
  

  затем в терминале:

  cat <file path pasted>
  

2. Убедитесь, что путь к файлу верен относительно относительного и абсолютного пути

• если он начинается с косой черты"/", то это не относится к корню папки вашего сайта( корню документа), а к корню ваш сервер.
  • например, каталог вашего сайта может быть /users/tony/htdocs
• если он не запускается прямой косой чертой, то он либо полагается на путь включения (см. ниже), либо путь относителен. Если это относительно, то PHP будет вычислять относительно пути текущий рабочий каталог.
  • таким образом, не относительно пути корня вашего сайта или файла, в котором вы находитесь набрав
  • по этой причине, всегда используйте абсолютные пути к файлам

рекомендации :

чтобы сделать ваш скрипт надежным, если вы перемещаете вещи, все еще генерируя абсолютный путь во время выполнения, у вас есть 2 варианта:

1. использовать require __DIR__ . "/relative/path/from/current/file". The __DIR__ магической константы возвращает каталог текущего файла.

2. определение SITE_ROOT константы себе :

   • в корневом каталоге вашего сайта создайте файл, например config.php

   • на config.php пишите

     define('SITE_ROOT', __DIR__);
     

   • в каждом файле, где вы хотите ссылаться на корневую папку сайта, включите config.php, а затем использовать SITE_ROOT константы везде, где вам нравится :

     require_once __DIR__."/../config.php";
     ...
     require_once SITE_ROOT."/other/file.php";
     

эти 2 практики также делают ваше приложение более портативным, потому что оно не полагается на ini такие параметры, как путь включения.

3. Проверьте свой путь включения

другой способ включить файлы, ни относительно, ни чисто абсолютно, - это полагаться на включить путь. Это часто имеет место для библиотек или фреймворков, таких как Zend framework.

такое включение будет выглядеть так:

include "Zend/Mail/Protocol/Imap.php"

в этом случае вы захотите убедиться, что папка, в которой находится "Zend", является частью пути включения.

вы можете проверить пути с :

echo get_include_path();

вы можете добавить в папку с :

set_include_path(get_include_path().":"."/path/to/new/folder");

4. Проверьте, что ваш сервер имеет доступ к этому файлу

возможно, что в целом пользователь, выполняющий серверный процесс (Apache или php), просто не имеет разрешения на чтение или запись в этот файл.

чтобы проверить под каким пользователем запущен сервер можно использовать posix_getpwuid :

$user = posix_getpwuid(posix_geteuid());

var_dump($user);

чтобы узнать разрешения на файл, введите в терминале следующую команду:

ls -l <path/to/file>

и посмотрите на разрешение символическая нотация

5. Проверьте настройки PHP

если ничего из вышеперечисленного не сработало, то проблема, вероятно, в том, что некоторые настройки PHP запрещают ему доступ к этому файлу.

3 установки смогли быть уместны :

1. функции
   • если это установлено, PHP не сможет получить доступ к любому файлу за пределами указанного каталога (даже через символическую ссылку).
   • однако поведение по умолчанию для него не должно быть установлено, и в этом случае нет никаких ограничений
   • это можно проверить, позвонив phpinfo() и с помощью ini_get("open_basedir")
   • вы можете изменить настройки, либо путем редактирования РНР.ini-файл или ваш httpd.файл conf
2. безопасный режим
   • если это включено, могут применяться ограничения. Однако это было удалено в PHP 5.4. Если вы все еще находитесь в версии, поддерживающей безопасный режим обновления до версии PHP, которая все еще поддерживается.
3. опция allow_url_fopen и allow_url_include
   • это относится только к включению или открытие файлов через сетевой процесс, такой как http:// not при попытке включить файлы в локальную файловую систему
   • это можно проверить с помощью ini_get("allow_url_include") и ini_set("allow_url_include", "1")

случаев углу

если ни один из вышеперечисленных не позволяет диагностировать проблему, вот некоторые специальные ситуации, которые могут произойти:

1. Включение библиотеки, опираясь на путь

может случиться так, что вы включаете библиотеку, например Zend framework, используя относительный или абсолютный путь. Например :

require "/usr/share/php/libzend-framework-php/Zend/Mail/Protocol/Imap.php"

но тогда вы все равно получите ту же ошибку.

это может произойти потому, что файл, который вы (успешно) включили, имеет сам оператор include для другого файла, и этот второй оператор include предполагает, что вы добавили путь этой библиотеки к пути include.

для например, файл Zend framework, упомянутый ранее, может иметь следующее значение:

include "Zend/Mail/Protocol/Exception.php" 

который не является включением ни относительным путем, ни абсолютным путем. Предполагается, что каталог Zend framework добавлен в путь включения.

в таком случае, единственным практическим решением является добавление в каталог к вашему пути.

2. В SELinux

если вы работаете с улучшенной безопасностью Linux, то это может быть причиной проблемы, отказывая в доступе к файлу с сервера.

чтобы проверить, включен ли SELinux в вашей системе запустите sestatus команда в терминале. Если команда не существует, то SELinux не в системе. Если он существует, то он должен сказать вам, является ли он принудительным или нет.

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

setenforce 0

если у вас больше нет проблемы с выключенным SELinux, то это является основной причиной.

решить, вам придется настроить SELinux соответственно.

необходимы следующие типы контекста:

• httpd_sys_content_t для файлов, которые вы хотите, чтобы ваш сервер мог читать
• httpd_sys_rw_content_t для файлов, которые вы хотите читать и писать к
• httpd_log_t для файлов журнала
• httpd_cache_t для каталога кэша

например, чтобы назначить httpd_sys_content_t введите контекст в корневой каталог вашего сайта, запустите:

semanage fcontext -a -t httpd_sys_content_t "/path/to/root(/.*)?"
restorecon -Rv /path/to/root

если ваш файл находится в домашнем каталоге, вы также должны включить httpd_enable_homedirs boolean:

setsebool -P httpd_enable_homedirs 1

в любом случае, могут быть различные причины почему SELinux будет отказывать в доступе к файлу, в зависимости от ваших политик. Поэтому вам нужно будет исследовать это. здесь - это учебник по настройке SELinux для веб-сервера.

3. В Symfony

если вы используете Symfony и испытываете эту ошибку при загрузке на сервер, то может быть, что кэш приложения не был сброшен, либо потому что app/cache был загружен, или этот кэш не был очищенный.

вы можете проверить и исправить это, выполнив следующую команду:

cache:clear

4. Не символы ACSII внутри Zip-файла

по-видимому, эта ошибка может произойти и при вызове zip->close() когда некоторые файлы внутри zip имеют символы не ASCII в их имени файла, такие как "é".

потенциальным решением является обертывание имени файла в utf8_decode() перед созданием целевой файл.

кредиты Фран Кано для определения и предложения решения этой проблемы