After a Nextcloud migration, the admin overview showed this warning:
OCS provider resolving
Your web server is not properly set up to resolve “/ocm-provider/”. This is most likely related to a web server configuration that was not updated to deliver this folder directly. Please compare your configuration against the shipped rewrite rules in “.htaccess” for Apache or the provided one in the documentation for Nginx. On Nginx those are typically the lines starting with “location ~” that need an update.
My setup
Nextcloud running in Docker using the official nextcloud image, behind a reverse proxy.
The investigation
The usual suspects, wrong overwrite.cli.url, bad permissions, missing mod_rewrite, all checked out fine. The real culprit turned out to be a missing .htaccess file:
docker exec nextcloud cat /var/www/html/.htaccess
# cat: /var/www/html/.htaccess: No such file or directory
The .htaccess file had gone missing, likely lost during a volume operation or update. No problem, since Nextcloud has a built-in command to regenerate it:
bash
docker exec -u www-data nextcloud php occ maintenance:update:htaccess
But this returned:
Error updating .htaccess file, not enough permissions, not enough free space
or "overwrite.cli.url" set to an invalid URL?
Disk space was fine (798G free). Permissions were fine (www-data owned /var/www/html). The overwrite.cli.url was correctly set to https://cloud.mydomain.com/. Very confusing.
The root cause
Digging into the Nextcloud source code at lib/private/Setup.php revealed the actual check:
if (!is_writable($setupHelper->pathToHtaccess())) {
return false;
}
This is a PHP quirk: is_writable() returns false for files that don’t exist yet, even if the directory is fully writable. Since .htaccess was missing, the command bailed out before it could create it.
The fix
Simple. Create an empty .htaccess file first and then give the command a writable target:
docker exec -u www-data nextcloud touch /var/www/html/.htaccess
docker exec -u www-data nextcloud php occ maintenance:update:htaccess
After that, .htaccess was regenerated correctly and the warning disappeared from the admin panel.
This was one of those bugs that looks like a permissions problem, smells like a config problem, but is actually a PHP quirk. Hope this saves someone an hour of head-scratching.



Leave a Reply