HowTo: Change / Move data directory after installation

📑 How to
,
146

I do not get why people all over the place mix two commands which do the same thing :smile:. Use:

sudo -s

Do not use su, unless you know that you must use it for some reason. It is dangerous as it does not start with a fresh environment by default, and is not logged transparently like a sudo session.

To avoid the need to manually create these dot files (and the new data dir itself), and avoid unintentionally missing other dot files, my howto uses

cp -a /path/to/data/. /new/path/to/data

Note the . instead of *, so it copies the directory itself (recursively), instead of its content, with the wildcard that does not match dot files.

Uff, every user now has full write access to your Nextcloud data’s parent directory. Do not do that! Every user can now create a .htaccess in this directory, and Apache respect those on every parent directory. That way really everything can be exposed easily to the public. Never create a 777 dir anywhere on the system. I really do not know a single use case for this. Always use the users these dirs shall finally be owned to, max 775 when selected multiple users require write access. In this particular case, I’d clearly leave it as default 755 and owned by root user, like all parent dirs of Nextcloud data, for security reasons.

The owner of symlinks is irrelevant, as it has 777 mode by default, which does not matter either since the target directory permissions are what counts. EDIT: I see even my HowTo contained this step. It is however not required :slightly_smiling_face:.

Basically, was there a particular step of my HowTo which did not work, so that you needed to go you own less secure steps? My aim writing HowTo’s is not only to make it easier, but also to make it more secure for people to do things, especially when it is about such sensitive things like private data exposed to the web, which is so easy to break. So I failed this aim, if for some reason people still go their own ways after reading my HowTo, weakening their data security :wink:.

EDIT: @c0ldfyr3 and others: I updated the HowTo with some unnecessary commands removed, better formatting, using Markdown code fences for copy button and adding the use of variables for all relevant paths and credentials. So it should be possible to do a lot more copy&paste without manually replacing arguments. Also sudo was added to all commands where it is usually required + a note about sudo -s as alternative. Please see whether something could still be better. I hope I did no typo/mistake in the edit :sweat_smile:.

2 Likes
147

Fixed it with 775 as you suggested. I tried 770 but that leads to an error message from Nextcloud admin page.

148

755 should work as well then. 770 would only work, if the webserver user www-data was member of the group, which owns this dir. Also 750 would work then (theoretically even 710), since this user does not require write access to the parent dir, only to the data dir itself, strictly seen executable permissions only, which mean directory listing = child dir access on directories.

The default 0755 root:root is usually pretty fine, when no one requires write access to that (parent) directory, but some require access to child dirs.

149

I looked for a howto you may be referring to, and I guess it’s this one.

I didn’t use this one, though I may have come across it when looking up how to do this. I would have seen that the post is from 2017 and assumed so much has changed in Nextcloud since then that it may not be as relevant today. It’s also kind of wordy at the beginning and the part I’m interested is farther down.

I see that the post is currently the #1 search result for moving the Nextcloud data directory. I think now, 7 years later, it’s probably better to start it off with the quick summary as given in the Nextcloud documentation, and then expanding those. The words you have at the beginning are some technical “under the hood” things that a person like me doesn’t want to get into when moving a data directory should be a fairly simple task.

I actually think the Nextcloud documentation should list the supported, sym link method first then the unsupported method, as the sym link method is simpler. I would get to the point early on with how to do that, then for those with more complex setups, go into more detail on those and describe more “under the hood” stuff.

I think enough time has passed and enough people have verified that the sym link method works, so we might as well just show the steps needed on a simple setup to move the data directory, with minimal wording about why it’s like that.

I think my main issues were how I copied the data directory, as it didn’t copy over hidden files, and the directory permissions for the parent directory of the data directory. I think the other information on how to do this is adequate.

150

You are aware that you are writing within exactly this topic? :smile:
How did you land here, but not reading the OP? However, forum navigation is sometimes weird, especially on huge topic like this, so all good.

I regularly update my HowTo’s, when required. See last edit timestamp. It is from today, and there are many more recent edits :wink:.

True. I like to give background information, but it is a double-edged sword.

I wasn’t aware that the Nextcloud documentation covers this at all. When I wrote this HowTo, Nextcloud staff simply saw this as unsupported move. While the symlink method is simpler, it is also kinda unclean, IMO, and it does not cover the security aspect of having the data dir outside of webroot. I definitely prefer method 1, hence I also made this no. 1. With the update today, I simplified the database update steps, so no manual MariaDB console typing anymore, but all can be copy&pasted into the shell. But I understand that generally accessing the database is a little worrying for some, hence method 2 is mentioned as well.

But thanks for the feedback. I am just thinking whether to put the “Background” into an expandable details, and add a tiny TOC for the two methods, like so:

Background

Click to read

Nextcloud looks up 
 bla blub 


Solution 1: Move data dir with database change
Solution 2: Link data dir without database change

