Upgrade from 8.1 from repository


#1

Steps to reproduce

  1. NONE

Expected behaviour

Tell us what should happen
Upgrade from Repository should upgrade to the next step

Actual behavior

Upgraded and bypassed 8.2 and caused issue (known issue if skipping version)

Server configuration

Operating system:
Ubuntu 16.04 LTS
Web server:
Apache
Database:
MYSQL
PHP version:

ownCloud version: (see ownCloud admin page)
Was 8.1 and upgraded to 9.0
Updated from an older ownCloud or fresh install:
Upgraded
Where did you install ownCloud from:
Repository
Signing status (ownCloud 9.0 and above):
Don’t know, can’t log in

Login as admin user into your ownCloud and access 
http://example.com/index.php/settings/integrity/failed 
paste the results into https://gist.github.com/ and puth the link here.

The content of config/config.php:
$CONFIG = array (
‘instanceid’ => ‘ocwtuqcb1nwb’,
‘passwordsalt’ => ‘’,
‘secret’ => ‘’,
‘trusted_domains’ =>
array (
0 => ‘192.168.63.36’,
1 => ‘96.69.223.209’,
2 => ‘96.69.223.210’,
3 => ‘96.69.223.211’,
4 => ‘96.69.223.212’,
5 => ‘96.69.223.213’,
),
‘datadirectory’ => ‘/var/www/owncloud/data’,
‘overwrite.cli.url’ => ‘http://192.168.63.36/owncloud’,
‘dbtype’ => ‘mysql’,
‘version’ => ‘8.1.3.0’,
‘dbname’ => ‘owncloud’,
‘dbhost’ => ‘localhost’,
‘dbtableprefix’ => ‘oc_’,
‘dbuser’ => ‘oc_jdeherrera’,
‘dbpassword’ => ‘’,
‘installed’ => true,
‘maintenance’ => true,
‘updatechecker’ => false,
‘theme’ => ‘’,
‘loglevel’ => 2,

Log in to the web-UI with an administrator account and click on
'admin' -> 'Generate Config Report' -> 'Download ownCloud config report'
This report includes the config.php settings, the list of activated apps
and other details in a well sanitized form.

or 

If you have access to your command line run e.g.:
sudo -u www-data php occ config:list system
from within your ownCloud installation folder

*ATTENTION:* Do not post your config.php file in public as is. Please use one of the above
methods whenever possible. Both, the generated reports from the web-ui and from occ config:list
consistently remove sensitive data. You still may want to review the report before sending.
If done manually then it is critical for your own privacy to dilligently
remove *all* host names, passwords, usernames, salts and other credentials before posting.
You should assume that attackers find such information and will use them against your systems.

List of activated apps:

If you have access to your command line run e.g.:
sudo -u www-data php occ app:list
from within your ownCloud installation folder.

Are you using external storage, if yes which one: local/smb/sftp/…
NO
Are you using encryption: yes/no
NO
Are you using an external user-backend, if yes which one: LDAP/ActiveDirectory/Webdav/…
NO

LDAP configuration (delete this part if not used)

NO

With access to your command line run e.g.:
sudo -u www-data php occ ldap:show-config
from within your ownCloud installation folder
NO, says "Could not open imput file: occ"
Without access to your command line download the data/owncloud.db to your local
computer or access your SQL server remotely and run the select query:
SELECT * FROM `oc_appconfig` WHERE `appid` = 'user_ldap';


Eventually replace sensitive data as the name/IP-address of your LDAP server or groups.

Client configuration

Browser:
Chrome
Operating system:
Windows 10 Pro

Logs

Web server error log

Insert your webserver log here

ownCloud log (data/owncloud.log)

Insert your ownCloud log here

Browser log

Insert your browser log here, this could for example include:

a) The javascript console log
b) The network log 
c) ...

Upgrade from 8.0.4 (stable) to latest
#2

I have already started copying the entire owncloud folders with the files that was stored on the server. Maybe what I need to do is finish this, remove owncloud, install again (not as upgrade), then put the files back after up and running. I believe this will work but maybe you can provide information about this options as well.


#3

Well since I have not seen any comments to this post, maybe I should ask a more specific question. Since I have copied the entire owncloud folder from /var/www when I install fresh copy of ver 9, can I just copy the “data” and “config” folder back into new install and be good to go - or will this break owncloud?


#4

Hey,

if you got from 8.1 to 9.0 then i think you probably have chosen the wrong repository :slightly_frowning_face:

It seems various repositories providing various ownCloud versions are listed at https://owncloud.org/download/older-versions/. If you’re still on 8.1 then i think you could add:

http://software.opensuse.org/download/package?project=isv:ownCloud:community:8.1&package=owncloud

After upgrading to the latest 8.1.12 version you could continue with 8.2.11 afterwards:

https://download.owncloud.org/download/repositories/8.2/owncloud

and after a successful upgrade to 8.2.11 a final step to the latest 10.0.10:

https://download.owncloud.org/download/repositories/stable/owncloud/index.html


#5

Thank you for all of the repository info - i was struggling to find them for some reason. This is really helpful. I did get it up and running by purging 9 (after backing up data) and installed 9 fresh. Allot of work but done. I need to upgrade to 10 still but this will give me all I need (I hope)


#6

Hey,

if you’re already at ownCloud 9.0 then it might be one step too much but (i think) still doable to get to 10.0.

From what i have read in the past you could go from 8.2.11 directly to 10.0.10. If you’re now on e.g. 9.0.11 to need to do the intermediate steps to 9.1.8 before being allowed to go to 10.0.10.


#7

I wanted to reply and explain outcome - and that I never was able to fix the owncloud install, apache2 or access the data within owncloud. I found that part of the issue was installation of xRDP and dependent software (so not all owncloud). However, I rebuilt a brand new installation server (Ubuntu 18.04 LTS) and installed only base apps and owncloud with dependent software. Then I had a power bump that for some reason our UPS did not keep the server running (whole different issue. I assume this caused a problem with one of the sync setups which generated error on client software " Server replied:internal Server Error" (without the “500”) pointing to one of the folders in sync set. I did a bunch of playing with it - removed folder from “files” and files_versions from within the “data” folder. Still the same issue. I do realize this is most likely due to the database that holds metadata info - which is fine but there is no fix for this that I can find. So I ended up creating a new login for this sync, deleted the “owncloud config files” from the client system shared folder and started new sync - and it is syncing now. It is large for this sync purposes but not in the scheme of things today. My issue is I wish there was a better process/documentation for these issues. I can’t keep fighting this program just to sync 4 systems - and in this one case for almost 2 weeks. I thought it was a great solution until we attempted the required upgrade to owncloud, now I have doubts how well this solution will be in the future. At this point, there is no way I would move to the enterprise solution and pay thousands a year. Sorry but I think this needs to be presented.