Upgrade Owncloud 9.0x to 9.1 in Synology NAS running DSM6

This is detailed guide for upgrading Owncloud 9.0x to Owncloud 9.1 in Synology NAS devices running DSM 6. Owncloud 9.1 has been just recently published, and I wanted to share my procedure for updating Owncloud. This process should be fine for minor, point or major version upgrades of Owncloud also going forward, unless big changes are introduced how Owncloud is operating.

Before starting to go through the steps, I want to emphasize that every system is different, and there may be aspects that you need to do and consider that I am not covering here. But hopefully I am able to provide enough information for you to understand the steps needed to consider on your side. So please do understand that this is not by any means a definitive guide for your upgrade process. But as I have received many questions in many contexts about the update and how to use the occ comands in command line in Synology NAS – I decided to share my process to you. My process might seem too thorough and detailed, but I personally like to be cautious in upgrading production systems.

Also please consider reading thoroughly the Owncloud 9 documentation section about updating Owncloud. As there are multiple options for doing the upgrade, mainly these:

Package upgrade

This is not an option for Synology, as there are no packages we could use in synocommunity.

Updater app upgrade

In practice we have here the same steps as in Manual upgrade, the difference is that the app is trying to automate the steps needed.

Manual upgrade

This is my favorite, and my choice for updating Owncloud instance. You are in control of every step of the process.

The following pieces of text are from Owncloud 9 documentation to highlight the importance:

It is best to keep your ownCloud server upgraded regularly, and to install all point releases and major releases without skipping any of them, as skipping releases increases the risk of errors. Major releases are 8.0, 8.1, 8.2, and 9.0. Point releases are intermediate releases for each major release. For example, 8.0.9 and 8.1.3 are point releases. Skipping major releases is not supported.

Upgrading is disruptive. Your ownCloud server will be put into maintenance mode, so your users will be locked out until the upgrade is completed. Large installations may take several hours to complete the upgrade.

You should always maintain regular backups and make a fresh backup before every upgrade.

Then review third-party apps, if you have any, for compatibility with the new ownCloud release. Any apps that are not developed by ownCloud show a 3rd party designation. Install unsupported apps at your own risk. Then, before the upgrade, all 3rd party apps must be disabled. After the upgrade is complete you may re-enable them.

Upgrade Quickguide

Disable all third-party apps.

Make a fresh backup.

Upgrade your ownCloud (core files).

Run occ upgrade(optionally disabling the migration test).

Apply strong permissions to your ownCloud directories.

Take your ownCloud server out of maintenance mode.

Re-enable third-party apps.

Ok – let’s start the upgrade process. You can follow to whole guide exactly as I do it, or pick up parts and pieces as you see fit for your own process.

1)

Login into your Owncloud instance as administrator, and disable all non-official 3rd party apps you might have installed and enabled. Non-official apps do not have the tag ‘Official’.

2)

List down for later purposes all the directories/paths where you have something you need or want to preserve in the upgrade.

You also need to think are there any other modifications that you have made, that you possibly need to re-do after upgrade. I know that I have modified the owncloud .htaccess file for doing the permanent re-direction from http to https. So I will record that to my to-do list as well. After your first upgrade you should have all this listing ready, and this will not be a big hassle at that point anymore. You should also keep this list up-to-date, in case you do some other direct changes to Owncloud core files.

3)

Put your Owncloud instance into maintenance mode. This prevents new logins, locks the sessions of logged-in users, and displays a status screen so users know what is happening. There are two ways to do this, and the preferred method is to use the occ command, which you must run as your HTTP user. Here is how you run that in Synology DSM:

(Note: In Synology DSM we actually need to use ‘php56’ instead of ‘php’ in the occ console commands for Owncloud.)

This is what your users should see once maintenance mode is enabled.

4)

Let’s modify the Owncloud web folder permissions, to ensure that we don’t ran into issues during our upgrade process. I won’t do any modifications to Owncloud data folder, as no changes are required there. This is valid only if you have setup your data folder outside Owncloud web folder (and you followed my guide for installing Owncloud 9 to your Synology NAS).

In similar manner you need to bring any special 3rd party apps you might have installed, from the old apps folder to the new apps folder.

At this point you also need to make the additional modifications (if any) you have made to the original Owncloud core files, like .htaccess or similar.

9)

Now after all above steps – you should have done all the preparations. Let’s re-start the Synology Web Service:

10)

Now we need to start the upgrade process from command line with following commands:

1
2

cd /volume1/web/owncloud
sudo -u http php56 occ upgrade

The upgrade operation takes a few minutes to a few hours, depending on the size of your installation. When it is finished you will see a success message, or an error message that will tell where it went wrong.

If you see the error “There were problems with the code integrity check” – this is most likely because Synology creates @eadir cache folders everywhere. Removing these manually from Owncloud folders will remove the error. In this job you might find this code useful:

1

find . -name "@eaDir" -type d -print0 | xargs -0 rm -rf

And here is example on how to use it:

And you have now removed all ‘@eaDir’ folders from owncloud folders. And you should also be able to remove the error by Selecting ‘RESCAN’ on admin page of Owncloud.

15)

Enable and test functionality for any 3rd party apps you possible had installed.

16)

If everything seems to work correct and files seem okay – it is time to assign more strict permissions back:

Please regard the given script as example only – always validate security permissions for your needs as required – and review related documentation from Owncloud.org for version 9.

And I’m running it in SSH terminal like this (run it as root as it “can be done in DSM 6″ and from root folder in SSH terminal):

Congratulations – you should have now successfully upgraded your Owncloud version!

Note: The renamed copy of the old Owncloud version should be removed away from web folder / assigned extremely strict permissions right after upgrade, and once you are confident the new updated Owncloud is working – you could delete the whole instance. After all, you still have the full & fresh back-up stored.

If this worked for you – please let me know by leaving a post / feedback below!

Thanks – and take care!

Feedback

Juha Ketola

Author is a passionate IT enthusiast and early adopter. Packed with years of experience leading Enterprise level IT development teams within the biggest companies of Technology industry. Watches closely start-ups and new disruptive innovations in order to stay on the cutting edge. Embraces hands-on IT development and IoT.

The permissions are always something that user should really focus and use some time to get the optimal setup for his/her case. That is why I have used here the recommendation from Owncloud documentation for setting Strong Directory Permissions – and not really dug deeper on that area.

first of all: thanks for your amazing tutorials! I successfully installed ownCloud 9 and upgraded to 9.1 with your guide.

But coming now to my problem: I upgraded yesterday to v9.1.3. Unfortunately, my ownCloud logs show reoccurring PHP errors: “PHP Startup: No such handler: DBA_DEFAULT at Unknown#0”. I did not find anything about that anywhere else.
Most interesting: Everything runs fine. All clients sync smoothly, the web interface runs correctly, … Do you have an idea where this error comes from? I could think of a problem with PHP communicating with MariaDB, but actually everything works fine.

Hi Juha & Matthias
Great tutorial that helps a lot for installing and upgrading Owncloud on the Synology NAS.
A BIG THANK YOU FOR THAT!
I do get now the same message as Matthias. I saw somewhere that it occured when different PHP versions are installed and the wrong one is called about. But I do actually only have one installed…
Any help?
KR
scherom

There is a mistake in the .htaccess template… Maybe its a simple incompatibility with Synology’s software combination. But anyway – it’s working now!
Took me nearly half an hour to find that information!
Hope it helps someone. 🙂