EDIT: I just read this short points about the topic in Nextcloud docs. It is for relatively experienced admins, indeed, without giving any command-line command details etc. I do wonder that it mentions the symlink method as “safe moving of data directory, supported by Nextcloud”, as it collides with security recommendations to never have such data within the webroot itself (a symlink practically means the same), if one can avoid it. A properly configured webserver prevents direct access, but it is so easy to break this, with a little mistake at the webserver config. I’ll open a PR to have this docs section changed, as I think it is dangerously wrong.

151

Oh yeah lol I got lost here in the comments and there were several forum posts I was reading on how to move the data directory and must have gotten lost.

152

For those of us with less expertise on this, like myself, we need those of you who are more knowledgeable to speak up. I do want to know more about the security aspect.

This seems like something that should be simple but it keeps on getting complicated


153

First of all, there is a recommendation for this in the admin manual (also linked in the HowTo solution 2): Hardening and security guidance — Nextcloud latest Administration Manual latest documentation

  • Generally, a website visitor can access any file located within the web root, i.e. everything within usually /var/www or /var/www/html, depending on OS/setup.
  • So when Nextcloud data are stored e.g. at /var/www/nextcloud/data, visitors could access and download any of your files just by accessing something like https://your.domain.org/data/USER/files/documents/secret.pdf, or even browse the files, when directory indexes are not disabled.
  • Of course, when you use Apache2, this is prevented by the .htaccess file located in the data dir. For .htaccess files to work, there is however an AllowOverride directive required, like used here: https://docs.nextcloud.com/server/stable/admin_manual/installation/source_installation.html#apache-web-server-configuration
  • When you use any other webserver, .htaccess files are not respected at all, and you need to manually take care to make the webserver block access to this directory. The Nginx example config of course does this, but there is no template for other webservers: NGINX configuration — Nextcloud latest Administration Manual latest documentation
  • So while a properly configured webserver prevents direct access to data, mistakes or intended harmful changes by bad actors can break it. In case of Apache2, it even depends on two things: the data/.htaccess to exist (and must be readable by the webserver user) and AllowOverride all being set in the webserver config.
  • Having a symlink for the data directory in place, does not make a difference in this regards.
  • Moving that data directory entirely (without symlink) outside of the webroot, prevents the ability to access it through the webserver regardless how it is configured and whether .htaccess exists and is readable to the webserver user. For sensitive things like your private data/files, it must not be “recommended” to rely on the webserver setup to prevent unintended access, if there is a better/safer way.
  • There are cases where it is not possible to change the data dir location, like in case of certain shared hostings or appliances. However, in these cases where you cannot control the location of the data dir, you cannot control and hence cannot break (or falsely configure/setup in the first place) the webserver setup either. So the recommendation remains true for all manual/base metal installs of Nextcloud, which implies all cases I can think of, where manually moving the data dir is possible. So the docs section about that contradicts the security recommendation, IMO in a careless way. And I wonder who phrased this “supported by Nextcloud” part, and whether/who decided that this is really officially supported. Of course it does not make anything worse, and the risk to break something/loose data is low (compared to editing the database). But it must be at least made clear that having the data or a symlink to data in the webroot is discouraged for security reasons.
3 Likes
154

Hi, and thanks very much for this post !
just have one question on nfs share :
I have permission issue as nfs share “/path/to/new/data/folder” has my user ownership and not www-data

And apparently i cannot change this ownership (maybe rejected by nfs server)
>> Is there any things to do ?

Many thanks

155

Do you intend to have the Nextcloud data directory within an NFS mount on the server, or as NFS share to be mounted on another system? I would strongly advice against both:

  • Moving the data directory into an NFS mount heavily degrades performance, of course. Attach the storages/drives to the Nextcloud server system, or install Nextcloud on the system which has the storages/drives attached, but do not separate them. You can add an NFS share as external storage via Nextcloud UI, but this is meant to be an extension, not the main storage, and has limited features.
  • Having the data directory as NFS share to be mounted elsewhere is also a little dangerous. Note that manually editing files outside of Nextcloud means that it cannot track those changes in its database, which leads to inconsistencies at best, more critical issues up to data loss in the worst case. Instead of mounting it as NFS share elsewhere, mount/access it via its WebDAV API, so all access is done through Nextcloud as intended.

With NFS, modes and ownerships are shared between both sides, ownerships via UIDs and GIDs. The server can define whether and which clients have write access in general. If granted, it still requires root access to change the user ownership.

156

maybe you can tell me, in the oc_storage table there are records like “home:://”, “smb:://”, but sometimes just a set of some hash, like - “11f1b285df7f9de5dafa407ab5f8695b”, please help me understand how to compare this? Understanding all this, I plan to move the data from smb to local, leaving the links working.

157

Do not touch any of these! Only the local:: entry is the actual data directory. Everything else are internal per-user or additional app data. Looks like you use(d) some SMB plugin, for an external storage. If you want the contained data stored on your Nextcloud host system instead, copy the content over from the Nextcloud UI, or from a Nextcloud client on a client system which has the SMB share mounted.

158

I understand your caution, but I have a situation where I need to transfer storage from smb to local . As for the set of numbers in the form of a hash, this is an md5 connection hash from the “smb::user@ip address // share” line. I have already conducted an experiment on the test server and left the files the same while saving storage_id in filecache. Thus, I have a chance to save shared links.

What is needed for this:
change/update table data: oc_storage , oc_external_* , oc_mount
If I missed something, I would be grateful for additional information

159

Why do you want to do this via manual database adjustments? Maybe it is possible, maybe you will just break your instance, maybe you will leave something broken which has only a subtil effect and will cause larger problems later.

Open the GUI, find your external SMB storage, copy the files over to your local storage (they need to be copied anyway the one way or the other, since they are not physically on the Nextcloud server), adjust shares and stuff, where needed, then remove the external storage. The GUI allows to move files, which should preserve all metadata applied by Nextcloud (shares, tags, comments, 
). Maybe this works for external storages as well, not sure.

Beyond that strong recommendation, I cannot help you, since I never managed an external SMB storage on Nextcloud. All I know, is that it is something fundamentally different compared to the main local storage, so you can not change it the same way as described in this HowTo, where it is just out of scope/topic.

Or do I misunderstand, and you do not want to move the files from the SMB share into the Nextcloud local storage, but you want to just move the SMB share from another machine to the machine which runs the Nextcloud server, but leave it as SMB share and as external storage in Nextcloud? This sounds more like it would be possible. I actually would expect this to be possible with the GUI of the app, since a changing IP or hostname for the same share is not so uncommon either. Otherwise, yeah if the oc_storage entry is the MD5 hash of the SMB URI, looks like this is the way to replace it. Beyond that, no idea, as said, I never managed an SMB share on Nextcloud.

160

Please don’t worry, I did it. I needed to transfer data to a new server while preserving external user links. First, I transferred all the files to local storage, and then wrote a program that searched for all external links on the original server and got the file parameters (from the filecache table) and searched for an identical parameter on the new server, and then also inserted the already known token for the external link. Note that Nextcloud indexed the files on its own, I did not interfere with this process, all I did was insert values ​​with new file identifiers into the oc_share table. Now I understand the internal workings better. Thanks for your help and advice

ps. as for the md5 hash in the oc_storage table, this was done because the field width was 64 characters and some of the links that were too large (and this can happen) were automatically replaced with this hash using the formula md5(smb::userName@ip_address // share-name-long-name-with-other-hash”)

161

Makes sense. Files on external storage are indexed (the table is called “cache”, but in fact that wording is wrong as it is an index) the same way, so replacing index identifiers elsewhere in the database generally works, regardless which storage type.

This behavior has even some negative implication: I remember a case where an SMB share was used across hundreds of (Nextcloud) users in the same office. Since every user added the SMB share to their own Nextcloud files, all files in the share were indexed once for each user, hence hundreds of index entries for every file. In turn that table had a massive size, bringing down the database and server to its knees :smile:. A team folder, or sharing a storage or directory from within Nextcloud with all users is a better solution for such things, so every file has only a single database entry.

I still wonder whether Nextcloud generally does not move shares together with files, when moving them from within the web UI, or whether it depends on the storage type. Would be actually a reasonable feature, so there is no need to do manual bulk database adjustments to preserve shares, also comments, tags, previews, versions and all such.

162

studying the mechanism of behavior and operation of filecache I just saw that each new mount point appeared in this table like a tree and was ready to grow in its own way. But probably it has its own architectural sense, when each mounted device has its own “reference point”, in my previous database about 5 TB is stored, about 800 storage records were created (due to ldap users), therefore the database after that contained about 6 million records. I had to create one user who was included in all the groups I needed at once, for each of which there was its own mount point of the local folder, thanks to this I was able to optimally assemble the index tree in the filecache table. for comparison between two servers with the same files on 5 TB on the old server 6 million records, and on the new 150 thousand records. at the same time everything is the same, I can say I was lucky to understand the mechanism of operation and optimally index the files in the filecache table

ps. When the new server replaces the old one, new trees may appear, but right now the difference is large in the number of records in the database.

1 Like
163

There is a command to set the datadirectory without messing with database clients and stuff:

sudo -u www-data php "$ncpath/occ" config:system:set datadirectory --value="$newdata"`

(This Howto from 2017 is pretty outdated in 2025, are there moderators out there to fix this?)

164

the occ command doesn’t fix paths of existing files..

@theking2 the How-to is still valid IMO but you are welcome to update and summarize - feel free to post anywhere or send me the update how-to as PM I’ll be happy to move into right category.

1 Like
165

As can be seen from the edit history, I am following and update the HowTo whenever needed. Last time I checked occ only changed the config.php, which leads to a new oc_storages entry, but does not remove the old one. While this may work, since it is generally not officially supported, hence not tested, it is advised (by Nextcloud engineers) to not leave the duplicate entry in place, to avoid any possible (now or future) problems.

But even for the config.php entry, I’d keep the sed in place, which replaces really any occurrence of the old path, not just the datadirectory entry. skeletondirectory, templatedirectory, logfile, logfile_audit, apps_paths, tempdirectory. mount_file, etc quite a bunch of settings which can contain the full data directory path as well.

2 Likes