Upgrade to 9.0.2.2 leads to Internal Server Error #24426
Comments
|
same here |
|
The problem here too since the upgrade, but only when using the Virtual Host for in the /etc/apache2/sites-available/xyz.conf file. In the /etc/apache2/conf-available/owncloud.conf When using this alias by calling then it works fine. A quick workaround would be to add a redirection for the root to /owncloud/ to the VirtualHost config file: if then the Alias is defined in /etc/apache2/conf-available/owncloud.conf then like this, at least the calendars on the client devices still work without changing anything. |
|
Same here, the Redirect quick fix solved the issue, anyway it's hard to understand how an automatic apt-get update could break the system so badly (users couldn't access their data). Maybe more testing is needed before releasing a package in the repository. |
Testing repositories are available here: https://download.owncloud.org/download/repositories/9.0:/testing/owncloud/index.html where you can test the packages. |
|
@RealRancor I think @stefanomarty means adding a unit test in the CI solution, not the an upstream testing repo. A bug like this is very difficult to debug for most consumers of the software. To that end @PVince81, I think this bug is serious enough to warrant a hotfix be deployed. I imagine there are a few people who upgraded their system in the wake of the latest OpenSSL exploit who have broken OwnCloud installs right now. |
|
I'm using owncloud with a reverse proxy and this upgrade broke my installation, too. |
But it helps if people are testing pre-release and finding this issue before the final release. |
|
So far from what I understand this is a packaging issue, so need to have a look at the packages themselves. Setting to 9.0.2 to look at fixing said packages. |
|
All, please share your Apache config, ownCloud config and .htaccess file via gist.github.com and post a link here. Thanks a lot. |
|
@benoitberlin Your configuration makes me a bit suspicious:
Are you sure you access ownCloud under |
|
@LukasReschke From what i have read until now all people facing this issue have changed their document root to point directly to /var/www/owncloud instead of using the Alias /owncloud /var/www/owncloud shipped by the package. |
|
Oh. Jesus. People, please don't do that 🙈 |
|
Ok. Some more productive help: In your config.php file the URL to your ownCloud is stored, if you change the URL to your ownCloud you also need to adjust So whoever encounters this problem please:
|
|
Okay excellent @LukasReschke. That fixes it for me. However, I do have to ask the obvious question: Why did our configurations work in the previous version(s) and break in this version? Specifically modifying the |
|
Nice, thank you very much. For me it worked to change the .htaccess! |
|
@LukasReschke A lot of people don't want to have ownCloud reachable via /owncloud but via the root domain. The main problem here is that there is no documentation about that available. I had created owncloud-archive/documentation#2205 to document the requirements. |
Because with ownCloud 9.0.2 we added code that the That said, your configuration has broken other more subtle things before already. Such as links generated by the command bus queue. (e.g. cron) – Now you just notice it actually earlier… |
Make sure you also adjust your |
|
Packaging perspective: We provide a default owncloud.conf for apache. As it is a config file, it should not be overwritten/refreshed during package upgrade. Some of the reports above leave the impression that something was overwritten. Please clarify - Everything else that is discussed here is not related to packaging. |
|
@fgdeluca that's your problem. change it to the domain name url you want to access the site from: http://myhost.com/ and if you don't use http://myhost.com/owncloud you need to remove owncloud from RewriteBase so that it is just "/" That's what I did to get mine working. |
|
@ishmot I believe that has fixed it. Thank you! Now if I could only get rid of these warnings about the integrity of my code... |
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.
|
Is this going to be fixed in future release? |
|
Try to fresh install using setup-owncloud.php. |
|
@jsl303 I think "setup-owncloud.php" might not be able to automatically setup OC in all reverse proxy situations. Please have a look at your config.php and make sure the values are correct. |
|
Strangely, I fresh installed 8.2.5, and I get no error. |
|
It turns out 9.0.2 fresh install doesn't have this problem! |
|
I had the same problem and found the problem came from the RewriteBase option in .htaccess file. But I think this is wrong. We are offering an owncloud instance to people. They all can access the instance via an common address (cloud.xxx.org/project) and they also can choose to have their own domain name to access it if they want (cloud.project.org). With this RewriteBase option, it's not possible anymore. The only way to come back having several domain names is by removing completely the option RewriteBase. Up to now, I didn't see any problem by removing the option, but maybe problems will come later. |
|
I was using v9.01. |
|
@LukasReschke Is removing the RewriteBase and option here? @quenenni Did removing it revert it back to the old behaviour? |
|
@enoch85 : As far as I could see, yes. Everything works fine now. |
|
The RewriteBase (or better this complete .haccess block) is used for "Pretty URLs" (without the index.php). You can't remove it completely without issues. With #24539 oC won't enable those URLs by default so this is then not an issue anymore. |
|
Great, this issue can be closed then as it's fixed and backported to stable 9 as well. |
|
Hello, I believe I am having this issue on a fresh install of Owncloud 9 Ubuntu 16.04, using the OpenSUSE repos. The underlaying cause of this, however, appears to be the reverse - I have NOT moved or relocated my install - it is at http://localhost/owncloud . Seeing this thread, I checked my /var/www/owncloud/.htaccess , and discovered the RewriteBase is set to '/' by default, which doesn't match the default install location of '/owncloud'. Also, it took me 3 days of searching just to find this page. That's 3 days of downtime on a fresh install! My apologies for venting some frustration. Just wanted to tip you off that somebody seems to have tried to fix this in git, and shot everybody else in the foot... |
|
I had the same problem after upgrading in Jessie. The fix from LukasReschke commented on May 4 worked for me. I do have the apache conf file pointing to /var/www/owncloud and disabled the /owncloud alias because I wanted to use owncloud at http://owncloud.mysite.com/ |
|
Hi, I'm guilty of changing my owncloud.conf file as well. I made the following changes: <VirtualHost *:443> ####Configuration for SSL ##### My .htaccess file (for some reason) has the domain specified(I didn't change this) RewriteCond %{REQUEST_URI} !^/.well-known/acme-challenge/.* My config.php file has: 'overwrite.cli.url' => 'cloud.domain.com' So what exactly should I be changing? I know it's a rewrite problem because the apache2 error log file has the following entry: /var/www/owncloud/.htaccess: RewriteBase: argument is not a valid URL |
|
This:
needs to be:
|
|
Unfortunately that still gives me this :/
|
|
You need to change the rewrite Base in htaccess. |
|
Unfortunately that now gives me:
|
|
Right, got it fixed! typo on the config file. |
|
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. |
and others
Steps to reproduce
Expected behaviour
Normal screen after login should appear (seeing the data etc)
Actual behaviour
Error after login:
Server configuration
Operating system: Debian Jessie 8.4
Web server: Apache/2.4.10
Database: mysql Ver 15.1 Distrib 10.0.23-MariaDB
PHP version: PHP 5.6.20-0+deb8u1
ownCloud version (see ownCloud admin page): 9.0.2.2 (from config.php as weblogin doesnt work)
Updated from an older ownCloud or fresh install: from 9.0
ownCloud log (data/owncloud.log): please see below
Special configuration (external storage, external authentication, reverse proxy, server-side-encryption):
No server-side encryption. I triggered an upgrade via
apt-get upgradeand then performedsudo -u www-data php ./occ upgradewith terminated without any errors. Then, I disabled the maintanence mode in config.php and rebooted.There are several errors in /var/www/owncloud/data/owncloud.log like this one (IPs blanked):
/etc/apache2/sites-enabled/000-default.conf
/etc/apache2/sites-enabled/default-ssl.conf
The owncloud update was triggered by the upgrade of this bunch of packages today:
/var/log/apt/history.log
config.php
The text was updated successfully, but these errors were encountered: