Skip to content
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

Upgrade to 9.0.2.2 leads to Internal Server Error #24426

Closed
bonanza123 opened this issue May 3, 2016 · 80 comments

Comments

Projects
None yet
@bonanza123
Copy link

commented May 3, 2016

Steps to reproduce

  1. Logging in from website

Expected behaviour
Normal screen after login should appear (seeing the data etc)

Actual behaviour
Error after login:

Internal Server Error
The server encountered an internal error and was unable to complete your request.
Please contact the server administrator if this error reappears multiple times, please include the technical details below in your report.
More details can be found in the server log.
Technical details
    Remote Address: yyy.xxx.yyy.xxx
    Request ID: 01rh8/w8DAWYVV4XKhyg

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 upgrade and then performed sudo -u www-data php ./occ upgrade with 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):

{"reqId":"oJZ8JSOK0rRZSJaI5rsV","remoteAddr":"xxx.xxx.xxx.xxx","app":"index","message":"Exception: {\"Exception\":\"Exception\",\"Message\":\"The requested uri(\\\/apps\\\/files\\\/) cannot be processed by the script '\\\/owncloud\\\/index.php')\",\"Code\":0,\"Trace\":\"#0 \\\/var\\\/www\\\/owncloud\\\/lib\\\/base.php(837): OC\\\\AppFramework\\\\Http\\\\Request->getRawPathInfo()\\n#1 \\\/var\\\/www\\\/owncloud\\\/index.php(39): OC::handleRequest()\\n#2 {main}\",\"File\":\"\\\/var\\\/www\\\/owncloud\\\/lib\\\/private\\\/appframework\\\/http\\\/request.php\",\"Line\":624}","level":3,"time":"2016-05-03T21:33:46+02:00","method":"GET","url":"\/apps\/files\/","user":"root"}
{"reqId":"U4uToMnS2E+YKYvJMfYz","remoteAddr":"xxx.xxx.xxx.xxx","app":"index","message":"Exception: {\"Exception\":\"Exception\",\"Message\":\"The requested uri(\\\/apps\\\/files\.svg) cannot be processed by the script '\\\/owncloud\\\/index.php')\",\"Car\\\/www\\\/owncloud\\\/lib\\\/base.php(837): OC\\\\AppFramework\\\\Http\\\n#1 \\\/var\\\/www\\\/owncloud\\\/index.php(39): OC::handleRequest()\\n#r\\\/www\\\/owncloud\\\/lib\\\/private\\\/appframework\\\/http\\\/request.:3,"time":"2016-05-03T21:33:49+02:00","method":"GET","url":"\/apps\/files\"user":"root"}

/etc/apache2/sites-enabled/000-default.conf

<VirtualHost *:80>
ServerName MYDOMAIN.com
ServerAlias MYDOMAIN-ALIAS.com

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}

</VirtualHost>

/etc/apache2/sites-enabled/default-ssl.conf

<IfModule mod_ssl.c>
        <VirtualHost *:443>
                ServerAdmin webmaster@localhost
                SSLProxyEngine on         
                ServerName MYDOMAIN.com
                ServerAlias MYDOMAIN-ALIAS.com

                <Directory /var/www/owncloud/>
                        Options +FollowSymlinks
                        AllowOverride All
                        <IfModule mod_dav.c>
                                Dav off
                        </IfModule>
                        SetEnv HOME /var/www/owncloud
                        SetEnv HTTP_HOME /var/www/owncloud
                </Directory>


                <IfModule mod_headers.c>
                        Header always set Strict-Transport-Security "max-age=15768000; includeSubDomains; preload"
                </IfModule>

                DocumentRoot /var/www/owncloud

                ErrorLog ${APACHE_LOG_DIR}/error.log
                CustomLog ${APACHE_LOG_DIR}/access.log combined

                SSLEngine on

                SSLCertificateFile /etc/letsencrypt/live/MYDOMAIN/fullchain.pem
                SSLCertificateKeyFile /etc/letsencrypt/live/MYDOMAIN/privkey.pem

                SSLHonorCipherOrder on
                SSLCompression          off
                SSLProtocol all -SSLv2 -SSLv3 -TLSv1
                SSLCipherSuite "ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!3DES:!MD5:!PSK"

        </VirtualHost>

