HowTo: Change / Move data directory after installation

📑 How to
,
10

Semi noob here-

  1. Would having Nginx vs apache change any of the guide for method #2?

  2. Does having NC 13.05 affect anything as well?

11

@Dove7

  1. Looks like you just leave out the apache-specific configuration parts, and nginx does the expected thing automatically.
  2. Nothing new in 13.05 should change method #2. :slight_smile:
13

Perhaps the snap setup inhibits symlinks, not sure.
I guess its bundled with Apache webserver? Is there a way to configure the webserver?

€: Jep Apache with symlinks explicitly enabled just for the htdocs folder: https://github.com/nextcloud/nextcloud-snap/blob/master/src/apache/conf/httpd.conf
Not sure about defaults on this Apache version but this might be the reason it does not work.

14

move data where you want and
make changes in
path/config/config.php

$CONFIG = array (
	***
	***
	***
	'datadirectory' => '/var/ncdata/data', //new path of data directory
	***
	***
	***
);

maybe this helps.

1 Like
15

Jep during all tests this worked at least since NC13. The needed database entry is created automatically, so no manual mysql step seems to be needed.

However before editing to guide above I am hoping for an official statement, since @nickvergessen still mentioned to database update ;). I guess on older NC versions it is indeed still needed, so would be good to know when this was changed.

Anyway the database update does not hurt and is even cleaner since no obsolete entry remains.

16

You won’t hear anything different ever from me. Not updating the existing record but automatically creating a new one leaves the database in an inconsistent state and could lead to problems in the future.

2 Likes
17

Thanks for the clear statement. I will follow it and won’t change the guide.

18

Hi there, and first thank you all for these precious information.

I figured out the solution to my problem while writting but still, I spent way more time than I would have wanted on this so : To anyone it may help ^^

With Nextcloud 14.0.3, I when performing the update on the database :
> update oc_storages set id=‘local::/new/path/to/data/’ where id=‘local::/path/to/data/’:wink:

I got the following error :
“ERROR 1062 (23000): Duplicate entry ‘local::/nas/data/’ for key ‘storages_id_index’”

I looked throuh the database using phpmyadmin I found that it probably came from the fact that a line was created automatically with value “local::/nas/data/” even before I executed the following line from the tutorial :

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

So I was trying to create the line a second time, basically duplicating it. This is probably because Nextcloud detects that the path in the config.php is not the same as the one in the db, and so it automatically generates a new line with the right path.

Actually, everything works fine with this automatically generated line and so the update of the path on the database seems to become quite obsolete now.

However, if you want to make your installation totally clean and remove the line with the old path, what you have to do is just go fast and :

  • delete the line with the new path (last line in oc_storages)
  • quickly update the old path into the new one before a line with the old path is generated.

(I did this from phpmyadmin so I don’t know the commands)

1 Like
19

Thanks for the info, even that you managed to resolve yourself.

Did you put Nextcloud into maintenance before doing the change in config.php, according to the guide?
Would be very strange that Nextcloud automatically adjusts the database entry when in maintenance mode :thinking:.

That the database entry is added automatically is known if you follow the discussion above. It does work without adding it manually, currently, but according to Nick’s statement above and for consistency it makes sense to replace/remove the old obsolete entry from database. So I didn’t change the guide.

But if somehow Nextcloud adds the entry, even if in maintenance, then this needs rework. Properly do a check first and add only if not already contained, or simply remove the old entry and rely on Nextcloud to add the new one automatically. Not sure which is the safest/failsafe solution with minimal manual user steps/checks required.

20

I confirm the same behaviour with Nextcloud 14.0.3 (Maintenance mode : On)

21

So again to assure:

  • You put Nextcloud into maintenance, did the data dir moving.
  • You did update oc_storages set id='local::/new/path/to/data/' where id='local::/path/to/data/'; within MySQL console.
  • Then you disabled maintenance mode and the local::/path/to/data/ database entry was doubled then, so Nextcloud UI refuses to open, or already occ maintenance:mode --off failed?

