Fix 'open_basedir Restriction in Effect' in cPanel & WordPress

You update a plugin, move a site, or add a symlink, and suddenly PHP throws a wall of warnings: open_basedir restriction in effect. File(/home/otheraccount/public_html/wp-content/...) is not within the allowed path(s). The site half-loads, images break, or a backup plugin just stops. Here's what's actually happening and how to fix it without turning the restriction off entirely.

What open_basedir actually does

open_basedir is a PHP setting that fences off which directories a PHP script is allowed to touch. On shared hosting it's normally set to your account's home directory only, something like:

open_basedir = /home/username/:/tmp/:/usr/lib/php/

That's a deliberate security boundary. If PHP could read and write anywhere on the server, one compromised or buggy script on any account could read another customer's wp-config.php. The restriction exists so a hack on one site can't walk sideways into the next one. It's not a bug — but it does break specific, legitimate use cases.

Symptom: the exact error you'll see

It usually shows up as a PHP warning, not a hard crash, so the page half-renders:

Warning: file_get_contents(): open_basedir restriction in effect.
File(/home/siteb/public_html/uploads/logo.png) is not within the allowed path(s):
(/home/sitea/:/tmp/:/usr/lib/php/) in /home/sitea/public_html/wp-content/plugins/example/functions.php on line 42

The path in the error tells you exactly which file PHP tried to reach and which directory it's actually confined to. That's your first diagnostic clue — don't skip reading it.

The usual culprits

• Symlinked or mapped directories. A staging site, a shared uploads folder, or a manually created symlink that points outside your account's home directory. PHP follows the link but open_basedir blocks the read.
• Backup and migration plugins. UpdraftPlus, Duplicator, and similar tools sometimes try to scan sibling directories or a custom backup destination outside public_html.
• WordPress Multisite with domain mapping where subsites' files were placed outside the primary account's docroot instead of under it.
• Addon domains pointed at a folder outside the main account — rare, but it happens after a manual DNS/document-root change in WHM.
• A recent migration where wp-config.php or an include still references the old account's absolute path (e.g. /home/oldaccount/...) instead of the new one.

Fix it on shared cPanel hosting

You can't edit php.ini directly on shared hosting, but you have two tools that matter here:

1. Check the current setting. In cPanel, go to Software > MultiPHP INI Editor, select your domain, and look for the open_basedir line under Editor Mode. This shows you exactly what path PHP is locked to right now.
2. Fix the actual reference, don't widen the fence. In almost every shared-hosting case, the real fix is to stop the script from reaching outside your account rather than expanding open_basedir. Move the file it's trying to reach into your own public_html or a subfolder of your home directory, and update the plugin's saved path setting to match.
3. If you genuinely need a wider path (for example, a legitimate cross-account setup your host approved), open a support ticket. Most hosts, including Getwebup, can add a specific extra path to your account's open_basedir value — they won't disable it outright, since that reopens the exact isolation risk it exists to prevent.

Fix it on a VPS you manage yourself

On a VPS you have full control, so you can edit the setting directly — but do it narrowly, not by removing it.

For PHP-FPM (most current LEMP/LiteSpeed setups), edit the pool config for that site, typically at:

/etc/php/8.3/fpm/pool.d/yoursite.conf

Find or add the line:

php_admin_value[open_basedir] = /var/www/yoursite/:/tmp/:/usr/lib/php/

To add an extra allowed path (say, a shared uploads directory used by two related sites), append it with a colon:

php_admin_value[open_basedir] = /var/www/yoursite/:/var/www/shared-uploads/:/tmp/:/usr/lib/php/

Then reload PHP-FPM:

sudo systemctl reload php8.3-fpm

For Apache with mod_php, the same directive can live in the vhost file instead:

php_admin_value open_basedir "/var/www/yoursite/:/tmp/:/usr/lib/php/"

followed by sudo systemctl reload apache2. Always test with a quick <?php phpinfo(); ?> page (delete it right after) to confirm the new value actually took effect — a typo in the pool file silently falls back to the previous restriction rather than erroring out.

Prevention

If you're still stuck after checking the path in the error message against MultiPHP INI Editor (or your pool config on a VPS), it's worth pasting the exact warning into a support ticket — the path in the message almost always points straight at the misconfigured plugin setting or leftover migration reference.