HowTo: Change / Move data directory after installation

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

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

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.

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.

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.

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.

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…

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.
2 Likes

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

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.