Will test/verify as well tomorrow. Very strange in case. Then instead of replacing the old entry, it should be removed only.

23

Is it safe to remove old entries in oc_storage table that refer to old, unused local storages? I seem to still have an old storage back from owncloud, and very old one from nextlcoud (changed mountpoints years back).

24

Should work fine, did this on my machine as well some time ago. However do a mysqldump first, just to be sure.

25

I followed solution 2 and it works fine. But, subsequently I’ve tried to install ElasticSearch full text search in my NC accordingly to this manual. But this ends up not in a working full text search but in:

pi@raspberrypi:~ $ sudo service elasticsearch start

pi@raspberrypi:~ $ sudo service elasticsearch status

● elasticsearch.service – LSB: Starts elasticsearch

Loaded: loaded (/etc/init.d/elasticsearch; generated; vendor preset: enabled)

Active: active (exited) since Wed 2019-04-24 13:07:26 BST; 40s ago

Docs: man:systemd-sysv-generator(8)

Process: 556 ExecStart=/etc/init.d/elasticsearch start (code=exited, status=0/SUCCESS)

CGroup: /system.slice/elasticsearch.service

Apr 24 13:07:26 raspberrypi systemd[1]: Starting LSB: Starts elasticsearch…

Apr 24 13:07:26 raspberrypi systemd[1]: Started LSB: Starts elasticsearch.

pi@raspberrypi:~ $ sudo -u www-data php /home/pi/usbdrive/html/occ fulltextsearch:index

In Index.php line 380:

failed platform test.

fulltextsearch:index [–output [OUTPUT]] [-r|–no-readline] [–] []

What am I wrong?

26

Please verify if elasticsearch follows symlinks by default or not. Just a guess in the blue, since this is the basic change that comes with solution 2 :wink:.

27

Hi, in the next days I will need to add a new disk to my server and with this will change my filesystem. After this my nextcloud_data folder (only this since the nextcloud system files are on a different drive) will have a new path. I read that changing the path is not recommended. Since all files in my nextcloud instance are synced to clients and I don’t need the previous version etc. I wonder if there is a way to reset (empty) the nextcloud data folder without the need to reinstall nextcloud? Meaning that for all users the folder is empty and filled with the data from the clients at the first sync. Similar to the first sync after a new installation.

28

You don’t run it on DietPi, do you? In case moving the dietpi_userdata with nextcloud_data inside can be done without any changes to Nextcloud.

However otherwise changing/moving your Nextcloud data dir via solution 1 (of this HowTo) requires an adjustment of the database in every case, with or without clearing the data. In fact clearing the data just means additional steps and risk. So no benefit/point in doing this IMO, only the risk that clients pull file removals instead of pushing them to server.

Whatever you do, do a full backup of your Nextcloud install dir and database. And cp -a/rsync the data (preserving timestamps) instead of moving them, so you have a backup in case any issue, corruption I/O error or such happens. And block/disconnect the server from clients access until you verified (e.g. accessing to web UI locally) that everything went well, before re-opening for client access.

1 Like
29

Isn’t it a better solution to mount the new storage in your nextcloud folder directly?

I have nextcloud/data as one mount and /nextcloud/data/appdata_oc56k88881p0f/preview as another. Works great and it makes it easier to backup nc and user data.

30

The whole idea of having it outside the Nextcloud install dir is the security aspect to have it outside of the webserver document root. And the effort for moving/backing up is nearly the same. I mean if you copy/sync one or two directories does not really make a difference, does not?

But generally moving data by mounting it to the old location is actually a “solution 3” as alternative to the symlink method. However I personally prefer to have the least amount of links/mounts/redirects possible to keep things simple and avoid unexpected surprises and such. So I always go with “solution 1” and tell Nextcloud directly where the final location is, in case of a mount inside /mnt. But that’s as well about personal taste and needs.

31

Ok, thanks. Then I will try solution 1. A backup of my data is available. Worst case means at the end reinstall nextcloud on the server.

How can I check afterwards that everything went fine. Is it sufficient to simple open some files in the WebUI or is there any better check/test?