Score:0

NGINX error: open_basedir

cn flag

I got this error from my NGINX server when I am running a script in Prestashop. I think this is something I can solve in the NGINX configuration or something, but I need some help to tell me what to do.

Warning: file_exists(): open_basedir restriction in effect. 
File(/www/wwwroot/panel_ssl_site/../app/etc/env.php) is not within 
the allowed path(s): (/www/wwwroot/panel_ssl_site/) in
/www/wwwroot/panel_ssl_site/bridge_i15GpcsW.php on line 832
  • How can I solve this?

Thanks,

Petter

Score:0
za flag

What is PHP open_basedir

It limits the files that can be accessed by PHP to the specified directory-tree, including the file itself. This directive is NOT affected by whether Safe Mode is turned On or Off.

When a script tries to access the file system, for example using include, or fopen(), the location of the file is checked. When the file is outside the specified directory-tree, PHP will refuse to access it. All symbolic links are resolved, so it's not possible to avoid this restriction with a symlink. If the file doesn't exist then the symlink couldn't be resolved and the filename is compared to (a resolved) open_basedir.

open_basedir can affect more than just filesystem functions; for example if MySQL is configured to use mysqlnd drivers, LOAD DATA INFILE will be affected by open_basedir. Much of the extended functionality of PHP uses open_basedir in this way.

The special value . indicates that the working directory of the script will be used as the base-directory. This is, however, a little dangerous as the working directory of the script can easily be changed with chdir().

In httpd.conf, open_basedir can be turned off (e.g. for some virtual hosts) the same way as any other configuration directive with "php_admin_value open_basedir none".

Under Windows, separate the directories with a semicolon. On all other systems, separate the directories with a colon. As an Apache module, open_basedir paths from parent directories are now automatically inherited.

The restriction specified with open_basedir is a directory name, not a prefix.

The default is to allow all files to be opened.

Reference PHP.NET, 1

Conclusion

You have used open_basedir, and you did not update the path. Additionally, i believe you that this Question should be asked on Superuser, as the evidence tells me that you are not using a Business Related environment.

php.ini (on Debian 10)

; open_basedir, if set, limits all file operations to the defined directory
; and below.  This directive makes most sense if used in a per-directory
; or per-virtualhost web server configuration file.
; Note: disables the realpath cache
; http://php.net/open-basedir
;open_basedir =

That example, from above, is the DEFAULT setting on Debian 10 which is usually also the default on php.net. Which means you have changed it either manually. Or what I believe, since the path names included "panel_ssl_site" is that I think you're using an Admin-Panel and this leads to, that this Question goes into OFF-TOPIC. However, every Admin panel should be able to change this setting too, See regarding Reference StackOverflow to the same issue

Michael Hampton avatar
cz flag
I see nothing here to indicate that this is not a business environment and should go to [su].
djdomi avatar
za flag
@MichaelHampton /www/wwwroot/panel_ssl_site is the default of [AAPanel](https://www.aapanel.com/index.html) that's why I guess it's not used for a professional hosting
Michael Hampton avatar
cz flag
Oh, a new one I've never heard of! We have a close reason specifically for mass web hosting control panels like cPanel, Plesk etc. so that seems more appropriate.
djdomi avatar
za flag
@MichaelHampton Nobody stops to learn new things, isnt it so? ;) but Peng58 seems to be gone away since theres no response
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.