Core: Upgrade to 9.0.2.2 leads to Internal Server Error

[bonanza123]

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]

same here

[MaxBo]

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]

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]

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]

@jnweiger @LukasReschke

[NightKhaos]

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

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]

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]

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.

[LukasReschke]

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

[benoitberlin]

https://gist.github.com/benoitberlin/4d1eafdbc406fd0a695a227e90ee6599

[LukasReschke]

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

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

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

[LukasReschke]

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]

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]

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

[ghost]

@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 https://github.com/owncloud/documentation/issues/2205 to document the requirements.

[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?

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]

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]

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.

[majorErr0r]

Thanks for the immediate help! This fixes it for me. (changed config.php and .htaccess as described)

[NightKhaos]

@jnweiger Provided the config.php and .htaccess are similarly marked as config files, I cannot identify anything in my configuration that would cause problems here.

FYI, I think the sev1 label can be dropped from this as the issue has been identified and instructions to fix this issue have been provided from @LukasReschke.

[NightKhaos]

@LukasReschke Is there anything we should investigate regarding possible issues our reconfiguration (i.e. you mentioned cron) caused? Any checks against the database?

[ghost]

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 -

From what i have read the users have disabled the /etc/apache2/conf-enabled/owncloud.conf after the initial installation (which caused the overwrite.cli.url pointing to http://example.com/owncloud) and pointed now the main vhost to /var/www/owncloud.

Anyone can confirm this?

[bonanza123]

Thanks all of you for your fast feedback and solution (I couldn't test it sofar). But what I noticed is that there is a wiki entry on how to set up nginx with owncloud but no instructions how to properly/correctly use the shipped /etc/apache2/conf-enabled/owncloud.conf for apache with HTTP/HTTPS settings. I'm still not sure how to do this correctly, i.e. how it is intended when using using the packaged version.

[ghost]

but no instructions how to properly/correctly use the shipped /etc/apache2/conf-enabled/owncloud.conf for apache with HTTP/HTTPS settings. I'm still not sure how to do this correctly, i.e. how it is intended when using using the packaged version.

https://github.com/owncloud/documentation/issues/2205

[bonanza123]

@RealRancor yes, but from the title it sounds like it just about moving the root from deafault / to /owncloud but not about the general apache settings (as they are given for nginx)

[ghost]

@bonanza123 The nginx config is community maintained by a few people. For apache2 no one has step up to do that but you're free to help documenting the apache settings in the documentation.

[NightKhaos]

@RealRancor That config is still enabled in my configuration. However, the default site is disabled in favour of a master redirect on 80 (that redirects everything to 443 SSL), and sites for the multiple sites running on this machine, of which owncloud-ssl.conf is one. The conf thus provides the directory access rights for the /var/www/owncloud directory.

Do you want me to upload my apache config to gist?

[bonanza123]

@NightKhaos that would be perfect. Thanks a lot in advance!

[NightKhaos]

https://gist.github.com/NightKhaos/de52f1804eaa207ab6fa730afba34f06

@RealRancor @jnweiger I uploaded the relevant files to explain my configuration. Included a few of the other vhosts for completeness, but they'll probably not help you. My concern is with the .htaccess file. Should this also be marked as a configuration file?

@bonanza123 You'll be interested in particular in owncloud-ssl.conf, config.php and .htaccess. FYI, I am now following owncloud/documentation#2205, please direct any questions related to conf there to keep this thread clean. I will post the gist there as well.

[PVince81]

@RealRancor thanks for the doc ticket, I think this is the way to go.

I'd like to close this issue in favor of the documentation ticket https://github.com/owncloud/documentation/issues/2205

Additional question: is it possible to detect this situation and show a warning in the admin page ? Or is the admin page not even reachable in this state ?

[bonanza123]

@PVince81 in my case, the admin page wasn't reachable anymore.

[Castiontone]

Thanks @LukasReschke ! Removing the 'overwrite.cli.url' - line worked. (I added this line last week after an Ubuntu package update on the 9.0.1 branch, which caused issues with a presumably 'unsecure' root folder.)

[ghost]

Removing the 'overwrite.cli.url' - line worked.

You shouldn't remove this line but configured it correctly to reflect the URL you're using to access your oC installation.

[Castiontone]

Thank you for your answer @RealRancor . I remove the line because I added it myself last week. It was not in the config file before I added it. Is that problematic? (I assumed having an overwrite is not the default but a fix. So if the fix is causing issues: remove it.)

[deMattin]

What's about a reverse proxy configuration?
I'm using a 9.0.2 test install proxied by my main server.
I set the settings for overwrite.cli.url (and the other overwrite settings) in config.php to the reverse url set up in my apache reverse proxy-server - this worked perfect before.
I have seen in log, that some content is tried to be loading ignoring this and uses default (or original) pathes.

On original Test-Server the path ist http://domain/owncloud and this is proxied to http://domain/oc.

In overwrite.cli.url it is set to http://domain/oc
And I get a "index.php" not found error.
Sorry that I can't give more information at the moment because I have access to the server not before next week.

[PVince81]

@jnweiger would your latest package fix affect this issue too ?

[enoch85]

If I change apache and config.php according to @NightKhaos gist, all the icons turn blank in the appdrawer, same goes for profile pic in the settings drawer.

[LukasReschke]

@deMattin Please post your complete configuration. THX a lot.

[ishmot]

Thanks everyone for this discussion. I am having the same problem. I originally had my owncloud site setup at https://myhost.com/ and the latest update broke that. So I applied the fix above in my virtualhost: (RedirectMatch ^/$ "/owncloud/" & DocumentRoot /var/www/owncloud) but now my site is only functional at https://myhost.com/owncloud/

I used occ to apply this last update. I've always done it via the web browser in the past. Is that what caused the problems I'm having?

I have not modified anything in config.php or .htaccess. My modifications have only been made in the default-ssl.conf file.

I'm unclear on what direction I need to go to make my site accessible again at the root url. Any assistance would be greatly appreciated.

[LukasReschke]

@ishmot Your overwrite.cli.url entry is wrong as described above. Fix that and then you can change the values back again. (also in .htaccess)

Do not change the location of your ownCloud without fixing your config file as well. This breaks stuff.

[ishmot]

@LukasReschke thank you! I currently have overwrite.cli.url' => 'http://localhost/owncloud'
and
RewriteBase /owncloud

should the overwrite.cli.url be https://myhost.com/owncloud or https://myhost.com (what I want it to be)?

and then what should the RewriteBase be?

Thanks again for your help. All of this is very new to me.

[LukasReschke]

overwrite.cli.url should be where you want your ownCloud to be accessible (https://myhost.com/), RewriteBase should be the part after the domain of your overwrite.cli.url. So in your case just /.

[LukasReschke]

Note that once this has been corrected once it will also be correct in the future.

[ishmot]

Will I then need to remove the (RedirectMatch ^/$ "/owncloud/" & DocumentRoot /var/www/owncloud) settings I entered into my default-ssl.conf file?

[LukasReschke]

That's more something for the forum as it is web server configuration related => forum.owncloud.org

[ishmot]

@LukasReschke Thank you! that appears to have fixed everything. I did have to remove the (RedirectMatch ^/$ "/owncloud/" & DocumentRoot /var/www/owncloud) settings I entered into my default-ssl.conf file. Again, thanks for your help.

[ghost]

That's more something for the forum as it is web server configuration related => forum.owncloud.org

Not even forum related. I think people should start using support forums for their webserver instead.

[ishmot]

I asked the question here because that particular "solution" was mentioned here by @MaxBo above. I apologize if I was out of line in any way.

[ghost]

No, it wasn't directed at you. :-) Just wanted to point out that communities dedicated to webservers are a better place to ask questions about specific questions about webservers than the owncloud.org forums

[MaxBo]

I posted that "solution" 8RedirectMatch ^/$ "/owncloud/") just as a quick workaroud. Thanks to all for providing the real solution with the overwrite.cli.url and .htaccess!

[deMattin]

@LukasReschke:
I figured it out with your hints.

As mentioned above, I have set up an apache reverse proxy and on original Test-Server (owncloud 9.x) the path ist https://internaldomain/owncloud and this is proxied to https://domain/oc on server that is accessable from the internet and running productive owncloud 8.x instance on default pathes.
On owncloud 9.x test server the overwrite.cli.url is (and has to be) correctly set to http://domain/oc and this also seems to be set in rewrite rules in .htaccess by owncloud instance.
This is wrong in reverse proxy case!

In .htaccess I simply had to change the pathes to the original path and not the reverse proxied path (which is set in overwrite.cli.url) to get everything working as expected:
So changing this automatic settings in .htaccess of owncloud 9.x test server:

...
</IfModule>
#### DO NOT CHANGE ANYTHING ABOVE THIS LINE ####

ErrorDocument 403 /oc/core/templates/403.php
ErrorDocument 404 /oc/core/templates/404.php
<IfModule mod_rewrite.c>
  RewriteRule . index.php [PT,E=PATH_INFO:$1]
  RewriteBase /oc
  <IfModule mod_env.c>
    SetEnv front_controller_active true
    <IfModule mod_dir.c>
      DirectorySlash off
    </IfModule>
  </IfModule>
</IfModule>

to

...
</IfModule>
#### DO NOT CHANGE ANYTHING ABOVE THIS LINE ####

ErrorDocument 403 /owncloud/core/templates/403.php
ErrorDocument 404 /owncloud/core/templates/404.php
<IfModule mod_rewrite.c>
  RewriteRule . index.php [PT,E=PATH_INFO:$1]
  RewriteBase /owncloud
  <IfModule mod_env.c>
    SetEnv front_controller_active true
    <IfModule mod_dir.c>
      DirectorySlash off
    </IfModule>
  </IfModule>
</IfModule>

is the change that is required.

[fgdeluca]

I too am experiencing a world of trouble and I'm confused as to what I actually need to post for you all to help me out. I'm somewhat of a novice user. Could someone please specify exactly what you need to see to help me? Also, what should I be removing from my configuration, such as IP address and passwords to maintain anonymity? I'm on Linux Mint 17.2 64-bit and using apache2. Thanks!

[ghost]

@fgdeluca There is no need to post additional info here. The reason of this (a wrong configured config option) and hint how ti fix your config is available here: https://github.com/owncloud/core/issues/24426#issuecomment-216814100

[fgdeluca]

@RealRancor Thank you for your quick response. I'm aware of this suggestion, but it did not work for me. I'd like someone to look at my config if possible.

[ishmot]

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

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

RewriteBase /owncloud

[ishmot]

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

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

[jsl303]

Is this going to be fixed in future release?

[jsl303]

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]

@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 https://github.com/owncloud/core/issues/24426#issuecomment-216814100

[jsl303]

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]

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

[quenenni]

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]

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]

@LukasReschke Is removing the RewriteBase and option here?

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

[quenenni]

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

[ghost]

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 https://github.com/owncloud/core/pull/24539 oC won't enable those URLs by default so this is then not an issue anymore.

[enoch85]

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

[aaronouthier]

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]

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]

Hi,

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

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/

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:

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

needs to be:

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

[CharlieNZ]

Unfortunately that still gives me this :/

[DeepDiver1975]

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

[CharlieNZ]

Unfortunately that now gives me:

[CharlieNZ]

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

[lock[bot]]

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.