No login after upgrade from 9.1.8 to 10.1.1.1

Server
1

Steps to reproduce

  1. Run 9.1.8 happily on Debian 9
  2. Go to admin menu, follow upgrade instructions
  3. Things don’t go too well, lots of error messages
  4. Fix all errors (upgrade to PHP7, remove all apps)
  5. Finish upgrade manually with php occ upgrade
  6. Go to site, enter credentials
  7. Nothing happens :
    • no logs in the web server or owncloud log files
    • no log-in denied message (no wrong password, etc…)
  8. Browser follows through to login page

Expected behaviour

Successful login and files displayed.

Actual behaviour

Nothing beyond login screen.

Server configuration

Operating system:
Debian 9.11

Web server:
Apache 2

Database:
MariaDB

PHP version:
7.0

ownCloud version: (see ownCloud admin page)
10.1.1.1

Updated from an older ownCloud or fresh install:
Just updated from 9.1.8 through legit channels.

Where did you install ownCloud from:
Initially : 9.1.0 tarball.

Signing status (ownCloud 9.0 and above):

=> can’t login !!

The content of config/config.php:

{
    "system": {
        "instanceid": "oc765a449f83",
        "passwordsalt": "***REMOVED SENSITIVE VALUE***",
        "secret": "***REMOVED SENSITIVE VALUE***",
        "trusted_domains": [
            "xxxx.fr"
        ],
        "datadirectory": "\/var\/www\/xxxx\/owncloud\/data",
        "overwrite.cli.url": "https:\/\/xxxx.fr\/owncloud",
        "dbtype": "mysql",
        "version": "10.1.1.1",
        "appstoreenabled": false,
        "appstoreurl": "https:\/\/marketplace.owncloud.com\/api\/v0",
        "apps_paths": [
            {
                "path": "\/var\/www\/xxxx\/owncloud\/apps",
                "url": "\/apps",
                "writable": false
            }
        ],
        "dbname": "owncloud",
        "dbhost": "localhost",
        "dbtableprefix": "oc_",
        "dbuser": "***REMOVED SENSITIVE VALUE***",
        "dbpassword": "***REMOVED SENSITIVE VALUE***",
        "installed": true,
        "loglevel": 3,
        "maintenance": false,
        "trashbin_retention_obligation": "auto",
        "appstore.experimental.enabled": true,
        "theme": "",
        "mail_smtpmode": "sendmail",
        "mail_from_address": "***REMOVED SENSITIVE VALUE***",
        "mail_domain": "***REMOVED SENSITIVE VALUE***",
        "mail_smtpport": "25",
        "mail_smtphost": "***REMOVED SENSITIVE VALUE***",
        "mail_smtpauthtype": "LOGIN",
        "mail_smtpauth": 1,
        "updater.secret": "***REMOVED SENSITIVE VALUE***"
    }
}

List of activated apps:

Enabled:
  - comments: 0.3.0
  - configreport: 0.1.2
  - dav: 0.4.0
  - federatedfilesharing: 0.3.1
  - federation: 0.1.0
  - files: 1.5.2
  - files_external: 0.7.1
  - files_sharing: 0.11.0
  - files_trashbin: 0.9.1
  - files_versions: 1.3.0
  - files_videoplayer: 0.9.9
  - notifications: 0.4.1
  - provisioning_api: 0.5.0
  - systemtags: 0.3.0
  - updatenotification: 0.2.1
Disabled:
  - encryption
  - external
  - firstrunwizard
  - market
  - user_external

Are you using external storage, if yes which one: local/smb/sftp/…
no

Are you using encryption:
no

Are you using an external user-backend, if yes which one: LDAP/ActiveDirectory/Webdav/…
no

Client configuration

Browser:
Firefox

Operating system:
Windows 10

Logs

Web server error log

no logs

ownCloud log (data/owncloud.log)

no log
2

Can you confirm that your webserver is running the new PHP version, by for example opening a phpinfo file in your browser?

  1. echo "<?PHP phpinfo(); ?>" > /path/to/owncloud/webroot/filename.php
  2. Open your browser and go the URL http(s)?://your.owncloud-fqdn.tld/filename.php