</IfModule>

The owncloud update was triggered by the upgrade of this bunch of packages today:
/var/log/apt/history.log

Start-Date: 2016-05-03  14:21:03
Commandline: apt-get upgrade
Upgrade: apt:amd64 (1.0.9.8.2, 1.0.9.8.3), multiarch-support:amd64 (2.19-18+deb8u3, 2.19-18+deb8u4), linux-image-3.16.0-4-amd64:amd64 (3.16.7-ckt20-1+deb8u4, 3.16.7-ckt25-2), librsvg2-2:amd64 (2.40.5-1, 2.40.5-1+deb8u1), libssl1.0.0:amd64 (1.0.1k-3+deb8u4, 1.0.1k-3+deb8u5), apt-transport-https:amd64 (1.0.9.8.2, 1.0.9.8.3), libpam0g:amd64 (1.1.8-3.1+deb8u1, 1.1.8-3.1+deb8u1+b1), libsane-common:amd64 (1.0.24-8, 1.0.24-8+deb8u1), owncloud:amd64 (9.0.0-1.1, 9.0.2-1.1), libgif4:amd64 (4.1.6-11, 4.1.6-11+deb8u1), apt-utils:amd64 (1.0.9.8.2, 1.0.9.8.3), tzdata-java:amd64 (2015g-0+deb8u1, 2016d-0+deb8u1), libc-dev-bin:amd64 (2.19-18+deb8u3, 2.19-18+deb8u4), libc-bin:amd64 (2.19-18+deb8u3, 2.19-18+deb8u4), libc6:amd64 (2.19-18+deb8u3, 2.19-18+deb8u4), ruby:amd64 (2.1.5+deb8u1, 2.1.5+deb8u2), libglib2.0-0:amd64 (2.42.1-1, 2.42.1-1+b1), libglib2.0-dev:amd64 (2.42.1-1, 2.42.1-1+b1), libapt-inst1.5:amd64 (1.0.9.8.2, 1.0.9.8.3), libgtk2.0-bin:amd64 (2.24.25-3, 2.24.25-3+deb8u1), libgtk2.0-common:amd64 (2.24.25-3, 2.24.25-3+deb8u1), owncloud-deps-php5:amd64 (9.0.0-1.1, 9.0.2-1.1), udev:amd64 (215-17+deb8u3, 215-17+deb8u4), base-files:amd64 (8+deb8u3, 8+deb8u4), gir1.2-gtk-2.0:amd64 (2.24.25-3, 2.24.25-3+deb8u1), gnupg:amd64 (1.4.18-7, 1.4.18-7+deb8u1), initramfs-tools:amd64 (0.120, 0.120+deb8u1), libcairo-gobject2:amd64 (1.14.0-2.1, 1.14.0-2.1+deb8u1), libpam-modules:amd64 (1.1.8-3.1+deb8u1, 1.1.8-3.1+deb8u1+b1), libsndfile1:amd64 (1.0.25-9.1, 1.0.25-9.1+deb8u1), libcairo2:amd64 (1.14.0-2.1, 1.14.0-2.1+deb8u1), libudev1:amd64 (215-17+deb8u3, 215-17+deb8u4), libsane:amd64 (1.0.24-8, 1.0.24-8+deb8u1), imagemagick-6.q16:amd64 (6.8.9.9-5, 6.8.9.9-5+deb8u1), nettle-dev:amd64 (2.7.1-5, 2.7.1-5+deb8u1), nodejs:amd64 (5.9.0-1nodesource1~jessie1, 5.11.0-1nodesource1~jessie1), libssl-dev:amd64 (1.0.1k-3+deb8u4, 1.0.1k-3+deb8u5), libapt-pkg4.12:amd64 (1.0.9.8.2, 1.0.9.8.3), libpcre3-dev:amd64 (8.35-3.3+deb8u2, 8.35-3.3+deb8u4), libhogweed2:amd64 (2.7.1-5, 2.7.1-5+deb8u1), librsvg2-common:amd64 (2.40.5-1, 2.40.5-1+deb8u1), systemd-sysv:amd64 (215-17+deb8u3, 215-17+deb8u4), libgtk2.0-0:amd64 (2.24.25-3, 2.24.25-3+deb8u1), libcairo2-dev:amd64 (1.14.0-2.1, 1.14.0-2.1+deb8u1), imagemagick:amd64 (6.8.9.9-5, 6.8.9.9-5+deb8u1), libsane-dev:amd64 (1.0.24-8, 1.0.24-8+deb8u1), systemd:amd64 (215-17+deb8u3, 215-17+deb8u4), gpgv:amd64 (1.4.18-7, 1.4.18-7+deb8u1), libpcrecpp0:amd64 (8.35-3.3+deb8u2, 8.35-3.3+deb8u4), libnettle4:amd64 (2.7.1-5, 2.7.1-5+deb8u1), libpam-modules-bin:amd64 (1.1.8-3.1+deb8u1, 1.1.8-3.1+deb8u1+b1), libmagickwand-6.q16-2:amd64 (6.8.9.9-5, 6.8.9.9-5+deb8u1), tzdata:amd64 (2015g-0+deb8u1, 2016d-0+deb8u1), openssl:amd64 (1.0.1k-3+deb8u4, 1.0.1k-3+deb8u5), libglib2.0-bin:amd64 (2.42.1-1, 2.42.1-1+b1), imagemagick-common:amd64 (6.8.9.9-5, 6.8.9.9-5+deb8u1), libsystemd0:amd64 (215-17+deb8u3, 215-17+deb8u4), linux-libc-dev:amd64 (3.16.7-ckt20-1+deb8u4, 3.16.7-ckt25-2), libpcre3:amd64 (8.35-3.3+deb8u2, 8.35-3.3+deb8u4), libmagickcore-6.q16-2:amd64 (6.8.9.9-5, 6.8.9.9-5+deb8u1), libgtk2.0-dev:amd64 (2.24.25-3, 2.24.25-3+deb8u1), locales:amd64 (2.19-18+deb8u3, 2.19-18+deb8u4), libcairo-script-interpreter2:amd64 (1.14.0-2.1, 1.14.0-2.1+deb8u1), libc6-dev:amd64 (2.19-18+deb8u3, 2.19-18+deb8u4), owncloud-files:amd64 (9.0.0-1.1, 9.0.2-1.1)
End-Date: 2016-05-03  14:23:46

