In some prior owncloud documentation (or maybe a github issue, I forget) I read enabling mod_rewrite and mod_env will trigger OC to magically eradicate index.php from URLS.
Is this the case with NC? Because I’ve confirmed both are enabled and it’s done a whole lot of nothing.
Is this the case with NC? Because I’ve confirmed both are enabled and it’s done a whole lot of nothing.
This is outdated documentation in Nextcloud and ownCloud, to enable index.php URLs the following condition needs to be met:
htaccess.RewriteBase in your config.php is linking to the web root folder (e.g. /nextcloud if you acesss foo.com/nextcloud, or / if it lives on the web root)
mod_env and mod_rewrite need to be enabled
Afterwards you should run occ maintenance:update:htaccess on your console
None. It’s pretty similar to the original approach but there were some rare server configurations that made this incompatible. So we dropped the autoconfiguration and went with this small manual interaction.
I’m also having issues. It seems that my server is unable to serve even static content like oc.js (https://cloud.koehn.com/index.php/core/js/oc.js?v=e3dfe14d771910e17007220657dff1a1 returns the index.html page instead of JavaScript; try it and see.
My whole site is down until I get this resolved. I added the 'htaccess.RewriteBase' => '/', to my conifg.php file, and ran occ maintenance:update:htaccess but I’m still stuck. I’d debug the issue but I’m not sure how to debug it.
Apache 2.4.23 (mod_rewrite and mod_env are enabled)
PHP 7.0.8-4+deb.sury.org~trusty+1
php7.0-fpm
nextcloud 9.0.52, upgraded from owncloud 9 (the upgrade worked without a hitch)
There’s nothing interesting in the owncloud.log, the access.log or the error.log from Apache, and the fpm.log is empty.
I’m beginning to suspect the issue is my .htaccess file. It isn’t being regenerated when I run occ maintenance:update:htaccess, even though that command responds with .htaccess has been updated.
There’s an issue with occ - it states that ‘it has been updated’ even when it hasn’t. What are your permissions for the .htaccess? Be sure it’s group writable (for the moment) if it’s owned by root:www-data like the guide tells you to make it. However, making it 644 root:www-data is best for security.
… yeah. I’m still on PHP 5.6.22, since I’m using Debian 8.5 Jessie. You know what, I’m just going to post my entire stack to see if it helps.
Debian 8.5 Jessie
Apache 2.4.10 (Debian)
MariaDB 10.0.25
PHP 5.6.22
I just switched to 5.6.23-2+deb.sury.org~trusty+1 and it makes no difference at all. You can hit my server at https://cloud.koehn.com/ and see what’s happening. Right now if I request /core/js/oc.js it doesn’t even log anywhere in /var/log/apache2/owncloud*.log. It’s like the request never happened.
Did you fix it recently? I just hit https://cloud.koehn.com/core/js/oc.js and it returns javascript just fine for me. Maybe try a different browser/turn off NoScript/what have you?
I have no idea how, but somehow (in the past few minutes) that URI works for me too (whether with a browser or curl). Now I can log in!
I turned on debug and forensic logging in Apache, which might have some insights. Still can’t get php7.0-fpm to log anything, which I suspect is where things are going wrong.
But, as soon as I do and I request anything (e.g., https://cloud.koehn.com/index.php/apps/files/), I get back a 302 (redirect) to https://cloud.koehn.com/index.php/apps/files/), no matter what URI was requested in the first place.
And a request for https://cloud.koehn.com/index.php/core/js/oc.js still results in the index page being returned.