PHP - Не удалось открыть поток: нет такого файла или каталога


167

В PHP скриптах, называя ли include(), require(), fopen()или их производные , такие как include_once, require_onceили даже move_uploaded_file(), часто впадает в ошибки или предупреждения:

Не удалось открыть поток: нет такого файла или каталога.

Что такое хороший процесс, чтобы быстро найти причину проблемы?


5
Я убрал не по теме комментарии к этому посту. Пожалуйста, держите мета обсуждения в мета. Тем не менее, обратите внимание, что обсуждение жизнеспособности канонических вопросов повторяется снова и снова. Смотрите пример здесь .
Призрак Мадары

1
У меня та же проблема, единственное решение, которое работало всегда: -1 Перейдите к файлу, чтобы включить, правильно, свойства, скопировать полный путь Например: C: /......../ file.php 2- включить его. На самом деле я увидел, что на этот вопрос дан ответ, и ответ подтвержден, но у меня в некоторых случаях не получалось, пока я не нашел способ, описанный выше.
Рашад

@Rash спасибо за помощь. К сожалению, ваше решение неверно, потому что в нем будет указано абсолютное имя пути, а это неверно. Причина, по которой это неправильно, заключается в том, что в тот момент, когда вы копируете свой проект в другое место или перемещаете его в свой компьютер, все разрушается.
Vic Seedoubleyew

Ответы:


260

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

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

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". __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.

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

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 запрещают ему доступ к этому файлу.

Три настройки могут быть актуальны:

  1. open_basedir
    • Если это установлено, PHP не сможет получить доступ ни к какому файлу за пределами указанного каталога (даже через символическую ссылку).
    • Тем не менее, поведение по умолчанию для него не должно быть установлено, в этом случае нет никаких ограничений
    • Это можно проверить по телефону phpinfo()или с помощьюini_get("open_basedir")
    • Вы можете изменить настройку, отредактировав файл php.ini или файл httpd.conf.
  2. безопасный режим
    • если это включено, ограничения могут применяться. Однако это было удалено в PHP 5.4. Если вы все еще используете версию, которая поддерживает безопасный режим, обновите ее до версии PHP, которая все еще поддерживается .
  3. allow_url_fopen и allow_url_include
    • это относится только к включению или открытию файлов через сетевой процесс, такой как http: // не при попытке включить файлы в локальную файловую систему
    • это можно проверить с помощью 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"

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

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

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

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

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

В таком случае единственное практическое решение - добавить каталог к ​​вашему пути включения.


2. SELinux

Если вы работаете в Security-Enhanced 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логическое значение:

setsebool -P httpd_enable_homedirs 1

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


3. Symfony

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

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

cache:clear


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

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

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

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


4
Я думаю, что упоминание о selinuxможет быть хорошей идеей здесь. по крайней мере, вам нужно httpd_sys_content_tразрешение (директории только для чтения и файлы, используемые Apache) на включенные файлы.
Банси

Большое спасибо за предложение. Поскольку я не знаком с SELinux, я немного почитал и попытался ответить на этот вопрос. Пожалуйста, не стесняйтесь оставлять отзывы или предлагать некоторые изменения, если они не верны. Еще раз спасибо за комментарий!
Вик Седублюев

chconявляется временным и не переживет restoreconили перезагрузки. Возможно, вам придется использовать semanageдля изменения контекста файла. Вот хороший простой урок для веб-сайта
Банси

Еще одна возможность добавить: кэширование в реальном
пути

@chrishiestand спасибо большое! Эта статья действительно интересная! Вы помните, как развивались события, которые привели к этой ошибке? Было ли это, что изначально у пользователя не было доступа для чтения к файлу, затем он изменился, но кэш все еще считал, что он не читается, поэтому выдает эту ошибку при открытии файла?
Vic Seedoubleyew

16

Добавить (действительно хороший) существующий ответ

Программное обеспечение Shared Hosting

open_basedirэто тот, который может поставить вас в тупик, потому что он может быть указан в конфигурации веб-сервера. Хотя это легко исправить, если вы запускаете свой собственный выделенный сервер, существуют некоторые пакеты программного обеспечения для общего хостинга (такие как Plesk, cPanel и т. Д.), Которые настраивают директиву конфигурации для каждого домена. Поскольку программное обеспечение создает файл конфигурации (то есть httpd.conf), вы не можете изменить этот файл напрямую, потому что программное обеспечение хостинга просто перезапишет его при перезапуске.

С Plesk они предоставляют место для переопределения предоставленного httpd.confвызова vhost.conf. Только администратор сервера может написать этот файл. Конфигурация для Apache выглядит примерно так