This should show the new PHP version.
Did you also install all the required PHP modules to run ownCloud for the new PHP version:
https://doc.owncloud.com/server/admin_manual/installation/manual_installation.html#php-extensions

3

I do confirm, the new PHP7.0 is indeed in place as well as all the recommended PHP extensions (uploader phpinfo.html for you here).

I am reluctant to move to PHP7.2 as suggested, since I don’t have a repo that I trust for this. I may end up moving to debian 10 instead.

4

On Debian you can always use deb.sury.org
Can’t hurt to go to Debian 10, that even ships PHP 7.3 already, which is more desirable:
https://www.php.net/supported-versions

But there definitely has to be something in the logs why it doesn’t work. I would also check the PHP session paths.

5

Just moved on to Debian 10 and confirmed use of PHP7.3.

Now this :slight_smile:
This version of ownCloud is not compatible with PHP 7.3
You are currently running PHP 7.3.11-1~deb10u1.

Any smooth upgrade path to something newer ?

6

I have moved on to version 10.3.2, still facing the same issue.
Now the logs show :
{“reqId”:“XiIeEtedvlyKF0pFmKyXDgAAAAY”,“level”:2,“time”:“2020-01-17T20:50:26+00:00”,“remoteAddr”:“83.205.100.249”,“user”:"–",“app”:“core”,“method”:“PROPFIND”,“url”:"/owncloud/remote.php/webdav/",“message”:“Login failed: ‘lou’ (Remote IP: ‘83.205.100.249’)”}

7

Now it seems I can’t rollback to a previous version (9.1) because it seems that earlier versions are incompatible with PHP7.3.

What a fucking mess!!!

All my data is lost…

8

Hey,

maybe you could check out the previous suggestion:

In my opinion it could be very likely that your problem is origination from the upgrade to PHP 7 and not from ownCloud itself.

Especially on PHP upgrades some linux systems are setting wrong permissions to the PHP session path / directory causing such login issues, there are a few issues where some users had got such issues sorted out by fixing the access permissions to the session path.

9

I did check this indeed. PHP sessions work judt finr with other applications hosted on the same apache instance.

10

Hi,
ownCloud version downgrades are not supported.
If you still have a backup of your old version, you should be able to restore that.

When doing an upgrade especially a more complicated one it’s always good to work on copy of your production setup to figure out the way. Once you have a confirmed working upgrade path you can apply it to your production setup.

So as I see it right now, you’ve upgraded your PHP from 5.x to 7.3, upgraded your Debian from 9 to 10 and upgraded your ownCloud from 9.1 to 10.3.2

If I was going to do this I would do it like so:

  1. Create a new Debian 10 VM
  2. Install old PHP and new PHP on the new VM
  3. Copy ownCloud installation to new VM with old PHP enabled
  4. Upgrade ownCloud
  5. Enable new PHP
  6. Make sure everything works
  7. Rerun steps 3-4 but migrate this time

There is a multitude of options available, this is just one example of how to do it. There is no right or wrong really as long as you have a clean, secure, working setup at the end.
Another option could be to upgrade PHP & ownCloud on the old server, so you have cleaner setup on the new server.

Make sure you have your log level on 0, try logging in and check /var/log/apache2/error.log and /path/to/your/owncloud/data/owncloud.log. There must be more than just “login failed”.

1 Like
11

@eneubauer

Thanks for these kind suggestions. I can only plead guilty to trying to rush an upgrade. It’s been bugging me for long that my OC 9.1 on Debian 8 was a security risk. I started with an upgrade to 9.1.8 and from there I was offered to upgrade to 10.1.1.1 by the admin web interface, which caused my confidence in the process. It turns out that my setup was not fit for 10.1.1.1, so while I was at it, I moved on to Debian 9 and then 10.

My main concern at this point is to start with a clean new install. I can live without the documents (files) history and restore backups, but I would like to keep the calendar data that is buried in SQL in some backup (in 9.1 format). Not sure what the best way would be to do this.

Anyway, sorry for the bad vibes, Owncloud is still in my opinion a great piece of software.

2 Likes
12

I would take the old calendar data from the DB and compare to new calendar data on the new server and see whether you can figure out what has changed since.

There is just too many moving parts in your upgrade path. If you want to try to save your installation, you’ll need to exactly find out which of your steps broke the setup and then go on from there.

1 Like