PHP failed to open stream: No such file or directory в чем ошибка?

Warning: move_uploaded_file(/img/test.jpg): failed to open stream: No such file or directory in C:\server\Apache\Apache24\htdocs\www1\api\create.php on line 17

• Вопрос задан более трёх лет назад
• 1324 просмотра

FILE IS img/test.jpg
Warning: move_uploaded_file(img/test.jpg): failed to open stream: No such file or directory in C:\server\Apache\Apache24\htdocs\www1\api\create.php on line 17

Warning: move_uploaded_file(): Unable to move ‘C:\server\Apache\Apache24\htdocs\www1\img\php50A0.tmp’ to ‘img/test.jpg’ in C:\server\Apache\Apache24\htdocs\www1\api\create.php on line 17
file is not moved

xymox72k: win7 x64. Я тут попытался воспроизвести ваш пример, поставил xampp,
написал простой пример с использованием относительных путей и copy/unlink/fileExists.
Вроде всё работает, относительные пути без каких-либо фокусов разрешаются. Может я конечно чего не понял, плохо пример воспроизвел.

Никита Полевой: я благодарю за ваш проявленный интерес, и верю что работает у вас. Вы какие-нибудь настройки проводили в php.ini ? Права доступа к папке? Просто я везде облазил, и мой скрипт тоже должен работать. Но когда указываешь абсолютный путь с диска C:/бла/бла то, скрипт работает, но так делать не нужно, ибо помимо php используется sql, и js ajax.

В php я не силен, всю жизнь программировал на C#, и там проблема с путями и экранизацией слешем — это банальные вещи и решаются без танцев.

xymox72k: именно для этих нужд в окружении любого сервера доступна переменная:
$_SERVER[‘DOCUMENT_ROOT’]
которая сама проставит абсолютный путь до корня вэб-сервера, а дальше:
$_SERVER[‘DOCUMENT_ROOT’] . «img/one/more/path»;
будет корректно работать на любой оси.

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

xymox72k: нет, php.ini дефолтный, права к папке у пользователя полные (кроме «особого разрешения»).

Попробуйте почитать в гугле вопросы/статейки по запросу «php windows relative path doesn’t work», там некоторые советуют всякие хитрые функции, может поможет.

PHP — Failed to open stream : No such file or directory

In PHP scripts, whether calling include() , require() , fopen() , or their derivatives such as include_once , require_once , or even, move_uploaded_file() , one often runs into an error or warning:

Failed to open stream : No such file or directory.

What is a good process to quickly find the root cause of the problem?

7 Answers 7

There are many reasons why one might run into this error and thus a good checklist of what to check first helps considerably.

Let’s consider that we are troubleshooting the following line:

Checklist

1. Check the file path for typos

either check manually (by visually checking the path)

or move whatever is called by require* or include* to its own variable, echo it, copy it, and try accessing it from a terminal:

Then, in a terminal:

2. Check that the file path is correct regarding relative vs absolute path considerations

• if it is starting by a forward slash «/» then it is not referring to the root of your website’s folder (the document root), but to the root of your server.
  • for example, your website’s directory might be /users/tony/htdocs
• if it is not starting by a forward slash then it is either relying on the include path (see below) or the path is relative. If it is relative, then PHP will calculate relatively to the path of the current working directory.
  • thus, not relative to the path of your web site’s root, or to the file where you are typing
  • for that reason, always use absolute file paths

In order to make your script robust in case you move things around, while still generating an absolute path at runtime, you have 2 options :

use require __DIR__ . «/relative/path/from/current/file» . The __DIR__ magic constant returns the directory of the current file.

define a SITE_ROOT constant yourself :

at the root of your web site’s directory, create a file, e.g. config.php

in config.php , write

in every file where you want to reference the site root folder, include config.php , and then use the SITE_ROOT constant wherever you like :

These 2 practices also make your application more portable because it does not rely on ini settings like the include path.

3. Check your include path

Another way to include files, neither relatively nor purely absolutely, is to rely on the include path. This is often the case for libraries or frameworks such as the Zend framework.

Such an inclusion will look like this :