config.php

<?php
$CONFIG = array (
  'instanceid' => 'abc',
  'passwordsalt' => 'abc',
  'secret' => 'abc',
  'trusted_domains' => 
  array (
    0 => 'MYDOMAIN.com',
  ),
  'datadirectory' => '/var/www/owncloud/data',
  'overwrite.cli.url' => 'https://MYDOMAIN.com/owncloud',
  'dbtype' => 'mysql',
  'version' => '9.0.2.2',
  'dbname' => 'oc-db',
  'dbhost' => 'localhost',
  'dbtableprefix' => 'oc_',
  'dbuser' => 'oc_root',
  'dbpassword' => 'abc',
  'logtimezone' => 'Europe/Berlin',
  'installed' => true,
  'memcache.local' => '\\OC\\Memcache\\APCu',
  'preview_libreoffice_path' => '/usr/bin/libreoffice',
  'loglevel' => 2,
  'logfile' => '/var/www/owncloud/data/owncloud.log',
  'appstore.experimental.enabled' => true,
  'maintenance' => false,
  'updatechecker' => false,
  'blacklisted_files' => 
  array (
    0 => '._*',
    1 => '.DS_Store',
    2 => '.DS_STORE',
    3 => '.ds_store',
    4 => '*.log',
    5 => '*.bbl',
    6 => '*.out',
    7 => '*.blg',
    8 => '*.aux',
    9 => '*.toc',
    10 => '*.synctex.gz',
    11 => '*.synctex',
    12 => '*.lof',
    13 => '*.lot',
    14 => '*.bit',
    15 => '*.idx',
    16 => '*.glo',
    17 => '*.ilg',
    18 => '*.out',
  ),
);
@benoitberlin

This comment has been minimized.

Copy link

commented May 3, 2016

same here

@MaxBo

This comment has been minimized.

Copy link

commented May 3, 2016

The problem here too since the upgrade, but only when using the Virtual Host for
cloud.mydomain.com that points to
DocumentRoot /var/www/owncloud

in the /etc/apache2/sites-available/xyz.conf file.

In the /etc/apache2/conf-available/owncloud.conf
there is an alias for /owncloud defined:
Alias /owncloud "/var/www/owncloud/"

When using this alias by calling
https://cloud.mydomain.com/owncloud

then it works fine.

A quick workaround would be to add a redirection for the root to /owncloud/ to the VirtualHost config file:
RedirectMatch ^/$ "/owncloud/"
DocumentRoot /var/www/owncloud

if then the Alias is defined in /etc/apache2/conf-available/owncloud.conf
Alias /owncloud "/var/www/owncloud/"

then
https://cloud.myserver.com
will be redirected to
https://cloud.myserver.com/owncloud

like this, at least the calendars on the client devices still work without changing anything.
shared links are broken, however.

@stefanomarty

This comment has been minimized.

Copy link

commented May 3, 2016

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.

@ghost

This comment has been minimized.

Copy link

commented May 4, 2016

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.

@PVince81

This comment has been minimized.

Copy link
Member

commented May 4, 2016

@PVince81 PVince81 added this to the 9.0.3-next-maintenance milestone May 4, 2016

@NightKhaos

This comment has been minimized.

Copy link

commented May 4, 2016

@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.

@deMattin

This comment has been minimized.

Copy link

commented May 4, 2016

I'm using owncloud with a reverse proxy and this upgrade broke my installation, too.
I set owncloud pathes (overwrite...) in config and some content is beeing tried to be loaded with ignoring this settings but with default(?) path.

@ghost

This comment has been minimized.

Copy link

commented May 4, 2016

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.

But it helps if people are testing pre-release and finding this issue before the final release.

@PVince81

This comment has been minimized.

Copy link
Member

commented May 4, 2016

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.

@PVince81 PVince81 modified the milestones: 9.0.2-current-maintenance, 9.0.3-next-maintenance May 4, 2016

@LukasReschke

This comment has been minimized.

Copy link
Member

commented May 4, 2016

All, please share your Apache config, ownCloud config and .htaccess file via gist.github.com and post a link here. Thanks a lot.

@LukasReschke

This comment has been minimized.

Copy link
Member

commented May 4, 2016

@benoitberlin Your configuration makes me a bit suspicious:

DocumentRoot /var/www/owncloud/
'overwrite.cli.url' => 'https://xxx.xxx.xxx.xx/owncloud',

Are you sure you access ownCloud under /owncloud when opening it in a browser?

@ghost

This comment has been minimized.

Copy link

commented May 4, 2016

@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.

@LukasReschke

This comment has been minimized.

Copy link
Member

commented May 4, 2016

Oh. Jesus. People, please don't do that 🙈

@LukasReschke

This comment has been minimized.

Copy link
Member