<Directory /var/www/vhosts/domain.com>
    <IfModule mod_php5.c>
        php_admin_flag engine on
        php_admin_flag safe_mode off
        php_admin_value open_basedir "/var/www/vhosts/domain.com:/tmp:/usr/share/pear:/local/PEAR"
    </IfModule>
</Directory>

Попросите администратора сервера проконсультироваться с руководством по использованию программного обеспечения хостинга и веб-сервера, которое они используют.

Файловые права

Важно отметить, что выполнение файла через ваш веб-сервер сильно отличается от выполнения командной строки или задания cron. Большая разница в том, что у вашего веб-сервера есть свой пользователь и права доступа. По соображениям безопасности этот пользователь довольно ограничен. Apache, например, часто бывает apache, www-dataили httpd( в зависимости от сервера). Задание cron или выполнение CLI имеет любые разрешения, которые есть у пользователя, выполняющего его (т. Е. Запуск сценария PHP от имени root будет выполняться с разрешениями root).

Часто люди решают проблему с разрешениями, выполняя следующее (пример Linux)

chmod 777 /path/to/file

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

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

  1. Этот пользователь владеет файлом и, возможно, родительским каталогом (особенно родительским каталогом, если вы хотите записывать файлы). В большинстве сред общего хостинга это не будет проблемой, потому что ваш пользователь должен владеть всеми файлами под вашим корнем. Пример Linux показан ниже

     chown apache:apache /path/to/file
  2. Пользователь и только этот пользователь имеет доступ. В Linux хорошей практикой будет chmod 600(только владелец может читать и писать) или chmod 644(владелец может писать, но каждый может читать)

Вы можете прочитать более подробное обсуждение разрешений Linux / Unix и пользователей здесь


7
  1. Посмотрите на точную ошибку

Мой код работал нормально на всех машинах, но только на этом начали возникать проблемы (которые раньше работали, я думаю). Использовал echo "document_root" путь для отладки, а также внимательно посмотрел на ошибку, нашел это

Предупреждение: include ( D: /MyProjects/testproject//functions/connections.php ): не удалось открыть поток:

Вы можете легко увидеть, где проблемы. Проблемы // перед функциями

$document_root = $_SERVER['DOCUMENT_ROOT'];
echo "root: $document_root";
include($document_root.'/functions/connections.php');

Так что просто удалите накладную / из include, и она должна работать нормально. Что интересно, это поведение отличается в разных версиях. Я запускаю один и тот же код на ноутбуке, Macbook Pro и на этом ПК, пока все работало нормально. Надеюсь, это кому-нибудь поможет.

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

Чем это отличается от шага 1 контрольного списка ниже?
Vic Seedoubleyew

Шаг 2 - дополнительная проверка, не связанная с шагом 1. Просто перейдите к предложенному пути в браузере и посмотрите, видите ли вы там файл (нет в проводнике Windows, но в браузере).
Хаммад Хан

2

Добавить скрипт с параметрами запроса

Это был мой случай. На самом деле это ссылка на вопрос # 4485874 , но я собираюсь объяснить это здесь в ближайшее время.
Когда вы пытаетесь потребовать path/to/script.php?parameter=value, PHP ищет файл с именем script.php?parameter=value, потому что UNIX позволяет вам иметь такие пути.
Если вы действительно должны передать некоторые данные включены сценарии, просто объявить его как $variable=...или $GLOBALS[]=...или другим способом , вам нравится.


2

Акции Самбы

Если у вас есть тестовый сервер Linux, и вы работаете с клиентом Windows, общий ресурс Samba вмешивается в команду chmod . Итак, даже если вы используете:

chmod -R 777 myfolder

на стороне Linux вполне возможно, что Unix Group \ www-data все еще не имеет доступа для записи. Одно из рабочих решений, если ваш общий ресурс настроен так, что администраторы Windows сопоставлены с root: в Windows откройте Permissions, отключите Inheritance для вашей папки с копией, а затем предоставьте полный доступ для www-данных.


1

Другая возможная причина: переименование и / или перемещение файлов в текстовом редакторе. Я прошел все вышеописанные шаги безуспешно, пока не удалил файл, который продолжал выдавать эту ошибку, и создал новый, который исправил проблему.


1
если я правильно понимаю, что вы имеете в виду правильно, это было бы сразу же устранить неполадки при первой проверке в списке
Вик Seedoubleyew

# 1 не ясно о потенциальных причинах
zMeadz

да, но вы не заботитесь о причинах, вы заботитесь о том, чтобы найти способ решить проблему. Что еще более важно, шаг № 1 решил бы вашу проблему
Вик Seedoubleyew
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.