Pretty URL procedure fails

No matter what I read and attempt, getting rid of the “index.php” in the address refuses to work. I either get (from Nextcloud page) no such file, or access denied. I have spent 4 hours on this when it should take 30 seconds.

CentOS 7 x64
PHP 5.6.30
Running iptables (but this has nothing to do with the problem…)

I am running a Sentora Control Panel on a completely different address.

My NextCloud install is at the root of the server’s subdomain and not in /var/www/html like this:

So my main domain structure looks like this: @ /var/www/html @ default for Sentora --> this is where NextCloud resides… /var/sentora/hostdata/zadmin/public_html/vapor_awesomehost_com

I don’t know what else to say, mod-rewrite and mod_env are installed and enabled.

EVERYTHING ELSE works perfectly except the pretty URL’s. Much of my time has been spent reading every thread here that not a single suggestion has made any headway.

I am totally out of ideas at this point. Any help would be appreciated.


Hi Doug,

Thanks for providing your environmental config, but you’ve not told us how you’re trying to enable this.

Can you provide your process step by step, including the config edits you’re inputting please?


I am just working off of the documentation.

Add this to /config/config.php

‘htaccess.RewriteBase’ => ‘/’

Before I can run the update to populate the .htacces I must change .htaccess ownership to apache, (or the command fails). [And yes, I have tried both combinations --> having the owner as root or apache both fail later on.]

Then I run:
sudo -u apache php occ maintenance:update:htaccess

Which properly populates the .htaccess file with what should be there - as confirmed from many threads here.)

Since whenever I try to to this I get either a permission complaint from NextCloud and it display nothing more than the NextCloud image and the error. The other error I believe is a complaint about not being authorized.

I have tried every combination possible and can say the usual problems for people - no mod-rewrite and mod_env or their command above is not changing the .htaccess file. Mine is changing fine, it is just that it “breaks it” - save me adding the index.php snippet back into the web address. Not much more I can think of. Feel free to inquire more about exact specifics so I may provide them to you.

I cannot help but think this is an Apache issue. That is the only thing left to work with that I am aware of.


When you say it updates the .htaccess, there’s been a few instances of it wiping out the contents and leaving only the bit it adds. Could you output your file in pastebin or similar?

If to Apache your install is in the root of a subdomain (as you indicate with no trailing filepath) then / is fine in the config file.

Could you output the error(s) you’re getting here, and a screenshot of the nc error page in the browser?

Sure, no problem give me a bit to get it all collected and uploaded.

With this in the config.php:

<?php $CONFIG = array ( 'passwordsalt' => 'SNo0bOFQsant0qYqwJMasDQI11ptVF', 'secret' => 'MaDRcDJ63j9RojDvnUDiaJI0L5K2RbxCORDxufqVrjwdvX+l', 'trusted_domains' => array ( 0 => 'localhost', 1 => '', 2 => '', 3 => '', ), 'datadirectory' => '/var/sentora/hostdata/zadmin/data', 'overwrite.cli.url' => '', 'memcache.local' => '\OC\Memcache\APCu', 'memcache.distributed' => '\OC\Memcache\Memcached', 'htaccess.RewriteBase' => '/', 'dbtype' => 'mysql', 'version' => '', 'dbname' => 'nextcloud', 'dbhost' => 'localhost', 'dbport' => '', 'dbtableprefix' => 'oc_', 'dbuser' => 'vapor', 'dbpassword' => '75F5QE6xCx642G70', 'logtimezone' => 'UTC', 'installed' => true, 'instanceid' => 'ocu9ed3962vr', );

I then change the .htaccess to apache:apache to run the update:

sudo -u apache php occ maintenance:update:htaccess

This yields an .htacess file of the following:


ErrorDocument 403 /core/templates/403.php
ErrorDocument 404 /core/templates/404.php

Options -MultiViews
RewriteRule ^core/js/oc.js$ index.php [PT,E=PATH_INFO:$1]
RewriteRule ^core/preview.png$ index.php [PT,E=PATH_INFO:$1]
RewriteCond %{REQUEST_FILENAME} !.(css|js|svg|gif|png|html|ttf|woff|ico|jpg|jpeg)$
RewriteCond %{REQUEST_FILENAME} !core/img/favicon.ico$
RewriteCond %{REQUEST_FILENAME} !/remote.php
RewriteCond %{REQUEST_FILENAME} !/public.php
RewriteCond %{REQUEST_FILENAME} !/cron.php
RewriteCond %{REQUEST_FILENAME} !/core/ajax/update.php
RewriteCond %{REQUEST_FILENAME} !/status.php
RewriteCond %{REQUEST_FILENAME} !/ocs/v1.php
RewriteCond %{REQUEST_FILENAME} !/ocs/v2.php
RewriteCond %{REQUEST_FILENAME} !/updater/
RewriteCond %{REQUEST_FILENAME} !/ocs-provider/
RewriteCond %{REQUEST_URI} !^/.well-known/acme-challenge/.*
RewriteRule . index.php [PT,E=PATH_INFO:$1]
RewriteBase /

SetEnv front_controller_active true

DirectorySlash off

Sorry, I cannot get into pastebin today and as you can see above the last entries are goofed up due to the forums. Here is a screencap.

Without changing the .htaccess back to its original apache:root I get this on the login page and any page I try to land on. I recieve this from NextCloud using as my URL.

I see now changing the permissions of .htaccess do not change the output - same as above.

Now if I put the index.php back in the address:

After trying to login, when the server removes the index.php after login and I end up with -> below at this address:

Normal server logs look fine. Do I need to add logging to the config.php to collect more/better data for you?

Incidentally I only started theming the app when I ran out of things to try to get the pretty URL’s to work. :slight_smile:

This is all I could find in the server logs - this one is under bind that I am not even using.

27-Feb-2017 13:20:23.394 general: notice: running
27-Feb-2017 15:21:39.884 general: notice: stopping command channel on
27-Feb-2017 15:21:39.912 general: notice: exiting
27-Feb-2017 15:23:09.442 general: error: managed-keys.bind.jnl: create: permission denied
27-Feb-2017 15:23:09.442 general: error: managed-keys-zone: sync_keyzone:dns_journal_open -> unexpected error
27-Feb-2017 15:23:09.442 general: error: managed-keys-zone: unable to synchronize managed keys: unexpected error
27-Feb-2017 15:23:09.443 general: notice: all zones loaded
27-Feb-2017 15:23:09.443 general: notice: running

Could this have to do with the fact I installed Let’sEncrypt SSL in Sentora? That is how it needs to be done to work properly - I have triple checked all of that and it is not throwing or creating the error we see on the login page… Thanks in advance and I hope any of this helps

Oh yeah, this is on a dedicated server so as far as the ‘/’ being correct, it should be as I created a new subdomain for the install. This is not like shared hosting where I might have public_html/… Rather as a subdomain it is the other way around:

Really? No one has any ideas? Permissions? What?

I made a new install in a vagrant container and was shocked to see all of THIS in the .htaccess before the “Don’t put stuff before this line” entry.

So all I did was run “sudo -u apache php occ maintenance:update:htaccess” as is stated above and copied all of the following above the “Don’t paste” line back in. Bingo! - Working PrettyURL’s in CentOS 7.