How to force Nextcloud AIO to respect volume settings in docker compose file?

I try to use the following volumes configuration in the docker compose file:

volumes:
  nextcloud_aio_mastercontainer:
    name: nextcloud_aio_mastercontainer
  nextcloud_aio_nextcloud_datadir:
    name: nextcloud_aio_nextcloud_datadir
    driver_opts:
      type: "nfs"
      o: "addr=10.1.0.4,nosuid,nolock,soft,rw"
      device: ":/volume1/docker/appsrv/nextcloud/data"

But for some reason Nextcloud AIO seems to override my settings and wont allow me to store my data on an nfs share. It creates a local volume instead. How do I force Nextcloud AIO to accept my settings?

Many Greetings!

Hi, see https://github.com/nextcloud/all-in-one?tab=readme-ov-file#how-to-store-the-filesinstallation-on-a-separate-drive

That doesn’t answer my question nor solve my problem. The only way to make sure a NFS share is mounted when a docker container starts during host reboot is by setting the NFS options on the docker volume.

https://github.com/nextcloud/all-in-one?tab=readme-ov-file#how-to-change-the-default-location-of-nextclouds-datadir

1 Like

Please stop sending documentation links that don’t help. Also: I consider sending a link without any further explanation rude.

1 Like

I came up with the docker compose configuration I wrote in my first post after reading the manual multiple times. As far as I understand that is how it is supposed to work with docker compose. And it actually did with all previous projects I configured. So why is it not working with Nextcloud AIO?

Do you realize how rude the classical RTFM reply really is? Since you didn’t write a single word I actually don’t really know what you’re trying to tell me.

I don’t have a direct answer to your question either, but perhaps you could use a workaround such as mounting the NFS share externally, e.g. with Systemd, and then ensuring that the Docker service only starts afterwards, as in this example I found (not tested myself): How to mount NFS share before starting docker service ? - Red Hat Customer Portal

1 Like

Thanks for the suggestion. I spent quite some time with the topic NFS in combination with docker compose. In the end I decided it’s best to let docker handle NFS connections. This way I don’t have to change anything in the host system core and it works reliably.

Do you realize how rude the classical RTFM reply really is? Since you didn’t write a single word I actually don’t really know what you’re trying to tell me.

We’re all volunteers trying to be helpful.

If you think RTFM replies (with direct links to specific and relevant doc sections!) are rude or unhelpful, perhaps you haven’t spent much time replying to random people on the Internet seeking assistance… :wink:

But for some reason Nextcloud AIO seems to override my settings and wont allow me to store my data on an nfs share. It creates a local volume instead. How do I force Nextcloud AIO to accept my settings?

Are you utilizing NEXTCLOUD_DATADIR as noted in the previously linked documentation for customizing the used data directory?

Please post your actual Compose file.

2 Likes

You’re right, I don’t spend much time answering to random people. Since it’s not my paid job, I only answer when I have something useful to say. Every voluntary helper has the freedom to ignore a question when they don’t like it.

I only posted the volumes part of the compose file because that’s the only relevant part. Together with my question it’s obvious that the volume is actually created and used. Just my additional volume settings are ignored.

The answer to this question is loosing its meaning anyways. I’m switching to iSCSI for the docker volumes folder because I can’t get rid of random NFS fileid changed notifications. That means I have to once again dable with starting order of services.

I guess the mention in the documentation to “manually” creating the volume would be the key. Well at least it’s a documented bug in Nextcloud AIO, right?

Many Greetings!

I guess the mention in the documentation to “manually” creating the volume would be the key. Well at least it’s a documented bug in Nextcloud AIO, right?

It’s not a bug in AIO. It’s the way Docker Compose works.

When defining the nextcloud_aio_nextcloud_datadir volume via Compose, Docker won’t create the volume until it is associated with a service. You can verify this yourself: it won’t even show up in docker compose config for example.

This is why the AIO instructions say to create the volume beforehand manually. This works around this limitation in Docker.

Without getting into all the specifics at the moment, there is a workaround even for Compose: you can create a dummy service in the Compose file that is associated with the nextcloud_aio_nextcloud_datadir. You won’t use that service for anything, but it’s enough for Compose not to consider the volume orphaned – so it creates the volume.

volumes: # If you want to store the data on a different drive, see https://github.com/nextcloud/all-in-one#how-to-store-the-filesinstallation-on-a-separate-drive
  nextcloud_aio_mastercontainer:
    name: nextcloud_aio_mastercontainer # This line is not allowed to be changed as otherwise the built-in backup solution will not work
  nextcloud_aio_nextcloud_datadir:
    name: nextcloud_aio_nextcloud_datadir
    driver: local
    driver_opts:
      type: "nfs"
      o: "addr=192.168.5.23,nfsvers=4,rw,soft,nolock"
      device: ":/"

services:
  # This service does nothing but keep the volume "alive" in Compose's eyes
  nfs-volume-anchor:
    image: alpine
    command: "true"
    volumes:
      - nextcloud_aio_nextcloud_datadir:/data

  nextcloud-aio-mastercontainer:
    image: nextcloud/all-in-one:latest
      nextcloud-aio-mastercontainer:
    image: nextcloud/all-in-one:latest
    init: true
    restart: always
    container_name: nextcloud-aio-mastercontainer # This line is not allowed to be changed as otherwise AIO will not work correctly
    volumes:
      - nextcloud_aio_mastercontainer:/mnt/docker-aio-config # This line is not allowed to be changed as otherwise the built-in backup solution will not work
      - /var/run/docker.sock:/var/run/docker.sock:ro # May be changed on macOS, Windows or docker rootless. See the applicable documentation. If adjusting, don't forget to also set 'WATCHTOWER_DOCKER_SOCKET_PATH'!
    ports:
      - 80:80 # Can be removed when running behind a web server or reverse proxy (like Apache, Nginx, Cloudflare Tunnel and else). See https://github.com/nextcloud/all-in-one/blob/main/reverse-proxy.md
      - 8080:8080
      - 8443:8443 # Can be removed when running behind a web server or reverse proxy (like Apache, Nginx, Cloudflare Tunnel and else). See https://github.com/nextcloud/all-in-one/blob/main/reverse-proxy.md
    environment: # Is needed when using any of the options below
      NEXTCLOUD_DATADIR: nextcloud_aio_nextcloud_datadir # Allows to set the host directory for Nextcloud's datadir. ⚠️⚠️⚠️ Warning: do not set or adjust this value after the initial Nextcloud installation is done! See https://github.com/nextcloud/all-in-one#how-to-change-the-default-location-of-nextclouds-datadir

