Downgrade owncloud 7 to owncloud 6.0.3 error

[cyberpunklynx]

Owncloud 7 wasn't useable for me. Always "403 forbidden" errors, ugly as hell.

I tried to use my backup of 6.0.3. So I took what was in "core" and overwrote the files on my server. The same for "3rd party" and "apps".

Now I see that wasn't enough:

An exception occurred while executing 'SELECT oc_permissions.fileid, permissions FROM oc_permissions INNER JOIN oc_filecache ON oc_permissions.fileid = oc_filecache.fileid WHERE oc_filecache.parent = ? AND oc_permissions.user = ?': SQLSTATE[23000]: Integrity constraint violation: 1052 Column 'permissions' in field list is ambiguous

What now??

I can't reach my list of files, not for a user, not for the admin. What's strange: I can reach the admin settings, and there are these errors all over.

A helluva hint for your future plans with owncloud:

1. inform your users before an upgrade that a completely new version will be installed. I installed 7 accidentally because I thought it was an 6.0.x upgrade
2. let your system check the database after restoring the files, like I did. In this case there should be a screen which says "Restoring database" or something. You know WordPress!? This is a feature here. Use this idea. I don't get a database backup when owncloud is backing up the install before an upgrade. Please tell me more, if this is a wrong assumption

Thanks.

[cyberpunklynx]

Well, the message above is what I get when I try to login as admin or user.

But I can reach /settings/admin, as mentioned. There, the log reads as follows:

Error hook error while running hook (\OC\Files\Storage\Shared::setup): An exception occurred while executing 'SELECT oc_share.id, item_type, item_source, item_target, oc_share.parent, share_type, share_with, uid_owner, file_source, path, file_target, permissions, stime, expiration, token, storage, mail_send FROM oc_share INNER JOIN oc_filecache ON file_source = oc_filecache.fileid WHERE file_target IS NOT NULL AND share_type IN (?,?,?) AND share_with IN (?,?) AND uid_owner != ?': SQLSTATE[23000]: Integrity constraint violation: 1052 Column 'permissions' in field list is ambiguous

It's always the same, but maybe it seems more familiar for someone.

[PVince81]

When you say you used your backup, did you mean backup of the "data" folder and backup of the database ?
I have the feeling that in your case you only restored the files ?
ownCloud doesn't have any downgrade code, so basically what you should do is extract the tarball in the emptied directory (don't just overwrite the source code files), then restore your backup of the "config" and "data" directory. And then also restore your backup of the database.
At this point you should already be back to OC 6.

It also looks like you upgraded through the "Update center" in the admin section ?

[PVince81]

@VicDeo can we add the version we're upgrading to in the update center ?

[cyberpunklynx]

@PVince81 Firstly, thanks for your reply!

Yes, I did the upgrade by using the internal update center as admin. In all of the cases prior to this event, when updating owncloud 6 to a newer version of this specific release, everything went perfect. No problems at all.

Never change a running system, but I thought the new update via the update center would just update owncloud 6 and not install a completely new version. I'm on a shared server and already experienced problems with full upgrades, I wanted to stick with 6.

Then, when 7 was installed, I experienced the "403 forbidden" problems. I already tried to add these LIMIT lines into my .htaccess, but in my case it didn't change anything. I couldn't delete or cut and paste files between folders in my cloud anymore.

So, what I did after that, was to take what was inside in the zip file which you see when visiting the update center: the folders "core", "apps", "3rd party", as mentioned by you and me. I deleted the old folders and copied these onto my server.

And then this error happened right after logging in.

The system itself seems to work, the only thing I can't visit is the tab "files". Then I see this error again.

Unfortunately I own no copy of the old owncloud 6 database. I thought I would find some hints in the zip, but there was nothing. What I need would be a procedure or something, to "downgrade" my current database so it would fit for the files of my backup.

Maybe you have some other ideas, I'm running out of them.

Regards

[PVince81]

Hmmm... I thought the update center would also backup the database.

Can you elaborate about the 403 forbidden problem ? We should definitely look into that.

I suspect something might be wrong with permissions. You could try running "./occ files:scan --all" as the web server user, if possible.

[cyberpunklynx]

Yeah, thought about the same regarding the backup zip...

The 403 forbidden problem is gone, it was present when using owncloud 7. I couldn't fix this, that's why I went back to owncloud 6 in the first place.

