Fix Nextcloud OCS Provider Error on LiteSpeed Enterprise

If a Nextcloud upgrade refuses to proceed and shows:

Your web server is not properly set up to resolve “/ocs-provider/”

This is not an update issue. It’s a routing issue – LiteSpeed is sending requests for /ocs-provider/ into Nextcloud’s front controller instead of serving the real folder directly.

The typical symptom:

  • https://your-domain/ocs-provider/index.php returns 200
  • https://your-domain/ocs-provider/ returns 404

That mismatch blocks the upgrade.

Step 1: Confirm the Symptom

Run these from your local machine or the server:

  curl -I https://your-domain/status.php
curl -I https://your-domain/ocs-provider/index.php
curl -I https://your-domain/ocs-provider/
curl -I https://your-domain/ocm-provider/

What to look for:

EndpointExpectedWhat it means
status.php200Domain and document root are correct
ocs-provider/index.php200Folder exists, PHP is working
ocs-provider/404 ← the problemLiteSpeed is rewriting instead of serving the folder
ocm-provider/Usually 200Not the main test – can be fine while /ocs-provider/ is broken

If ocs-provider/ returns 404, continue below.

Step 2: Set Correct Nextcloud Config Values

If Nextcloud is installed in the webroot (e.g. public_html), confirm these in config/config.php:

  'htaccess.RewriteBase' => '/',
'overwrite.cli.url' => 'https://your-domain/',

The trailing slash on overwrite.cli.url is recommended for consistency with CLI-generated URLs.

Step 3: Regenerate Nextcloud Rewrite Rules

From the Nextcloud root folder:

  cd /path/to/public_html
sudo -u YOURWEBUSER php occ maintenance:update:htaccess

This regenerates the .htaccess rules Nextcloud expects. If the problem is a missing or corrupted rule, this alone may fix it.

Step 4: Patch the LiteSpeed Rewrite Edge Case

On LiteSpeed Enterprise, the .htaccess exclusion for /ocs-provider/ sometimes only matches one directory form. The fix is to allow an optional trailing slash.

4.1 Back up .htaccess first 

  cd /path/to/public_html
cp -a .htaccess .htaccess.bak.$(date +%F-%H%M%S)

4.2 Apply the patch

Option A: Automatic (recommended)

  cd /path/to/public_html

# Patch common Nextcloud variants (safe if one does not match)
sed -i 's@RewriteCond %{REQUEST_FILENAME} !/(ocs-provider|updater)/@RewriteCond %{REQUEST_FILENAME} !/(ocs-provider|updater)/?@' .htaccess
sed -i 's@RewriteCond %{REQUEST_FILENAME} !/(ocm-provider|ocs-provider|updater)/@RewriteCond %{REQUEST_FILENAME} !/(ocm-provider|ocs-provider|updater)/?@' .htaccess

Option B: Manual

Find this line in .htaccess:

  RewriteCond %{REQUEST_FILENAME} !/(ocm-provider|ocs-provider|updater)/

Change it to:

  RewriteCond %{REQUEST_FILENAME} !/(ocm-provider|ocs-provider|updater)/?

The only difference is the ? after the trailing slash, making it optional so LiteSpeed matches both /ocs-provider and /ocs-provider/.

Step 5: Restart LiteSpeed

If you manage LiteSpeed via WebAdmin, do a Graceful Restart.

Via systemd:

  sudo systemctl restart lsws

If your service name differs:

  systemctl list-units --type=service | grep -i litespeed

Step 6: Verify

Re-run:

  curl -I https://your-domain/ocs-provider/ | head -n 1

You should see HTTP 200 (or anything that is not 404). If it still returns 404, check whether it’s a Nextcloud-generated 404 (look for oc_sessionPassphrase in the response cookies). If it is, the rewrite is still catching the request and the .htaccess patch was not applied or got overwritten.

Troubleshooting

“I patched it but it came back after an upgrade”

Some Nextcloud upgrades regenerate .htaccess. Keep your backup and re-apply the same sed patch after the update.

“ocs-provider/index.php is 200 but /ocs-provider/ is still 404”

This is almost always the rewrite edge case. Re-check Step 4 and confirm the /? exists in the exclusion condition. Also verify LiteSpeed was actually restarted (Step 5).

Last updated 22 Apr 2026, 14:21 +0200. history

Was this page helpful?