In that case, you will want to make sure that the folder where «Zend» is, is part of the include path.

You can check the include path with :

You can add a folder to it with :

4. Check that your server has access to that file

It might be that all together, the user running the server process (Apache or PHP) simply doesn’t have permission to read from or write to that file.

To check under what user the server is running you can use posix_getpwuid :

To find out the permissions on the file, type the following command in the terminal:

5. Check PHP settings

If none of the above worked, then the issue is probably that some PHP settings forbid it to access that file.

Three settings could be relevant :

1. open_basedir
   • If this is set PHP won’t be able to access any file outside of the specified directory (not even through a symbolic link).
   • However, the default behavior is for it not to be set in which case there is no restriction
   • This can be checked by either calling phpinfo() or by using ini_get(«open_basedir»)
   • You can change the setting either by editing your php.ini file or your httpd.conf file
2. safe mode
   • if this is turned on restrictions might apply. However, this has been removed in PHP 5.4. If you are still on a version that supports safe mode upgrade to a PHP version that is still being supported.
3. allow_url_fopen and allow_url_include
   • this applies only to including or opening files through a network process such as http:// not when trying to include files on the local file system
   • this can be checked with ini_get(«allow_url_include») and set with ini_set(«allow_url_include», «1»)

Corner cases

If none of the above enabled to diagnose the problem, here are some special situations that could happen :

1. The inclusion of library relying on the include path

It can happen that you include a library, for example, the Zend framework, using a relative or absolute path. For example :

But then you still get the same kind of error.

This could happen because the file that you have (successfully) included, has itself an include statement for another file, and that second include statement assumes that you have added the path of that library to the include path.

For example, the Zend framework file mentioned before could have the following include :

which is neither an inclusion by relative path, nor by absolute path. It is assuming that the Zend framework directory has been added to the include path.

In such a case, the only practical solution is to add the directory to your include path.

2. SELinux

If you are running Security-Enhanced Linux, then it might be the reason for the problem, by denying access to the file from the server.

To check whether SELinux is enabled on your system, run the sestatus command in a terminal. If the command does not exist, then SELinux is not on your system. If it does exist, then it should tell you whether it is enforced or not.

To check whether SELinux policies are the reason for the problem, you can try turning it off temporarily. However be CAREFUL, since this will disable protection entirely. Do not do this on your production server.

If you no longer have the problem with SELinux turned off, then this is the root cause.

To solve it, you will have to configure SELinux accordingly.

The following context types will be necessary :

• httpd_sys_content_t for files that you want your server to be able to read
• httpd_sys_rw_content_t for files on which you want read and write access
• httpd_log_t for log files
• httpd_cache_t for the cache directory

For example, to assign the httpd_sys_content_t context type to your website root directory, run :

If your file is in a home directory, you will also need to turn on the httpd_enable_homedirs boolean :

In any case, there could be a variety of reasons why SELinux would deny access to a file, depending on your policies. So you will need to enquire into that. Here is a tutorial specifically on configuring SELinux for a web server.

3. Symfony

If you are using Symfony, and experiencing this error when uploading to a server, then it can be that the app’s cache hasn’t been reset, either because app/cache has been uploaded, or that cache hasn’t been cleared.

You can test and fix this by running the following console command:

4. Non ACSII characters inside Zip file

Apparently, this error can happen also upon calling zip->close() when some files inside the zip have non-ASCII characters in their filename, such as «é».

A potential solution is to wrap the file name in utf8_decode() before creating the target file.

Credits to Fran Cano for identifying and suggesting a solution to this issue

To add to the (really good) existing answer

Shared Hosting Software

open_basedir is one that can stump you because it can be specified in a web server configuration. While this is easily remedied if you run your own dedicated server, there are some shared hosting software packages out there (like Plesk, cPanel, etc) that will configure a configuration directive on a per-domain basis. Because the software builds the configuration file (i.e. httpd.conf ) you cannot change that file directly because the hosting software will just overwrite it when it restarts.

With Plesk, they provide a place to override the provided httpd.conf called vhost.conf . Only the server admin can write this file. The configuration for Apache looks something like this