Due to the fact that I'm on a shared server I can't use your console command. :-/ Mabye it's possible to run this scan by using another method? Via URL or something? Via PHPMyAdmin maybe?

[PVince81]

@cyberpunklynx hmm, you could try opening the files app in the browser, then open the javascript console and type scanFiles(true);. Not sure whether it will work.

Can you check the database table oc_filecache and see what's in the permissions column ? Are there zeroes everywhere ?

[cyberpunklynx]

@PVince81 I don't know if I'm doing this right, but when opening the web console and switching to the tab "Console", the first message there is: "web console logging app was deactivated by a script of this site". Then, after typing the command and hitting enter: "ReferenceError: scanFiles is not defined".

Your second idea:
I see
nineteen zeroes,
five times the number 31 and
one time the number 27

Hope this helps...

[PVince81]

@icewind1991 if I remember well the permissions should have fixed themselves the first time these folders are accessed again ?

@cyberpunklynx for the JS web console you need to be in the files app (not admin page or somewhere else).

[cyberpunklynx]

@PVince81 Okay, I was able to reach /apps/files from /admin/settings. But the message stays the same: "ReferenceError: scanFiles is not defined". Such sad.

[PVince81]

@cyberpunklynx did you actually switch back to OC 7 ?

Is it in OC 7 that you could not reach the files app at all or OC 6 ?
The downgrade itself will not be possible because the DB schema has changed, so there's nothing we can do there.

The only way now is switch to OC 7 and try and find out what's wrong with the permissions.

[cyberpunklynx]

@PVince81 So OC 6 is dead for me? Nothing we can do here?

What would be the best way to switch to OC 7 without harming more? Running the updater again, doing the update manually via the download archive or something completely different?

[PVince81]

Yes, OC 6 is dead because we can't restore the DB without a backup, sorry.

To switch back to OC7, do the following:

1. Download the 7.0.1 archive
2. Inside your ownCloud folder, remove everything EXCEPT the "config" and "data" folders
3. Extract the archive there
4. Make sure to put back the "config" and "data" folders (if you moved them away)
5. Open ownCloud, click "Start upgrade"

Do you have lots of files ? Lots of shared files ?

I'd recommend you to wait for 7.0.2 to be out some time this week as it fixes some issues from 7.0.1.

[cyberpunklynx]

Okay, so you definitely don't recommend an update via the updater. Got that.

I got about 3GB of files and maybe 10 files which are shared.

I'll wait for 7.0.2 and do as you mentioned.

Thanks.

[VicDeo]

A few theses:

• http://doc.owncloud.org/server/6.0/admin_manual/maintenance/update.html (Note in blue at the top)
• we did not support a downgrade on the core level currently. DB can't be updated by core to the previous version, but only to the next one;
• DB backup is not done by updater currently. Updater does a file snapshot used for reverting the instance in case of emergency (and keeping user-specific files occasionally left somewhere) only. This task is not straightforward and time consuming due to various DB backends;
• and a link to Differentiate update candidates by version appstore-issues#4 once again.

Thanks for hints.

[cyberpunklynx]

@VicDeo How to update OC when using a shared server is not listed there. You only explain the internal updater as well as doing an update via the command line; which is only available when you installed OC on your own server and have access to a shell

For the second comment, I never read that and it just was an idea of mine. I know systems, e.g. WordPress, where it's automatically detected if you are using an old version and alter the database accordingly. Due to the fact that OC uses only about 18MB or so for the database (at least in my case) that shouldn't be too big of a problem

If the updater doesn't save a backup with at least some information about the database, why is there this backup function at all? I don't get it, it didn't work as you can see in my specific case. This is utterly useless

I fully support what you wrote in your post at the end. Looking forward to see this implemented

Regards

[VicDeo]

@cyberpunklynx

If the updater doesn't save a backup with at least some information about the database, why is there this backup function at all? I don't get it, it didn't work as you can see in my specific case. This is utterly useless

Backup is used currently:
a. to revert the system into the initial state in case something really bad happened while moving the files
b. to keep core files (since users do changes inplace sometimes) and incompatible apps which are auto removed (From the core standpoint disable = remove for any 3rdparty app)

[RobinMcCorkell]

Closing due to inactivity. Sorry about your database @cyberpunklynx 😞