HowTo: Change / Move data directory after installation

📑 How to
,
6

I moved it twice already, always changed config.php and UPDATED the oc_storages entry.

Never had a problem so far.

1 Like
7

@MorrisJobke @nickvergessen
Okay, this underlines the “known” procedure in OT, but what about the oc_storages entry being added automatically? As mentioned within discussion, scooter and me could successfully change the datadirectory without adjusting oc_storages (my short steps list above). Even comments and flags, thus stuff that especially relies on file IDs, is preserved.

9

Under 13.1, oc_storages gets the correct update automatically. I never tried prior versions, so I can’t say for sure. It seems that prior versions did not update automatically and required manual entries/adjustments to oc_storages.

It also seems that, after updating config.php while in maintenance mode, then exiting maintenance mode, a check is done between the datadirectory entry and oc_storages to see if the path is already in the table and if not, it adds it, PLUS it also checks fstab to see if the directory is mounted at startup. If not, an error message is given when exiting maintenance mode saying that the datadirectory entry is invalid.

Here are the tests I performed:

TEST 1
Maintenance mode on
Edit config.php (add new datadirectory entry)
Edit fstab (enter new drive / mount point)
Check oc_storages (no new entries)
Maintenance mode off (no error message)
Check oc_storages (new entry aded for “local::” using datadirectory path from config.php)
Exit mysql
Exit root
Test in browser (login successful, files & folders present)

TEST 2
Maintenance mode on
Edit config.php (restore original datadirectory entry)
Edit fstab (restore previous drive / mount point)
Maintenance mode off (no error message)
Exit root
Test in browser (login successful, files & folders present)
Check oc_storages (no changes since previous check; two entries for “local::”)

I did numerous other tests before determining that this order produced no errors. In retrospect, it’s probably better to update fstab before config.php, but as long as both are done while in mainteance mode, it doesn’t seem to matter.

1 Like
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