Have your server admin consult the manual for the hosting and web server software they use.

File Permissions

It’s important to note that executing a file through your web server is very different from a command line or cron job execution. The big difference is that your web server has its own user and permissions. For security reasons that user is pretty restricted. Apache, for instance, is often apache , www-data or httpd (depending on your server). A cron job or CLI execution has whatever permissions that the user running it has (i.e. running a PHP script as root will execute with permissions of root).

A lot of times people will solve a permissions problem by doing the following (Linux example)

This is not a smart idea, because the file or directory is now world writable. If you own the server and are the only user then this isn’t such a big deal, but if you’re on a shared hosting environment you’ve just given everyone on your server access.

What you need to do is determine the user(s) that need access and give only those them access. Once you know which users need access you’ll want to make sure that

That user owns the file and possibly the parent directory (especially the parent directory if you want to write files). In most shared hosting environments this won’t be an issue, because your user should own all the files underneath your root. A Linux example is shown below

The user, and only that user, has access. In Linux, a good practice would be chmod 600 (only owner can read and write) or chmod 644 (owner can write but everyone can read)

require(vendor/autoload.php): failed to open stream

I know that this issue has been posted many times, but for me it seems to be a different problem.

Indeed, this error

Warning: require(vendor/autoload.php): failed to open stream: No such file or directory in C:\xampp\htdocs\site_web\send_mail.php on line 3

Fatal error: require(): Failed opening required ‘vendor/autoload.php’ (include_path=’C:\xampp\php\PEAR’) in C:\xampp\htdocs\site_web\send_mail.php on line 3

appears at the begining of my code from this line:

So, I guess there must be a /vendor/autoload.php file somewhere in my computer (I have installed composer and ran composer require phpmailer/phpmailer ).

So, I looked for this file using: dir /s autoload.php in the Windows command line, and found one here: C:\Windows\SysWOW64\vendor\autoload.php ,

but for me, syswow64 folder has nothing to see with autoload.php, I don’t see what I am missing here.

17 Answers 17

What you’re missing is running composer install , which will import your packages and create the vendor folder, along with the autoload script.

Make sure your relative path is correct. For example the example scripts in PHPMailer are in examples/ , below the project root, so the correct relative path to load the composer autoloader from there would be ../vendor/autoload.php .

The autoload.php you found in C:\Windows\SysWOW64\vendor\autoload.php is probably a global composer installation – where you’ll usually put things like phpcs, phpunit, phpmd etc.

composer update is not the same thing, and probably not what you want to use. If your code is tested with your current package versions then running update may cause breakages which may require further work and testing, so don’t run update unless you have a specific reason to and understand exactly what it means. To clarify further – you should probably only ever run composer update locally, never on your server as it is reasonably likely to break apps in production.

I often see complaints that people can’t use composer because they can’t run it on their server (e.g. because it’s shared and they have no shell access). In that case, you can still use composer: run it locally (an environment that has no such restrictions), and upload the local vendor folder it generates along with all your other PHP scripts.

Running composer update also performs a composer install , and if you do not currently have a vendor folder (normal if you have a fresh checkout of a project), then it will create one, and also overwrite any composer.lock file you already have, updating package versions tagged in it, and this is what is potentially dangerous.

Similarly, if you do not currently have a composer.lock file (e.g. if it was not committed to the project), then composer install also effectively performs a composer update . It’s thus vital to understand the difference between the two as they are definitely not interchangeable.

It is also possible to update a single package by naming it, for example:

This will re-resolve the version specified in your composer.json and install it in your vendor folder, and update your composer.lock file to match. This is far less likely to cause problems than a general composer update if you just need a specific update to one package.

It is normal for libraries to not include a composer.lock file of their own; it’s up to apps to fix versions, not the libraries they use. As a result, library developers are expected to maintain compatibility with a wider range of host environments than app developers need to. For example, a library might be compatible with Laravel 5, 6, 7, and 8, but an app using it might require Laravel 8 for other reasons.

Composer 2.0 (out soon) should remove any remaining inconsistencies between install and update results.