-
Notifications
You must be signed in to change notification settings - Fork 2.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Internal server error #24525
Comments
Please post the whole config file and also explain how you map from |
Here is the full config.php $CONFIG = array ( Regarding the mapping from /homepages/19/d438963193/htdocs/oc/owncloud/ to https://www.mywebsite.com/oc/owncloud' It is a shared hosting, and internaly the adress /homepages/19/d438963193/htdocs\ points to the base of my domain name https://www.mywebsite.com/ |
How did you install ownCloud then? From what URL? Also I'm super confused, sometimes you refer to |
The current logic for mod_rewrite relies on the fact that people have properly configured ownCloud, basically it reads from the `overwrite.cli.ur l` entry and then derives the `RewriteBase` from it. This usually works. However, since the ownCloud packages seem to install themselves at `/owncloud` (because subfolders are cool or so…) _a lot_ of people have just created a new Virtual Host for it or have simply symlinked the path etc. This means that `overwrite.cli.url` is wrong, which fails hard if it is used as RewriteBase since Apache does not know where it should serve files from. In the end the ownCloud instance will not be accessible anymore and users will be frustrated. Also some shared hosters like 1&1 (because using shared hosters is so awesome… ;-)) have somewhat dubious Apache configurations or use versions of mod_rewrite from the mediveal age. (because updating is money or so…) Anyhow. This makes this explicitly an opt-in configuration flag. If `htaccess.RewriteBase` is set then it will configure index.php-less URLs, if admins set that after installation and don't want to wait until the next ownCloud version they can run `occ maintenance:update:htaccess`. For ownCloud 9.0 we also have to add a repair step to make sure that instances that already have a RewriteBase configured continue to use it by copying it into the config file. That way all existing URLs stay valid. That one is not in this PR since this is unneccessary in master. Effectively this reduces another risk of breakage when updating from ownCloud 8 to ownCloud 9. Fixes #24525, #24426 and probably some more.
The current logic for mod_rewrite relies on the fact that people have properly configured ownCloud, basically it reads from the `overwrite.cli.ur l` entry and then derives the `RewriteBase` from it. This usually works. However, since the ownCloud packages seem to install themselves at `/owncloud` (because subfolders are cool or so…) _a lot_ of people have just created a new Virtual Host for it or have simply symlinked the path etc. This means that `overwrite.cli.url` is wrong, which fails hard if it is used as RewriteBase since Apache does not know where it should serve files from. In the end the ownCloud instance will not be accessible anymore and users will be frustrated. Also some shared hosters like 1&1 (because using shared hosters is so awesome… ;-)) have somewhat dubious Apache configurations or use versions of mod_rewrite from the mediveal age. (because updating is money or so…) Anyhow. This makes this explicitly an opt-in configuration flag. If `htaccess.RewriteBase` is set then it will configure index.php-less URLs, if admins set that after installation and don't want to wait until the next ownCloud version they can run `occ maintenance:update:htaccess`. For ownCloud 9.0 we also have to add a repair step to make sure that instances that already have a RewriteBase configured continue to use it by copying it into the config file. That way all existing URLs stay valid. That one is not in this PR since this is unneccessary in master. Effectively this reduces another risk of breakage when updating from ownCloud 8 to ownCloud 9. Fixes #24525, #24426 and probably some more.
I use two methods to install owncloud. I can upload the whole app with FTP and start setup or simply upload the script setup-owncloud.php and run it. It works until the login page. I am sorry for the confusion between oc/owncloud and test/owncloud. In fact since my owncloud installation broke a few days ago, I tried different new installations for testing purposes. So I tried once with test/owncloud and again with oc/owncloud. The fact is that owncloud was working very well since version 6 and it seems broken now though I have not changed anything. I thought my config files were wrong, but I see that a fresh install leads to the same issue. I thought that |
Please try to remove everything after the "DO NOT CHANGE ANYTHING ABOVE THE LINE" entry in .htaccess. If that works then there is a good chance that the patch in 9.0.3 will fix this. (you might need to have to repeat this step in 9.0.3 again but afterwards not anymore if you also remove the htaccess.RewriteBase entry from your config.php then) |
Had the same Error. .htaccess
I had to comment out the RewriteBase to get Owncloud work |
Same issue here. Oh man, really every time I update owncloud it breaks into a thousand pieces. Do you guys run tests before releases? Thanks to @Mannshoch - removing "RewriteBase /owncloud" in .htaccess helped (wtf?). |
@LukasReschke I am also facing internal server error. Though I tried testing the #24539 and it worked successfully after that. It was successful in fixing the internal server error. |
@hirschnase Im familiar with .htaccess deactivating. I run .htaccess on one Webspace on which i have to remove the half of all .htacces entries to get a working Owncloud. |
Well, I tried with shortened .htacess and it does not work .... I installed back an older version 8 and it is working fine. |
The current logic for mod_rewrite relies on the fact that people have properly configured ownCloud, basically it reads from the `overwrite.cli.ur l` entry and then derives the `RewriteBase` from it. This usually works. However, since the ownCloud packages seem to install themselves at `/owncloud` (because subfolders are cool or so…) _a lot_ of people have just created a new Virtual Host for it or have simply symlinked the path etc. This means that `overwrite.cli.url` is wrong, which fails hard if it is used as RewriteBase since Apache does not know where it should serve files from. In the end the ownCloud instance will not be accessible anymore and users will be frustrated. Also some shared hosters like 1&1 (because using shared hosters is so awesome… ;-)) have somewhat dubious Apache configurations or use versions of mod_rewrite from the mediveal age. (because updating is money or so…) Anyhow. This makes this explicitly an opt-in configuration flag. If `htaccess.RewriteBase` is set then it will configure index.php-less URLs, if admins set that after installation and don't want to wait until the next ownCloud version they can run `occ maintenance:update:htaccess`. For ownCloud 9.0 we also have to add a repair step to make sure that instances that already have a RewriteBase configured continue to use it by copying it into the config file. That way all existing URLs stay valid. That one is not in this PR since this is unneccessary in master. Effectively this reduces another risk of breakage when updating from ownCloud 8 to ownCloud 9. Fixes #24525, #24426 and probably some more.
How can this be? I did another OwnCloud update via the Ubuntu "apt upgrade" and again it breaks my installation -> 500 SERVER ERROR. WTF? Again I had to manually edit .htaccess and remove the line "RewriteBase /owncloud" to make it work again. I really don't get it. This project is a mess. |
@hirschnase Just fix your config: #24426 (comment) |
Hey, this issue has been closed because the label (This is an automated comment from GitMate.io. |
This is closed? Update: the upgrade to nextcloud worked like a charm - the error went away immediately after following the instructions at https://nextcloud.com/migration/ We then went all the way to Version 12 see http://wiki.bitplan.com/index.php/Nextcloud |
This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
Steps to reproduce
I am running an owncloud instance on a 1&1 web hosting and it has been working well until yesterday.
I am using the last version of owncloud 9.0.2
Since yesterday, I cannot use owncloud anymore.
I always end with a "Internal Server Error".
I even tried a fresh install of owncloud with auto installer and sqllite. The same thing happens. Right after setup finishes, it ends with the same internal error.
I checked the paths in config.php and .htaccess
#24426 (comment)
Owncloud is installed at this adress:
https://www.mywebsite.com/test/owncloud
Here are the two lines created by the owncloud installer in config.php and .htaccess
RewriteBase /test/owncloud
'overwrite.cli.url' => 'http://localhost/test/owncloud',
I tried replacing overwrite.cli.url with this one
'overwrite.cli.url' => 'https://www.mywebsite.com/test/owncloud',
PHP version:
I tried with version 5.6 and 7
ownCloud version: (see ownCloud admin page)
9.02
Updated from an older ownCloud or fresh install:
Older owncloud and fresh install
Where did you install ownCloud from:
Manual install and automatic install
Are you using external storage, if yes which one: local/smb/sftp/...
NO
Are you using encryption:
YES
ownCloud log (data/owncloud.log)
{"reqId":"txKbQx6pS1mTYZVE/bEr","remoteAddr":"","app":"no app in context","message":"Exception: {"Exception":"DomainException","Message":"Contacts tables are missing. Nothing to do.","Code":0,"Trace":"#0 \/homepages\/19\/d438963193\/htdocs\/oc\/owncloud\/apps\/dav\/lib\/migration\/migrateaddressbooks.php(83): OCA\Dav\Migration\AddressBookAdapter->setup()\n#1 \/homepages\/19\/d438963193\/htdocs\/oc\/owncloud\/apps\/dav\/appinfo\/application.php(186): OCA\Dav\Migration\MigrateAddressbooks->setup()\n#2 \/homepages\/19\/d438963193\/htdocs\/oc\/owncloud\/apps\/dav\/appinfo\/install.php(26): OCA\Dav\AppInfo\Application->migrateAddressbooks()\n#3 \/homepages\/19\/d438963193\/htdocs\/oc\/owncloud\/lib\/private\/installer.php(639): include('\/homepages\/19\/d...')\n#4 \/homepages\/19\/d438963193\/htdocs\/oc\/owncloud\/lib\/private\/installer.php(590): OC_Installer::includeAppScript('\/homepages\/19\/d...')\n#5 \/homepages\/19\/d438963193\/htdocs\/oc\/owncloud\/lib\/private\/installer.php(561): OC_Installer::installShippedApp('dav')\n#6 \/homepages\/19\/d438963193\/htdocs\/oc\/owncloud\/lib\/private\/setup.php(370): OC_Installer::installShippedApps()\n#7 \/homepages\/19\/d438963193\/htdocs\/oc\/owncloud\/core\/controller\/setupcontroller.php(64): OC\Setup->install(Array)\n#8 \/homepages\/19\/d438963193\/htdocs\/oc\/owncloud\/lib\/base.php(832): OC\Core\Controller\SetupController->run(Array)\n#9 \/homepages\/19\/d438963193\/htdocs\/oc\/owncloud\/index.php(39): OC::handleRequest()\n#10 {main}","File":"\/homepages\/19\/d438963193\/htdocs\/oc\/owncloud\/apps\/dav\/lib\/migration\/addressbookadapter.php","Line":72}","level":3,"time":"2016-05-07T16:18:40+00:00","method":"POST","url":"--","user":"--"}
{"reqId":"txKbQx6pS1mTYZVE/bEr","remoteAddr":"","app":"no app in context","message":"Exception: {"Exception":"DomainException","Message":"Calendar tables are missing. Nothing to do.","Code":0,"Trace":"#0 \/homepages\/19\/d438963193\/htdocs\/oc\/owncloud\/apps\/dav\/lib\/migration\/migratecalendars.php(84): OCA\Dav\Migration\CalendarAdapter->setup()\n#1 \/homepages\/19\/d438963193\/htdocs\/oc\/owncloud\/apps\/dav\/appinfo\/application.php(202): OCA\Dav\Migration\MigrateCalendars->setup()\n#2 \/homepages\/19\/d438963193\/htdocs\/oc\/owncloud\/apps\/dav\/appinfo\/install.php(27): OCA\Dav\AppInfo\Application->migrateCalendars()\n#3 \/homepages\/19\/d438963193\/htdocs\/oc\/owncloud\/lib\/private\/installer.php(639): include('\/homepages\/19\/d...')\n#4 \/homepages\/19\/d438963193\/htdocs\/oc\/owncloud\/lib\/private\/installer.php(590): OC_Installer::includeAppScript('\/homepages\/19\/d...')\n#5 \/homepages\/19\/d438963193\/htdocs\/oc\/owncloud\/lib\/private\/installer.php(561): OC_Installer::installShippedApp('dav')\n#6 \/homepages\/19\/d438963193\/htdocs\/oc\/owncloud\/lib\/private\/setup.php(370): OC_Installer::installShippedApps()\n#7 \/homepages\/19\/d438963193\/htdocs\/oc\/owncloud\/core\/controller\/setupcontroller.php(64): OC\Setup->install(Array)\n#8 \/homepages\/19\/d438963193\/htdocs\/oc\/owncloud\/lib\/base.php(832): OC\Core\Controller\SetupController->run(Array)\n#9 \/homepages\/19\/d438963193\/htdocs\/oc\/owncloud\/index.php(39): OC::handleRequest()\n#10 {main}","File":"\/homepages\/19\/d438963193\/htdocs\/oc\/owncloud\/apps\/dav\/lib\/migration\/calendaradapter.php","Line":68}","level":3,"time":"2016-05-07T16:18:40+00:00","method":"POST","url":"--","user":"--"}
{"reqId":"ZLzRuJMwd7d2G3JzoT3T","remoteAddr":"","app":"index","message":"Exception: {"Exception":"Exception","Message":"The requested uri() cannot be processed by the script '\/oc\/owncloud\/index.php')","Code":0,"Trace":"#0 \/homepages\/19\/d438963193\/htdocs\/oc\/owncloud\/lib\/base.php(837): OC\AppFramework\Http\Request->getRawPathInfo()\n#1 \/homepages\/19\/d438963193\/htdocs\/oc\/owncloud\/index.php(39): OC::handleRequest()\n#2 {main}","File":"\/homepages\/19\/d438963193\/htdocs\/oc\/owncloud\/lib\/private\/appframework\/http\/request.php","Line":621}","level":3,"time":"2016-05-07T16:19:08+00:00","method":"GET","url":"--","user":"--"}
{"reqId":"V9RcGckYaCc0R4wn6c9r","remoteAddr":"","app":"index","message":"Exception: {"Exception":"Exception","Message":"The requested uri() cannot be processed by the script '\/oc\/owncloud\/index.php')","Code":0,"Trace":"#0 \/homepages\/19\/d438963193\/htdocs\/oc\/owncloud\/lib\/base.php(837): OC\AppFramework\Http\Request->getRawPathInfo()\n#1 \/homepages\/19\/d438963193\/htdocs\/oc\/owncloud\/index.php(39): OC::handleRequest()\n#2 {main}","File":"\/homepages\/19\/d438963193\/htdocs\/oc\/owncloud\/lib\/private\/appframework\/http\/request.php","Line":621}","level":3,"time":"2016-05-07T16:19:40+00:00","method":"GET","url":"--","user":"--"}
The text was updated successfully, but these errors were encountered: