Nextcloud files on another drive

I have a Nextcloud set up in the following way:

Nextcloud for my permanently accessible data

20 environment.etc.“nextcloud-admin-pass”.text = “…”;
19 services.nextcloud = {
18 enable = true;
17 package = pkgs.nextcloud28;
16 hostName = “192.168.0.5”;
15 maxUploadSize = “200G”;
14 config = {
13 adminpassFile = “/etc/nextcloud-admin-pass”;
12 extraTrustedDomains = [ “mydomain.com” ];
11 };
10 };

Now I found out that my files are all at /dev/sda2/var/lib/nextcloud but I would like to have my nextcloud at /mnt/nvme/nextcloud .

seems simple enough, but I can’t make it and GPT is only suggesting to add “datadirectory” to the configuration.nix where it says that this command is not there.

There is a post tat suggests " Due to systemd hardening and sandboxing, I think it will be easier to just mount your disk at /var/lib/nextcloud ." but I have other things on that disk

if any further info is necessary, please let me know.

I still think this is true. See below, don’t listen to me.

You could use a bind mount instead to bind a specific subdirectory of that disk.

environment.etc.“nextcloud-admin-pass”.text = “test123”;

Don’t actually do this, you’re storing your password world-readable in the nix store.

1 Like

you can use the services.nextcloud.dataDir option to set your data to a desired directory/mountpoint if that’s enough for you

We learned in the referenced thread that that option doesn’t work as conveniently in practice because of permissions and cgroups, sadly. May be worth revisiting, to be fair, I don’t recall the exact problem, it may have involved ntfs?

maybe you’re talking about the services.nextcloud.home option which by default points to /var/lib/nextcloud?

I’m using this setup with dataDir being on a dedicated mountpoints literally for years without any issues. In my case it points to a NFS mountpoint to make things more interesting :slight_smile:

1 Like

Looks like you’re right, I must be thinking of a different thread: Cannot change home dir / datadir in nextcloud

That mostly looks like there was data from a former installation still lying around and the remount was an incidental fix.

Sorry about the misinformation!