Take a look at the parsed config output: docker compose config (for your existing Compose file). If the NFS volume isn’t listed there, this is at least part of the problem. Then do the same for the example above. That NFS volume will show up.

As far as I understand that is how it is supposed to work with docker compose. And it actually did with all previous projects I configured. So why is it not working with Nextcloud AIO?

Did those projects have all the services (i.e. the ones reference the NFS volumes) in the Compose perhaps?

AIO doesn’t work like that; it bootstraps via the mastercontainer then interacts with the Docker API directly to bring up and manage additional containers to bring up a full Nextcloud stack.

I only posted the volumes part of the compose file because that’s the only relevant part. Together with my question it’s obvious that the volume is actually created and used. Just my additional volume settings are ignored.

Believe it or not the people here do have some idea what they’re doing. We don’t just ask for additional information for the heck of it. The rest of the Compose file does matter.

1 Like

What I gather from this is that it might actually be better to mount the NFS share at system level via fstab or systemd (systemd with the relevant configuration parameters to be 200% sure it is mounted before Docker starts) instead of relying on Docker Compose. :wink:

1 Like
docker compose --ansi never --all-resources config

I don’t see any limitations with docker. Since I’m not very deeply involved in either project I might have a different view on things. My opinion is: It’s a bad design decision made by the Nextcloud Developers and that’s why I call it a bug in Nextcloud AIO. There are more things that bug me but they are off topic here.

Yes, thank you for that suggestion. I had that idea much to late.

Yeah, that’s one of my biggest issues with Nextcloud. It messes with my otherwise “perfect” setup. “Perfect” being perfectly subjective, no discussions required there.

Sorry, but I don’t see how that would be a insight gathered from this forum thread. As I mentioned before: The NFS mounts handled by docker are working just fine. With a properly set up NFS server I would suggest this setup to everyone. Just make sure the NFS shared folders are located on their own file-systems. Unfortunately my NAS is set up as one big file-system.

So what now? Does it work or not? Or does it only work with other containers/stacks and not with AIO? I’m a little confused.

I am not knowledgeable enough to be able to judge this in detail. However, I would treat AIO primarily as an appliance. In other words, I wouldn’t try to change anything beyond what is officially described in the Readme/Wiki on GitHub. I also wouldn’t integrate it into existing Docker stacks.

If you want more flexibility, you could use the “normal” Nextcloud images and build your own stack. If that’s still not flexible enough for you, all the software used in AIO is open source and freely available, so you can always create your own images and “design” everything the way you want it. :wink:

Docker itself works without any questions. The problem is the way Nextcloud-AIO handles the data volume. With the current implementation it just ignores any volume settings from the compose file. Also: I consider it a very bad design decision to implement a data path in a way that prevents it from being changed in the future. Had that with other software in the past and it is always a hassle.

Up until now I couldn’t find an example docker compose file that implements that for the current version of Nextcloud. It seems they only support Nextcloud-AIO in the future. Also: I really like the backup functionality of Nextcloud-AIO. I’m considering implementing something like that for the rest of my docker stacks.

If you think this could be done better and maybe even have some specific ideas about how it should be done, why not open a feature request on GitHub, or maybe even diretcly contribute via pull request. I think they are generally open to suggestions and contributions that improve the product as long as they remain within the project’s scope, can be implemented and maintained with reasonable effort, and, most importantly don’t break anything. :wink:

https://github.com/docker-library/docs/blob/master/nextcloud/README.md#base-version—fpm

Of course, this is only an example for a basic Nextcloud setup. If you want all the bells and whistels of AIO, you’d have to add them yourself.

Hey, just to link to this post again and quote my own screenshot:

  • Another option is to provide a specific volume name here with: --env NEXTCLOUD_DATADIR="nextcloud_aio_nextcloud_datadir". This volume needs to be created beforehand manually by you in order to be able to use it. e.g. on Windows with:
    docker volume create ^
    --driver local ^
    --name nextcloud_aio_nextcloud_datadir ^
    -o device="/host_mnt/e/your/data/path" ^
    -o type="none" ^
    -o o="bind"
    
    In this example, it would mount E:\your\data\path into the volume so for a different location you need to adjust /host_mnt/e/your/data/path accordingly.

To highlight it even more, you are probably missing --env NEXTCLOUD_DATADIR="nextcloud_aio_nextcloud_datadir" in the compose file.

1 Like

Yes, that’s hard without a reference. I don’t remember exactly where it was mentioned and I don’t have time right now to look for it. But since only AIO will be supported in the future and I would like to use a supported installation, I’m probably stuck with it.

Yeah, that would be a completely new rabbit hole I don’t really have time for right now. But I will keep it in mind.

Nope, not missing it. This discussion here is at least one level below this documentation entry. I’m not so good with words, but I’m thinking at a developer level, since I’m one myself.

Just found it myself at the top of your link: “This image is maintained by community volunteers”. That’s not exactly what I want to use for a production environment.