commented May 4, 2016

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 overwrite.cli.url in there. If you move it to the root then change that to /.

So whoever encounters this problem please:

  1. Make sure you did not manually fiddle around with configs
  2. If you did, and you made ownCloud accessible via different location THEN
    • Adjust overwrite.cli.url in your config.php
    • Adjust RewriteBase in your .htaccess file to reflect this change also (so for example from /owncloud to /)
@NightKhaos

This comment has been minimized.

Copy link

commented May 4, 2016

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 RewriteBase in .htaccess was the change I was missing.

@benoitberlin

This comment has been minimized.

Copy link

commented May 4, 2016

Nice, thank you very much. For me it worked to change the .htaccess!
Just changed the RewriteBase to /

@ghost

This comment has been minimized.

Copy link

commented May 4, 2016

@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/documentation#2205 to document the requirements.

@LukasReschke

This comment has been minimized.

Copy link
Member

commented May 4, 2016

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?

Because with ownCloud 9.0.2 we added code that the index.php-less URLs should also work in case one uses OCC to upgrade or install ownCloud. For this we leveraged the existing configuration flag which by default is correct unless somebody did manually move their installation 😉

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…

@LukasReschke

This comment has been minimized.

Copy link
Member

commented May 4, 2016

Just changed the RewriteBase to /

Make sure you also adjust your config.php's overwrite.cli.url or you will face the same error the next time you update.

@jnweiger

This comment has been minimized.

Copy link
Contributor

commented May 4, 2016

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.

@ishmot

This comment has been minimized.

Copy link

commented May 11, 2016

@fgdeluca, what do you have set for your overwrite.cli.url? and what do you have set for your RewriteBase in your .htaccess file?

@fgdeluca

This comment has been minimized.

Copy link

commented May 12, 2016

@RealRancor
'overwrite.cli.url' => 'http://localhost/owncloud',

RewriteBase /owncloud

@ishmot

This comment has been minimized.

Copy link

commented May 12, 2016

@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.

@fgdeluca

This comment has been minimized.

Copy link

commented May 12, 2016

@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...

DeepDiver1975 added a commit that referenced this issue May 12, 2016

