Backups Fail Silently on CloudPanel / nginx / OpenLiteSpeedPRO

Symptoms

You probably have this issue if one or more of the following are true:

How to Verify It’s This Specific Issue

Two quick checks confirm the diagnosis before you change any server config.

ls -la wp-content/uploads/sitevault/ 2>/dev/null || echo "SITEVAULT DIRECTORY MISSING"

PHP_USER=$(stat -c '%U' wp-config.php)
sudo -u "$PHP_USER" touch wp-content/uploads/.write-test \
    && rm wp-content/uploads/.write-test \
    && echo "UPLOADS WRITABLE BY $PHP_USER" \
    || echo "UPLOADS NOT WRITABLE BY $PHP_USER"

curl -I https://yoursite.com/wp-content/uploads/sitevault/

The Fix — Two Layers

There are two separate problems to solve, and it’s easy to conflate them. Do them in this order:

1. Fix the directory-creation failure — this is a filesystem-layer issue (Linux file permissions, PHP’s open_basedir, or in rare cases SELinux/AppArmor). The web server’s config doesn’t directly control whether PHP’s mkdir() syscall succeeds.
2. Protect backups from being downloaded by URL guessing — this is a web-server-layer issue. SiteVault auto-writes .htaccess + web.config + a stub index.php into the backup directory, which Apache and IIS honor. nginx and OpenLiteSpeed don’t read .htaccess, so on those servers you need an explicit vhost rule.

Layer 1: Fix Directory Creation (the actual cause)

cd /path/to/your/wordpress
stat -c '%U:%G' wp-config.php

ls -la wp-content/uploads/

sudo chown -R $(stat -c '%U:%G' wp-config.php) wp-content/uploads/
sudo chmod 755 wp-content/uploads/

PHP_USER=$(stat -c '%U' wp-config.php)
sudo -u "$PHP_USER" mkdir -p \
    wp-content/uploads/sitevault/backups \
    wp-content/uploads/sitevault/temp \
    wp-content/uploads/sitevault/logs

Layer 2: Protect Backups from Web Access (security)

After Layer 1 makes backups work, the backup files themselves need to be unreachable by URL guessing — they contain your full database dump and wp-config.php. On Apache and IIS the protection is automatic (SiteVault writes .htaccess and web.config). On nginx and OpenLiteSpeed you have to add a vhost rule because those servers don’t read .htaccess.

CloudPanel + plain nginx

Open your site’s vhost config (CloudPanel: /etc/nginx/sites-enabled/<site>.conf; Debian/Ubuntu: /etc/nginx/sites-available/yourdomain.conf; CentOS/RHEL: /etc/nginx/conf.d/yourdomain.conf). Inside the server { ... } block, add:

location ~* /wp-content/uploads/sitevault/ {
    deny all;
    return 403;
}

Then reload nginx:

sudo nginx -t && sudo systemctl reload nginx

OpenLiteSpeed

LiteSpeed Web Server (Enterprise) + Apache

Both honor the .htaccess SiteVault writes into the backup directory automatically — no extra config needed.

Why Does This Happen?

Two separate things are going on, and the failure conflates them in a way that’s easy to mis-diagnose.

The creation failure (Layer 1)

SiteVault Pro stores backups under wp-content/uploads/sitevault/. The first time it runs a backup, it needs to create that directory tree. wp_mkdir_p() — the WordPress wrapper around PHP’s mkdir() syscall — can fail silently for a handful of filesystem-layer reasons:

• The PHP user doesn’t own wp-content/uploads/ — common on managed hosts where a deploy script created the WordPress install as one user, but PHP-FPM runs as a different user. PHP can read the directory but can’t create subdirectories under it.
• open_basedir restriction — some hosts restrict PHP to a whitelist of paths via php.ini. If the install path isn’t in the whitelist, every filesystem call fails.
• SELinux / AppArmor / custom security wrappers — rare but real on hardened stacks. Some managed-host setups mirror their nginx deny rules at the filesystem layer via these mechanisms, which is what the plugin error message is hinting at when it mentions “server-level rules”.
• Disk space / per-user quotas — produces the same “cannot create” symptom.

Before 1.7.31, wp_mkdir_p()’s return value was discarded by the plugin, so the failure was invisible and the backup just crashed mid-run with a generic error. 1.7.31 checks the return value and surfaces the exact path that failed, which is what lets you actually fix it.

The web-access protection (Layer 2)

The backups themselves contain your full database dump plus wp-config.php — anyone with a URL guess could download them. SiteVault writes a deny all rule into .htaccess AND web.config AND a stub index.php guard the moment the directory is created.

Apache honors .htaccess. IIS honors web.config. nginx ignores both, and so do OpenLiteSpeed and some LiteSpeed configurations — their web-server config has to be edited at the vhost level. That’s why the Layer 2 step is required on those servers but not on Apache.

SiteVault Pro 1.7.26+ self-validates the protection: it probes the backup directory with a short-lived canary file via loopback HTTP, and shows a red admin notice if the canary is fetchable. So you’ll know if Layer 2 needs work even if you initially skipped it.

Still Failing After the Server Config Change? Email Priority Support

If you’ve added the location block, reloaded the web server, and SiteVault still fails to create the backup directory, email support@royalplugins.com with the diagnostic info below. Priority email support is included with your SiteVault Pro license — typical response time is within 24 hours.