Migrating from ownCloud to Nextcloud

That is ABSOLUTELY what we want to enable - even recommend. We’re totally confident that half a year from now, things will be entirely clear. Perhaps sooner, even. So sit back, watch, we will take care of providing a clean migration path for sure.

From a security point of view, well, @LukasReschke works for us so if you’re very security conscious I can recommend to move to Nextcloud, same with if you need the features. But we will report security issues back upstream, anything else would be very uncool, so while they might be slower to release you won’t be super insecure. If you don’t care too much about either of these then stay put and we can help you migrate later. No worries.

Upgraded from OC 9 running on CentOS 7 with the following steps and zero issues ( I am using apache instead of nginx, but change what would be needed for nginx if needed.

download the zip file and unzip it into your www location of wherever apache nginx is looking at
copy over owncloud/data and owncloud/config to the nextcloud directory.
run the upgrade "sudo -u apache php occ upgrade"
run a chown -R apache:apache on the nextcloud directory
configure apache nginx to point to your nextcloud directory instead of the owncloud one

Not needed but if you use the news application then you need to go to php5.6
assume you already have php 5.5 this step could be not needed
rpm -Uvh https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm
rpm -Uvh https://mirror.webtatic.com/yum/el7/webtatic-release.rpm

yum install yum-plugin-replace

yum replace php55w-common --replace-with=php56w-common

Start apache back up
systemctl restart httpd


1 Like

In case it helps others, here are my notes from manually migrating my server from ownCloud 9.0.2 to Nextcloud 9.0.50. Follow this at your own risk and keep in mind these commands are specific to my environment, install locations, etc. so adjust for your setup accordingly. I also recommend testing/reviewing backups before upgrading to make sure your data is safe and you have a way to recover.

I’ve got a manual install on a LEMP stack. My setup consists of:

  • Ubuntu 16.04 LTS
  • NGINX 1.11.1
  • PHP 7.0.4-7ubuntu2.1 (cli) ( NTS )
  • MariaDB 10.1.13

Backup Everything

Reference: https://doc.owncloud.org/server/9.0/admin_manual/maintenance/backup.html

Enable Maintenance Mode

sudo -u www-data php /var/www/html/cloud.lan/occ maintenance:mode --on

Backup Folders

mkdir -p ~/Documents/backup/

sudo rsync -Aax /var/www/html/cloud.lan ~/Documents/backup/owncloud-web-dirbkp_`date +"%Y%m%d"`/
sudo rsync -Aax /var/oc_data/ ~/Documents/backup/owncloud-oc_data-dirbkp_`date +"%Y%m%d"`/

Backup Database

mysqldump --lock-tables -u vance -p owncloud > ~/Documents/backup/owncloud-sqlbkp_date +"%Y%m%d".bak

Download & Verify Source of New Release

sudo curl -L https://download.nextcloud.com/server/releases/nextcloud-9.0.50.tar.bz2 -o /usr/local/src/nextcloud-9.0.50.tar.bz2

sudo curl -L https://download.nextcloud.com/server/releases/nextcloud-9.0.50.tar.bz2.sha256 -o /usr/local/src/nextcloud-9.0.50.tar.bz2.sha256

cat /usr/local/src/nextcloud-9.0.50.tar.bz2.sha256

echo "6c067d01416462dffb80862468a3f1b43307e48b9f8f023d544875dfa5db2ddf /usr/local/src/nextcloud-9.0.50.tar.bz2" | sha256sum -c -

sudo curl -L https://download.nextcloud.com/server/releases/nextcloud-9.0.50.tar.bz2.asc -o /usr/local/src/nextcloud-9.0.50.tar.bz2.asc

curl -L https://nextcloud.com/nextcloud.asc -o nextcloud.asc

gpg --import nextcloud.asc

rm nextcloud.asc

gpg --verify /usr/local/src/nextcloud-9.0.50.tar.bz2.asc /usr/local/src/nextcloud-9.0.50.tar.bz2

Start Installation


cd /usr/local/src/

sudo tar -xjf /usr/local/src/nextcloud-9.0.50.tar.bz2

Stop Web Server

sudo kill -QUIT $( cat /var/run/nginx.pid )

Rename old ownCloud directory

sudo mv /var/www/html/cloud.lan /var/www/html/cloud.lan.old

Move new source code into place

sudo cp -r /usr/local/src/nextcloud /var/www/html/cloud.lan

Restore old config

sudo cp /var/www/html/cloud.lan.old/config/config.php /var/www/html/cloud.lan/config/config.php

If you keep your data/ directory in your owncloud/ directory, copy it from your old version of ownCloud to your new owncloud/. If you keep it outside of owncloud/ then you don’t have to do anything with it, because its location is configured in your original config.php, and none of the upgrade steps touch it.

If you are using 3rd party applications, look in your new owncloud/apps/ directory to see if they are there. If not, copy them from your old apps/ directory to your new one. Make sure the directory permissions of your third party application directories are the same as for the other ones.

Restart NGINX

sudo nginx

Resolve permissions

sudo chown --recursive www-data:www-data /var/www/html/cloud.lan

Start upgrade
sudo -u www-data php /var/www/html/cloud.lan/occ upgrade

I encountered an error about “PHP module mb multibyte not installed.”
sudo apt-get update && sudo apt-get install php7.0-mbstring

Re-start upgrade

sudo -u www-data php /var/www/html/cloud.lan/occ upgrade

Secure permissions

cd /usr/local/bin

sudo cp set-owncloud-permissions.sh set-nextcloud-permissions.sh

Reference: https://docs.nextcloud.org/server/9/admin_manual/installation/installation_wizard.html#strong-perms-label for ideas on how to write a permissions setting script. Mine is below:


printf "Creating possible missing Directories\n"
mkdir -p $ocdata
mkdir -p $ocpath/assets

printf "chmod Files and Directories\n"
find ${ocpath}/ -type f -print0 | xargs -0 chmod 0640
find ${ocpath}/ -type d -print0 | xargs -0 chmod 0750
find ${ocdata}/ -type f -print0 | xargs -0 chmod 0640
find ${ocdata}/ -type d -print0 | xargs -0 chmod 0750

printf "chown Directories\n"
chown -R ${rootuser}:${htgroup} ${ocpath}/
chown -R ${htuser}:${htgroup} ${ocpath}/apps/
chown -R ${htuser}:${htgroup} ${ocpath}/config/
chown -R ${htuser}:${htgroup} ${ocdata}/
chown -R ${htuser}:${htgroup} ${ocpath}/themes/
chown -R ${htuser}:${htgroup} ${ocpath}/assets/

chmod +x ${ocpath}/occ

printf "chmod/chown .htaccess\n"
if [ -f ${ocpath}/.htaccess ]
  chmod 0644 ${ocpath}/.htaccess
  chown ${rootuser}:${htgroup} ${ocpath}/.htaccess
if [ -f ${ocdata}/.htaccess ]
  chmod 0644 ${ocdata}/.htaccess
  chown ${rootuser}:${htgroup} ${ocdata}/.htaccess

sudo ./set-nextcloud-permissions.sh

Disable Maintenance Mode

sudo -u www-data php /var/www/html/cloud.lan/occ maintenance:mode --off

Login as Admin and Check for warnings. If all is good, feel free to clean up downloads, etc.


That is awesome. Now I feel my blog I just published isn’t half as good as it should be…

I will update it to point to this awesome post!

1 Like

Can you elaborate what the problem with distribution packages was/is?
I’ve previously used the packages from here for Debian 7/8 and Ubuntu and it generally worked very well.

Distributions picking up nextcloud wouldn’t get you any up to date software anyway (at least not in the Debain/Ubuntu case).
Archlinux already has a PKGBUILD in the AUR. Hope it gets promoted to community at some time.

Maybe some Gentoo Linux users are reading here too, so I just want to point to the ebuild (and migration hints) for Gentoo Linux I just offered.

The corresponding bug with the ebuild is here.



Thanks mvance and Jos Poortvliet, the transition from owncloud 9.0.2 to Nextcloud was easy thanks to your instructions! I want to also mention that if you changed the installation path (I changed from /var/www/owncloud to /var/www/nextcloud) then cron will need to be updated to point to the new location as well.

1 Like

That’s a real bummer. Guess I have to stay with ownCloud for now to get easy and up-to-date updates.

Here is my experience with the upgrade process:

Luckily, the system on which my OwnCloud is running, is a Raspberry, so it was pretty easy to do a full back up of the entire system before trying to upgrade. And I really needed that back up!

After I started the upgrade process as shown above, NextCould was producing tons of errors. After two more tries, each time using a fresh copy of the SD card, I gave up and decided to do an installation from scratch.

I unzipped NC to /var/www/nextcloud/, copied OwnCloud’s nginx configuration (sites-available) to a configuration file for NextCloud, changed the paths accordingly, created a new MySQL data base and let NC to it’s magic. Then I logged into NC, created the user accounts, and activated the necessary apps. After NC was up and running, I logged into the old OwnCloud, downloaded my contacts and calendars and imported them back into NextCloud. After that was done, I re-changed nginx’s configuration, so that to each synchronizing client (Android, Thunderbird, file synchronizing clients) would never notice that OwnCloud was replaced by NextCloud.

That hole procedure took me about half an hour and went pretty smoothly, while the misfired upgrade processes before took me half an hour each!

So, my recommendation to any one who is not working in an productive environment with more than 2 or 3 users, would certainly be to do a fresh installation. No offence meant, but I really think that the upgrade scripts do need medical care. This has been an issue with OwnCloud for a long time, because if you search the net you will find lots of people who had lots of problems with that before.

[quote=“John, post:17, topic:551”]When they finally learn that NC is the better choice for them (which, of course, they will undoubtly do :stuck_out_tongue: ), easy migration is still at hand.[/quote]In my opinion if “better choice” is the goal, then deb packages for Debian and Ubuntu need to be available.


Amen - but this time, I am hoping Debian/Ubuntu provide them as they our packaging efforts were a PITA in the past.


I’d like to have an “offical” statement if renaming /var/www/owncloud/ to /var/www/nextcloud

realy won’t lead to issues, as mentioned in this thread:


I did this, changing my install directory name to /var/www/nextcloud. The only issue that I had was my background task cron job was now trying to execute a file in the old directory. Once this was updated all went smoothly.

The upgrade went very well. I used the manual upgrade process from ownCloud 9.1 (deleting the specified owncloud files on my shared hosting and replacing them with the nextCloud files). I just needed to disable the maintenance mode before I could proceed with the web update. I have one question:

I have a tagspaces folder in my nextCloud folder that is currently failing the code integrity check: > There were problems with the code integrity check.
Is there a way to disable this check for the files in this folder?

It worked flawlessly for me as well.

But Contacts and Calendar still have to be enabled manually.
I really hope these will become first class citizens, as promised.

This has been a cumbersome thing from the beginning: upgrading and reenabling these two for each upgrade & release have driven me mad. I feel I have never had a simple, direct, upgrade process with owncloud.

Only solution should be to move this folder out of your nextcloudinstallation…

-> Dokumentation


Unless the packages were configured in rather stark violation of how Debian packages are supposed to be set up, an uninstall shouldn’t be deleting any configuration files (only a purge should).

This is one of the nice things about proper package management, it makes things simple without any “gotchas” for the users. I’m quite disappointed that you’re ditching the repo, it’s a major step backwards in user-friendliness, frankly (and the only thing you folks have done so far that isn’t quite reassuring and laudable).


After the migration is my app Gallery missing. I can’t found the app anymore.

I have my owncloud installation in the root of the webserver and since it is already linked to a subdomain from another hosting provider I am not sure how to change this. Is there something the tagspaces https://github.com/tagspaces/tagspaces dev can do to the files so they are for example recognized as a (special) app of nextcloud?

Just my 2 cents. At least for me the absence of supported Ubuntu/Debian packages means that Nextcloud is not a drop-in replacement for the other one. Integrating yet another new mechanism in my server admin processes is time-prohibiting for the time being.