HowTo: Change / Move data directory after installation

If you can see your files and can write to them (or create new ones) then this should be sufficient as check.

A reinstall should never be required as long as you have your e.g. /var/www/nextcloud (or where you installed it) and the database dump (as mentioned/created through the HowTos steps) you can always revert to the previous stage. PHP, webserver, Redis server (in case you use it) and all this are not affected.

Hi @MichaIng,
Thank you very much for this thread! Very helpful :slight_smile:

After all the answers, I am a little bit lost regarding the actual operations to be done to move data directory (as there have been updates since, some of the commands are no longer required).
I have a “Tech and Me” Nextcloud VM. I understand that, even if Solution 1 is a little bit more risky, it’s the one you recommend (mainly for security reasons). Then, can I use Solution 1, described in the first post for the “Tech and Me” Nextcloud VM? or should I change / add / avoid some commands?

Thank you so much again!

Hey guys,

Just found this article:

If you are looking to add some more space on data directory on your Nextcloud “Tech and Me” VM, why not just add a new disk on the ZFS pool?

Jep exactly, the official VM already has the data dir located on a separate ZFS partition, thus there is really no need to change anything about this and it might even break the VM UI elements.

If required, one could either raise the drives size + ZFS partition or add a new drive to the ZFS pool as you mentioned. However AFAIK there is usually no need to make things more complicated with a second data drive, the VM platform should allow to increase the size of existing drives, if required? At least on VirtualBox and VMware this works quite well.

I added the hint to the initial post besides Snap/Docker/NCP appliances hint, many thanks for reporting! :slightly_smiling_face:.

1 Like

Please keep in mind after move your data folder - Files amount after moving of data directory is wrong (much bigger).

But also note that when following Solution 1, the doubled entry is avoided by this step:

update oc_storages set id='local::/new/path/to/data/' where id='local::/path/to/data/';

But aside from that obviously, having a look into this database table generally makes sense from time to time, when heavily changing data dir and/or external storages.

1 Like

hey I have try your tutorial but i have some probleme. First I don’t find the occ folder in my server second when i enter the first command the console display “php:comand not found”
(I have install nextcloud on the ubuntu server setup)

occ is not a folder, but a file, located in the root of your Nextcloud install dir, e.g. /var/www/nextcloud/occ.

Is the error message from php that it does not find the occ command, or is the php command itself not found (which seems to be the case based on error message)?
Please check which php if it gives any output. Assure that you have php-cli installed (which ships the command).

Which OS do you use? Sometimes the command is shipped with PHP version string inside, e.g. php7.3. It should be located in /usr/bin/ or /usr/local/bin/ depending on your install method. Or you run some system-wise search: find / -type f,l -name php


Is there also a step by step guide for Apache/PostgreSQL? Thanks!

Solution 2 works with postgres just the same way. Solution 1 should as well, since the SQL syntax is the same, AFAIK. Besides of course there is another command than mysqldump to create a database backup. pgsqldump? :wink:

Got it: Nextcloud Daten-Ordner verschieben (Apache, PostgreSQL)

Are these instructions still up to date for NC17 and NC18?
When looking at the official instructions on how to migrate to a different server (e.g.,, that page states about potential path changes:
“On the new system make sure to pick the appropriate locations. If you change any paths, make sure to adopt the paths in the Nextcloud config.php file”
However, it does not mention that the database needs to be adjusted. I would have assumed that I had to follow the steps mentioned for “Solution 1” in that case as well.

To me it feels like either this howto is outdated or the manual is incomplete. Thus, can someone provide an update on this issue and either
a) update this howto article with details for current NC versions (16-18) or
b) stimulate an update for the manual page mentioned above.

The methods here are still valid. Please see the discussion, where it is mentioned that editing the database entry is indeed not required (as far as it was tested). But see this post of nickvergessen that it is still the recommended way to keep the database entries clean and consistent.

Indeed your statement (hence this HowTo) and Nextcloud docs do not match here. If altering the database on data dir transfer is recommended, then this should be just the same when migrating a Nextcloud instance to a different server and having a different data dir path there. But a definit solution to rule out any issues would be if Nextcloud altered the database automatically according to config.txt entry, to have a single matching entry for local data dir only.

@MichaIng I assume you mean config.php?

The config.php entry must be changed. If Nextcloud finds no matching database entry, it creates an additional one, which then works fine according to quick tests and user reports above. But to be sure and not mess up the database with obsolete entries it is recommended to replace the old entry with the new one manually as mentioned in solution 1.

Well the question is which storage to update. Sure I guess hacking could take place to achieve that, but I’d like to rather not do this.

The data dir entry/entries should be identifyable, although I know there are “local::” entries as well for every user. I’ll dig into it by times to check for safe ways to identify the correct entries. Basically of config.php does not contain a matching entry, Nextcloud could remove all obsolete ones before adding the correct new one.

Hi All, I am a newbie here and really appreciate this thriving community. I have Rpi 4 with 2gb and 2 5TB HDD on RAID 1. My challenge was that I couldn’t get NCPi to target to RAID as I was doing a fresh install and RAID was built “after” NCPi was installed. Hence, intense search on changing Data after install.

I was going to go for the easy method but read the warning from @nickvergessen on DB integrity topic and decided against it.

I followed all the steps for Solution 1 from @MichaIng and it went well. I am able to navigate NCPi and all features… at least till now.

The only problem that I faced was to understand how “oc_storages” DB table can be edited. I have no clue on DBs so this was a challenge. After searching forever (3 days), I stumbled upon phpMyadmin, installed it and used the user and password from config file… lo behold, I was able to edit the DB. I am very impressed with this forum! Great work, all!

1 Like

Although phpMyAdmin provides a nice GUI, it is not required to alter the database. The mysql command line tool can be used from any shell/terminal/emulator/SSH, according to the HowTo:

mysql -u<rootuser> -p
# enter mysql root password, then within mysql console:
use <nextclouddb>;
update oc_storages set id='local::/new/path/to/data/' where id='local::/path/to/data/'; //take care about backslash at the end of path!!

Usually <rootuser> is “root”, with MariaDB on modern Debian at least the -p option must or can be omitted when you logged in as root UNIX user. You could also use the Nextcloud database user, where /path/to/nextcloud/config/config.php provides its name and password.

Actually using Nextcloud database user is the much better way, since it has only permissions to alter the Nextcloud database and no other, hence one cannot by accident break something within other databases. Something I’ll edit in the HowTo another day :thinking:.

Thanks a lot, @MichaIng for the clarification. This is really helpful. I am just scared to make changes in places where I have very little or no experience. Hence for me, phpMyAdmin was a boon.
But I get your point. Will try CLI the next time I need it… hopefully never, as I am still scared. :grimacing: