You open your error log — or worse, your homepage — and see a wall of red text like Warning: require_once(): open_basedir restriction in effect. File(/home/otheruser/public_html/wp-load.php) is not within the allowed path(s). Nothing was "hacked," nothing is actually broken in your code. This is PHP's sandbox doing exactly what it's designed to do, just at the wrong moment. Here's what's going on and how to fix it without turning off a security feature you actually want.

Symptom

You'll usually see one of these:

  • A PHP warning or fatal error mentioning open_basedir restriction in effect followed by a file path
  • A plugin or theme that suddenly stops working after a migration, a new add-on domain, or a symlink was added
  • File uploads, cron jobs, or an SMTP plugin failing when they try to read or write a path outside your account
  • A staging or cloned copy of a site throwing errors that the original site never did

Check error_log in your site's root, or in cPanel go to Metrics > Errors, and you'll almost always find the exact restricted path in the message — that's your first clue.

Cause

open_basedir is a PHP directive that limits which directories a script is allowed to touch. On shared and reseller hosting it's one of the more important isolation controls: it stops a compromised or buggy script in one cPanel account from reading files in another account on the same server. Think of it as a fence around your home directory.

The problem shows up when your code — a plugin, a custom script, a WP-CLI command, a cron job — tries to reach a path outside that fence. Common triggers:

  • Symlinks pointing outside your home directory. A very common one: an addon domain or a migrated site leaves a symlink to /home/otheruser/... or to a shared library folder that isn't inside open_basedir.
  • Hardcoded absolute paths left over from a migration — a theme or plugin still references /home/olduser/public_html/... instead of the new account's path.
  • Temp directories. PHP's default sys_temp_dir (often /tmp) is sometimes not included in open_basedir, which breaks plugins that write temp files — PDF generators, image processors, some SMTP/email plugins, backup plugins.
  • Multiple domains under one cPanel account where a script on the addon domain tries to reach a file that lives under the main domain's document root but outside the shared account path (rare, but it happens with oddly structured multisite setups).
  • A newly restored backup that references the old server's absolute file paths in wp-config.php, an .htaccess include, or a plugin's settings table.

Fix

Don't jump straight to disabling open_basedir — that's a security downgrade, not a fix. Work through this in order:

1. Read the exact path in the error

The warning tells you precisely which file PHP tried to reach and refused. Nine times out of ten that path is either a symlink target outside your account, or a leftover absolute path from a different server/account.

2. Check for bad symlinks

Via SSH or Terminal in cPanel:

find /home/youruser/public_html -type l -ls

Look at where each symlink actually points (the -> target). If any of them point outside /home/youruser/, that's your culprit. Remove it and, if it was meant to share files between two of your own addon domains, replace it with an actual copy of the files, or ask support to widen the account's allowed paths instead of symlinking across accounts.

3. Search for hardcoded absolute paths

After a migration, grep wp-config.php and any custom mu-plugins or theme functions.php for the old server's path:

grep -r "/home/olduser" /home/youruser/public_html --include="*.php"

Update any matches to the new account's actual path. Run pwd from inside public_html if you're not sure what that path is.

4. Widen open_basedir correctly (only if a legitimate path is missing)

If the blocked path genuinely needs to be reachable — for example, PHP's temp directory isn't included — don't remove the restriction, add the one path you need. In cPanel, go to Software > MultiPHP INI Editor, select the domain, switch to Editor Mode, and find (or add) the open_basedir line. It'll look something like:

open_basedir = /home/youruser/public_html:/home/youruser/tmp:/usr/lib/php:/tmp

Append the extra path with a colon separator on Linux, keeping every existing entry intact. Never set it to a bare / or remove it entirely — that turns off the isolation for the whole account. If MultiPHP INI Editor won't let you edit this directive because it's locked server-wide, that's intentional on shared hosting and you'll need to open a support ticket explaining the exact path you need added.

5. Point plugins at an in-account temp folder

For plugins that insist on writing to /tmp (some PDF and backup tools), check the plugin's settings for a configurable temp/cache directory and point it at something inside public_html, like wp-content/uploads/tmp/, instead of relying on the system temp path.

6. Restart PHP-FPM if the site uses it

After editing php.ini-level settings, PHP-FPM pools sometimes need a restart to pick up the change (MultiPHP INI Editor usually handles this for you, but if you edited a custom php.ini directly via SSH, restart the pool or wait for the next automatic reload).

Prevention

  • After any migration or account move, grep for the old absolute path before you consider the job done — it's a five-second check that saves a confusing debugging session later.
  • Avoid symlinking between two different cPanel accounts, even ones you own. Copy files or use SkyServer's account-to-account transfer tools instead.
  • When installing a plugin that processes files (PDF generation, video encoding, large exports), check its documentation for temp-directory requirements before you need them in production.
  • Keep a copy of your account's actual open_basedir value somewhere handy (from MultiPHP INI Editor) so you can compare it quickly if something new breaks after a plugin update.

Frequently Asked Questions

Is it safe to just disable open_basedir?

No, not on shared or reseller hosting. It's one of the main barriers stopping a compromised script in your account from reading or writing files belonging to other accounts on the same server. Add the specific path you need instead of removing the restriction.

Why did this suddenly start after a plugin update?

Plugin updates sometimes change where the plugin writes temporary or cache files — a new version might start using the system temp directory or a hardcoded path it didn't use before. Check the plugin's changelog and settings for a configurable storage path.

I'm on a VPS with root access — do I still need open_basedir?

It's less critical if you're the only account on the server, but it's still good practice if you run multiple sites or clients under separate Linux users on the same VPS. If it's just your own single WordPress install, you can safely loosen or remove it in your site's PHP-FPM pool config.

How do I know what my current open_basedir value is?

Create a temporary file with <?php phpinfo(); ?>, load it in a browser, and search the page for open_basedir — it'll show the exact active value for that PHP handler. Delete the file when you're done; never leave a phpinfo() file publicly accessible.

Can this affect WP-CLI or cron jobs too, not just the website?

Yes. cron jobs and CLI scripts run under the same PHP configuration as the website unless you're explicitly using a different PHP binary or ini file. If a cron job fails with the same open_basedir warning, check which php.ini it's loading with php --ini over SSH.