|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #52065 Warning about open_basedir restriction while accessing a file as directory
Submitted: 2010-06-12 14:58 UTC Modified: 2021-05-20 10:48 UTC
Avg. Score:4.2 ± 1.0
Reproduced:28 of 28 (100.0%)
Same Version:10 (35.7%)
Same OS:14 (50.0%)
From: manuel at mausz dot at Assigned:
Status: Verified Package: Safe Mode/open_basedir
PHP Version: 5.6.8 OS: Unix
Private report: No CVE-ID: None
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If this is not your bug, you can add a comment by following this link.
If this is your bug, but you forgot your password, you can retrieve your password here.
Bug Type:
From: manuel at mausz dot at
New email:
PHP Version: OS:


 [2010-06-12 14:58 UTC] manuel at mausz dot at
fopen_wrappers raise warning about open_basedir restriction in effect while accessing a file as a directory. This only occurs if the file exists.

Test script:
# sapi/cli/php -n -d open_basedir="$(pwd)" -r 'var_dump(is_readable("myfile/doesntexist"));'
# touch myfile
# sapi/cli/php -n -d open_basedir="$(pwd)" -r 'var_dump(is_readable("myfile/doesntexist"));'

Expected result:


Actual result:

Warning: is_readable(): open_basedir restriction in effect. File(myfile/doesntexist) is not within the allowed path(s): (/home/manuel/php5.3-201006120030) in Command line code on line 1


open-basedir-without-realpath (last revision 2015-04-29 20:11 UTC by

Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2010-08-11 12:20 UTC] manuel at mausz dot at
Can someone please finally take a look at this?
 [2012-04-28 07:18 UTC] nick at aussiecom dot com
Why hasn't this bug been resolved? It's nearly 2 years old...
 [2012-08-08 07:20 UTC] mein at e3b dot org
This bug is also present in php 5.4...
 [2015-04-29 20:11 UTC]
The following patch has been added/updated:

Patch Name: open-basedir-without-realpath
Revision:   1430338315
 [2015-04-29 20:14 UTC]
-Status: Open +Status: Verified -PHP Version: 5.3SVN-2010-06-12 (SVN) +PHP Version: 5.6.8
 [2015-04-29 20:14 UTC]
The patch open-basedir-without-realpath would fix this issue, but
it might have security implications or other undesired side
 [2015-06-03 08:26 UTC]
Any news on this one? Edge case but still :)
 [2015-06-04 00:00 UTC]
Considering the amount of closely related bug reports[1], I
wouldn't necessarily call that an edge case, Pierre. :)

I'll make a PR based on my patch with some tests, if no one beats
me to it.

[1] I've assembled a maybe non-exhaustive list in
 [2015-09-22 10:20 UTC] jan dot prachar at gmail dot com
Broken since 5.3.0, see
 [2018-02-28 22:26 UTC] a19836 at gmail dot com
Why isn't this bug fixed yet?
It was detected in 2013 or even before. And already passed 5 years... 

I trying the following example with PHP 7 and I'm getting exactly the same error.

ini_set("open_basedir", __DIR__);
file_put_contents(__DIR__ . "/foo.txt", "bar");
echo "EXISTS:".file_exists(__DIR__ . "/foo.txt/");

Error: PHP Warning:  file_exists(): open_basedir restriction in effect. File(/var/www/html/test/foo.txt/) is not within the allowed path(s): (/var/www/html/test) in /var/www/html/test/test.php on line 4

Can you please fix this and let me know please?
 [2018-10-02 05:08 UTC] sriccio at swisscenter dot com
We're seeing this in all the PHP versions we use (5.6, 7.0, 7.1, 7.2).

Literally spent hours trying to understand why we have these warning even that the paths are allowed in the open_basedir directive.

Finally it was because the parent dir of a path was in fact a file and not a dir.

The warning message is really misleading...

It would really be nice to fix this
 [2019-11-12 16:36 UTC] michael dot vorisek at email dot cz
Please fix asap, reported by many users. Thank you.
 [2020-11-12 15:04 UTC] php dot stephan at lippe-net dot de
Cool, a bug described in 2010 not even fixed in PHP 8.0RC3.
That's a statement!
 [2021-05-18 18:11 UTC] bugs-php dot a2 at x25 dot pl
cat a.php

php a.php

Warning: mkdir(): open_basedir restriction in effect. File(/home/naox/public_html/test) is not within the allowed path(s): (/home/naox/public_html/test) in /home/naox/public_html/ on line 3
 [2021-05-20 10:48 UTC]
> […] but it might have security implications […]

Indeed, it would.  Passing FALSE as 5th parameter to
expand_filepath_with_mode() actually means CWD_EXPAND, and that
would not resolve symlinks.

A possible solution for the issue would be to change
php_check_specific_open_basedir() so that it returns different
values for failure (currently it always returns -1, what should
actually be FAILURE), so that the caller could distinguish between
an actual open_basedir violation, and an invalid path (as is the
case here; files can't have subdirectories).  However. the functon
is exported, so changing the result values would be a BC break
(and a rather delicate at that).

An alternative would be to introduce another function, say
php_check_specific_open_basedir_ex() which gives more detailed
failure information, but frankly, why not simply change the error

Of course, one may argue that "file checking" functions, such as
is_readable() or is_file() should not warn at all, but simply
rreturn false, but again, that would require to modify the
existing funtion, or to introduce a new one, because currently
there is no such distintion when checking for potential
open_basedir violations.  A global flag to the rescue?
 [2021-05-20 10:54 UTC] rtrtrtrtrt at dfdfdfdf dot dfd
> why not simply change the error
> message?

because any message is a problem to begin with and more important: in most of the cases you get a message that a path which is obviously within open_basedir isn't  

you could even check that and be silent given that when i see that as human with the blink of an exe why shouldn't a computer?

> Of course, one may argue that "file checking" functions, such as
> is_readable() or is_file() should not warn at all, but simply
> rreturn false, but again, that would require to modify the
> existing funtion

and *that* is the point after decades where this annoying behavior exists - wenn i ask from inside the application if a file exists i don't care why i can't reach it (don't exist, no permissions, open_basedir)

especially on systems with error_reporting E_ALL on purpose and sending twice per hours log collections with a "fix it" policy it's really annoying and when you also have a don't use @ for error supression policy you are doomed
PHP Copyright © 2001-2022 The PHP Group
All rights reserved.
Last updated: Tue Aug 09 11:05:50 2022 UTC