Owncloud resolving to /index.php/login and not /owncloud/index.php/login

atca · March 23, 2021, 3:38am

Owncloud/Apache2 are redirecting to FDQN.com/index.php/login which doesn’t load " This site can’t be reached"

Expect to redirect to FDQN.com/**owncloud**/index.php/login which does load.

How to get owncloud/apache to include the subdirectory?

I tried adding to owncloud.conf in apache sites-available/enabled

RedirectMatch ^/$ /owncloud/index.php/login

But it doesn’t work well and feels like a sticky plaster.

Steps to reproduce

go to FQDN.com

Expected behaviour

Expect to redirect to FDQN.com/owncloud/index.php/login

Actual behaviour

Instead get routed to FDQN.com/index.php/login which doesn’t work
Manually changing domain and path to FDQN.com/owncloud/index.php/login does work

Server configuration

Operating system: Ubuntu 20.04.1

Web server: Apache 2.4.41

Database: n/a

PHP version: n/a

ownCloud version: 10.5.0.10

Updated from an older ownCloud or fresh install: Update from prior version (unknown)

Where did you install ownCloud from: owncloud.org repo

Signing status (ownCloud 9.0 and above): Where to find this?

Login as admin user into your ownCloud and access 
paste the results into h and puth the link here.

No errors have been found.

The content of config/config.php:

<?php
$CONFIG = array (
  'updatechecker' => false,
  'instanceid' => 'REDACT',
  'passwordsalt' => 'REDACT',
  'secret' => 'REDACT',
  'trusted_domains' =>
  array (
    0 => 'localhost',
    1 => '192.168.1.100',
    2 => 'FQDN.com',
  ),
  'datadirectory' => '/var/www/owncloud/data',
  'overwrite.cli.url' => 'https://localhost/owncloud',
  'dbtype' => 'sqlite3',
  'version' => '10.5.0.10',
  'logtimezone' => 'UTC',
  'installed' => true,
  'maintenance' => false,
  'theme' => '',
  'loglevel' => 2,
  'logtimezone' => 'Europe/London',
);

Apache virtualhost config:

#Alias /owncloud "/var/www/owncloud/"

<VirtualHost *:443>
        Alias /owncloud "/var/www/owncloud/"
        ServerName FQDN.com
        DocumentRoot /var/www/owncloud
#       RedirectMatch ^/$ /owncloud/index.php/login #this doesn't really work very well
        <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
#         Satisfy Any
        </Directory>
        <Directory "/var/www/owncloud/data/">
          Require all denied
        </Directory>
        <IfModule mod_headers.c>
          Header always set Strict-Transport-Security "max-age=15552000; includeSubDomains"
        </IfModule>
</VirtualHost>

Client configuration

Browser: Chrome

eneubauer · March 23, 2021, 9:16am

That’s exactly how you do it. You have to configure a redirect in the web server. What is the problem with that?

Technically this isn’t even an ownCloud problem.

If you configure your webserver to have ownCloud installed in a sub directory, then that is what it should do.

If you don’t like that, you have two options:

What you have already done, configure a redirect
You could reconfigure your webserver to have ownCloud served just from the domain.

atca · March 24, 2021, 2:10am

The redirect does correctly redirect the url address but the page doesn’t load. I then have to refresh with the correctly ‘received’ redirect URL and the page loads, it isn’t seamless.

Unfortunately I have other sites on the the apache server so this needs to be at /owncloud. I thought enabling the alias in the vhost may have helped but it doesn’t seem to make a difference to the initial loading of index.php at FQDN/index.php

I appreciate it is more of an apache issue, but I thought owncloud was always at /owncloud/index.php which is why I was confused the site doesn’t automatically load up at FQDN/owncloud/index.php but for some reason tries to open at FQDN/index.php

I’ve tried the steps to enable php less access, e.g. FQDN/owncloud/login but again same issue it tries to load FQDN/login which doesn’t work, FQDN/owncloud/login then entered manually works.

Welcome any other pointers, I thought someone else may have had this issue.

eneubauer · March 24, 2021, 9:26am

A production instance that is business critical should be an instance that isn’t hosting anything else. If you don’t have that requirement then this is fine.

You can setup as main domain, sub domain or sub folder, it doesn’t matter it should mainly be an apache issue how you configure that. With sub domains you could have multiple websites running on the same server without the need for subfolders using virtual hosts.