Do not automatically try to enable index.php-less URLs (#24539)
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.

@MorrisJobke MorrisJobke modified the milestones: 9.0.3-current-maintenance, 9.0.2 May 12, 2016

@jsl303

This comment has been minimized.

Copy link

commented May 17, 2016

Is this going to be fixed in future release?

@jsl303

This comment has been minimized.

Copy link

commented May 17, 2016

Try to fresh install using setup-owncloud.php.
After finishing, it redirects to localhost instead of the domain.
Never had this problem before.
cat owncloud.log
{"reqId":"lN37lVHPnSg3xVqS0VeR","remoteAddr":"","app":"no app in context","message":"Exception: {"Exception":"DomainException","Message":"Contacts tables are missing. Nothing to do.","Code":0,"Trace":"#0 \/opt\/lampp\/htdocs\/cloud\/apps\/dav\/lib\/migration\/migrateaddressbooks.php(83): OCA\Dav\Migration\AddressBookAdapter->setup()\n#1 \/opt\/lampp\/htdocs\/cloud\/apps\/dav\/appinfo\/application.php(186): OCA\Dav\Migration\MigrateAddressbooks->setup()\n#2 \/opt\/lampp\/htdocs\/cloud\/apps\/dav\/appinfo\/install.php(26): OCA\Dav\AppInfo\Application->migrateAddressbooks()\n#3 \/opt\/lampp\/htdocs\/cloud\/lib\/private\/installer.php(639): include('\/opt\/lampp\/htdo...')\n#4 \/opt\/lampp\/htdocs\/cloud\/lib\/private\/installer.php(590): OC_Installer::includeAppScript('\/opt\/lampp\/htdo...')\n#5 \/opt\/lampp\/htdocs\/cloud\/lib\/private\/installer.php(561): OC_Installer::installShippedApp('dav')\n#6 \/opt\/lampp\/htdocs\/cloud\/lib\/private\/setup.php(370): OC_Installer::installShippedApps()\n#7 \/opt\/lampp\/htdocs\/cloud\/core\/controller\/setupcontroller.php(64): OC\Setup->install(Array)\n#8 \/opt\/lampp\/htdocs\/cloud\/lib\/base.php(832): OC\Core\Controller\SetupController->run(Array)\n#9 \/opt\/lampp\/htdocs\/cloud\/index.php(39): OC::handleRequest()\n#10 {main}","File":"\/opt\/lampp\/htdocs\/cloud\/apps\/dav\/lib\/migration\/addressbookadapter.php","Line":72}","level":3,"time":"2016-05-17T01:56:09+00:00","method":"POST","url":"--","user":"--"}
{"reqId":"lN37lVHPnSg3xVqS0VeR","remoteAddr":"","app":"no app in context","message":"Exception: {"Exception":"DomainException","Message":"Calendar tables are missing. Nothing to do.","Code":0,"Trace":"#0 \/opt\/lampp\/htdocs\/cloud\/apps\/dav\/lib\/migration\/migratecalendars.php(84): OCA\Dav\Migration\CalendarAdapter->setup()\n#1 \/opt\/lampp\/htdocs\/cloud\/apps\/dav\/appinfo\/application.php(202): OCA\Dav\Migration\MigrateCalendars->setup()\n#2 \/opt\/lampp\/htdocs\/cloud\/apps\/dav\/appinfo\/install.php(27): OCA\Dav\AppInfo\Application->migrateCalendars()\n#3 \/opt\/lampp\/htdocs\/cloud\/lib\/private\/installer.php(639): include('\/opt\/lampp\/htdo...')\n#4 \/opt\/lampp\/htdocs\/cloud\/lib\/private\/installer.php(590): OC_Installer::includeAppScript('\/opt\/lampp\/htdo...')\n#5 \/opt\/lampp\/htdocs\/cloud\/lib\/private\/installer.php(561): OC_Installer::installShippedApp('dav')\n#6 \/opt\/lampp\/htdocs\/cloud\/lib\/private\/setup.php(370): OC_Installer::installShippedApps()\n#7 \/opt\/lampp\/htdocs\/cloud\/core\/controller\/setupcontroller.php(64): OC\Setup->install(Array)\n#8 \/opt\/lampp\/htdocs\/cloud\/lib\/base.php(832): OC\Core\Controller\SetupController->run(Array)\n#9 \/opt\/lampp\/htdocs\/cloud\/index.php(39): OC::handleRequest()\n#10 {main}","File":"\/opt\/lampp\/htdocs\/cloud\/apps\/dav\/lib\/migration\/calendaradapter.php","Line":68}","level":3,"time":"2016-05-17T01:56:09+00:00","method":"POST","url":"--","user":"--"}
{"reqId":"cpOu11k7LZ6oU7qAejly","remoteAddr":"","app":"index","message":"Exception: {"Exception":"Exception","Message":"The requested uri() cannot be processed by the script '\/cloud\/index.php')","Code":0,"Trace":"#0 \/opt\/lampp\/htdocs\/cloud\/lib\/base.php(837): OC\AppFramework\Http\Request->getRawPathInfo()\n#1 \/opt\/lampp\/htdocs\/cloud\/index.php(39): OC::handleRequest()\n#2 {main}","File":"\/opt\/lampp\/htdocs\/cloud\/lib\/private\/appframework\/http\/request.php","Line":621}","level":3,"time":"2016-05-17T01:56:47+00:00","method":"GET","url":"--","user":"--"}

@PVince81

This comment has been minimized.

Copy link
Member

commented May 17, 2016

@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.
Also see #24426 (comment)

@jsl303

This comment has been minimized.

Copy link

commented May 17, 2016

Strangely, I fresh installed 8.2.5, and I get no error.
Then I upgraded to 9.0.2 using the admin page. Still no error. Everything works.
However, if I fresh install 9.0.1, it throws an error after finishing up the setup.

@jsl303

This comment has been minimized.

Copy link

commented May 18, 2016

It turns out 9.0.2 fresh install doesn't have this problem!

@quenenni

This comment has been minimized.

Copy link

commented May 18, 2016

I had the same problem and found the problem came from the RewriteBase option in .htaccess file.

But I think this is wrong.
It means you can only access the owncloud instance via 1 domain name.
So, what's the purpose of the option "trusted_domains" in config.php file?

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.
Then it works for every domain name we use.

Up to now, I didn't see any problem by removing the option, but maybe problems will come later.
Can you tell me if RewriteBase is important?

@quenenni

This comment has been minimized.

Copy link

commented May 18, 2016

I was using v9.01.
I tested it with v9.02 and the problem is still there.
And removing the option RewriteBase solves the problem.
(and no v9.0.3 available in Debian repo)

@enoch85

This comment has been minimized.

Copy link
Member

commented May 18, 2016

@LukasReschke Is removing the RewriteBase and option here?

@quenenni Did removing it revert it back to the old behaviour?

@quenenni

This comment has been minimized.

Copy link

commented May 18, 2016

@enoch85 : As far as I could see, yes. Everything works fine now.

@ghost

This comment has been minimized.

Copy link

commented May 18, 2016

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.

@enoch85

This comment has been minimized.

Copy link
Member

commented May 18, 2016

Great, this issue can be closed then as it's fixed and backported to stable 9 as well.

@aaronouthier

This comment has been minimized.

Copy link

commented Jun 10, 2016

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...

@xabispacebiker

This comment has been minimized.

Copy link

commented Jun 30, 2016

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/

@CharlieNZ

This comment has been minimized.

Copy link

commented Jul 5, 2016

Hi,

I'm guilty of changing my owncloud.conf file as well. I made the following changes:

<VirtualHost *:443>

####Configuration for SSL #####
SSLEngine on
SSLCertificateFile /etc/apache2/ssl/owncloud.pem
SSLCertificateKeyFile /etc/apache2/ssl/owncloud.key
SSLProtocol all -SSLv2 -SSLv3
SSLCompression off
SSLHonorCipherOrder On
SSLCipherSuite EECDH+AESGCM:EECDH+AES
#End of SSL Configuration #
ServerName cloud.domain.com
Header always add Strict-Transport-Security "max-age=15768000"
ServerSignature Off
DocumentRoot /var/www/owncloud/
<Directory /var/www/owncloud>
Options Indexes FollowSymLinks MultiViews
AllowOverride All
Require all granted

My .htaccess file (for some reason) has the domain specified(I didn't change this)


RewriteCond %{REQUEST_URI} !^/.well-known/acme-challenge/.*
RewriteRule . index.php [PT,E=PATH_INFO:$1]
RewriteBase cloud.domain.com


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

@ghost

This comment has been minimized.

Copy link

commented Jul 5, 2016

This:

'overwrite.cli.url' => 'cloud.domain.com

needs to be:

'overwrite.cli.url' => 'https://cloud.domain.com'

@CharlieNZ

This comment has been minimized.

Copy link

commented Jul 5, 2016

Unfortunately that still gives me this :/

image

@DeepDiver1975

This comment has been minimized.

Copy link
Member

commented Jul 5, 2016

You need to change the rewrite Base in htaccess.
Try /

@CharlieNZ

This comment has been minimized.

Copy link

commented Jul 5, 2016

Unfortunately that now gives me:

image

@CharlieNZ

This comment has been minimized.

Copy link

commented Jul 5, 2016

Right, got it fixed! typo on the config file.
Thanks for your help everyone :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.