Again that is just standard apache configuration, and how it should be. If you need something else, you need to reconfigure apache.

I still don’t understand what the current situation is, so perhaps you could do the following and show us the output:

# 1. What happens on main domain:
curl -I FQDN
# This should show a Location: response header which is where it is redirecting to
# From how I understand your RedirectMatch the content of the Location response header should be what we test next
curl -I FQDN/owncloud/index.php/login
# If that wasn't what the location header was showing also use the other location header for the next test
curl -I <content of location header>

If you have a Linux or Mac workstation you can run curl directly there, otherwise just install curl on your ownCloud web server, just be aware that there could be subtle difference to how the hostname is resolved and the traffic is routed. Not sure if you can install curl on Windows nowadays.

Alternatively you could also have a look into the network tab of the developer console of your browser. There you can click on any request to see request and response headers and see which redirect comes when.

I know setting this up right can be very frustrating and require a lot of trial and error

Finally there is one ownCloud config.php variable which could help you here:
https://doc.owncloud.com/server/10.4/admin_manual/configuration/server/config_sample_php_parameters.html#override-ownclouds-webroot

atca · March 24, 2021, 6:42pm

Curl doesn’t like my self signed SSL certs. Maybe time to move on to lets encrypt.

curl: (60) SSL certificate problem: self signed certificate
More details here: https://curl.haxx.se/docs/sslcerts.html

curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.

Dev Tools > Network didn’t give much interesting away mainly because the direct seems to fail, as the redirect drops https to http. Owncloud is only served on https/

That said the virtualhost redirect does semi work, as it does substitue the path just drops the ssl:

RedirectMatch ^/$ /owncloud/index.php/login

Is redirecting http**s**://FQDN/owncloud/index.php/login now to http://FQDN/owncloud/index.php/login

Running the regexp through a tester like https://regex101.com/ or https://regexr.com/ does not find a match.

So a couple of things to try and fix https:// redirecting to http:// which I assume is a regexp issue. I’d welcome any pointers on the regexp as I’m struggling here given the existing expression fails in any testing tools I’ve tried, but clearly does something.

And second maybe swap to a letsencrypt cert to help simplify degugging.

eneubauer · March 25, 2021, 10:44am

You can just run curl -Ik <URL> instead.

That could be the root cause of the issue. Make sure that from the HTTP sites you have the correct redirects to HTTPS in place.
Browser generally don’t like HTTPS connection downgrading to HTTP.

atca · March 25, 2021, 3:19pm

But I don’t get what causes the drop down in the first place, I start off on https:// and get dropped to http:// that first drop down feels like it shouldn’t happen in any case.

eneubauer · March 26, 2021, 9:22am

Something in the apache configuration. Perhaps checking your configuration with apachectl -S could help:
This should show you something like this:

root@test:~# apachectl -S 
AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 127.0.1.1. Set the 'ServerName' directive globally to suppress this message
VirtualHost configuration:
*:80                   host.owncloud.tld (/etc/apache2/sites-enabled/owncloud.conf:4)
ServerRoot: "/etc/apache2"
Main DocumentRoot: "/var/www/html"
Main ErrorLog: "/var/log/apache2/error.log"
Mutex default: dir="/var/run/apache2/" mechanism=default 
Mutex mpm-accept: using_defaults
Mutex watchdog-callback: using_defaults
Mutex rewrite-map: using_defaults
Mutex ssl-stapling-refresh: using_defaults
Mutex ssl-stapling: using_defaults
Mutex ssl-cache: using_defaults
PidFile: "/var/run/apache2/apache2.pid"
Define: DUMP_VHOSTS
Define: DUMP_RUN_CFG
User: name="www-data" id=33
Group: name="www-data" id=33

If you have multiple apache vhost configurations they should show here. Then you could check all the files that are in there, for a redirect.
Otherwise a simple grep on the /etc/apache2 directory could point you in the right direction:

grep -Ri redir /etc/apache2/

instead of redir you could check other typical directives that could redirect you somehow.

Finally double check for .htaccess files:

find /var/www/ -name ".htaccess"

atca · March 27, 2021, 4:57pm

So I’ve removed FDQN/owncloud and moved to subdomain.FQDN/

This seems to have cleared up a lot of headache, including the the https drop down to http. I’ve also moved to letsencrypt at the same time.

Thanks for your pointers, I think subdomains and a properly sign cert help for anyone who follow this thread in future.

system · June 25, 2021, 4:57pm

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.