using the docker install, how would one go about placing the actual cloud files storage outside of docker? Is this by default? A switch on first run? Or by editing docker-compose?
Sorry, I thought this would be easy enough for ppl to answer here before I went thru the trouble of trying to find out on my own.
TIA
There are a several docker images available, which one do you intend to use and on what hardware?
You can use the -v (volume) option to mount data, anywhere you want it.
You can mount a folder on the host (as opposed to a Docker volume) to a folder on the container. So for example with Nextcloud you may want to mount the web root and data folder (which should not be under the web root) to actual folders on the host.
You can find the full command reference here under volumes:
I would definitely map the data volume (any data you want to persist from a Docker container should be mapped with a volume).
But Iâm not clear on the reasons for mapping the web root or other application code. Does that kind of defeat the purpose of Docker?
No, it just makes it simpler to access the data or back it up.
An unnamed volume is also created automatically for the container root. When you delete and recreate the container, the unnamed volume gets set aside and a fresh one is created. In other words, everything NOT in the web root or data folder gets replaced with fresh files from the image.
Donât you also want to replace what is in the web root with the app code from the new image? The only thing you want to save is the user data and configuration, so doesnât it only make sense to map those two things?
In other words, isnât the Nextcloud application code stored in the web root? So if I map the web root to the host and then upgrade Nextcloud with a new docker container, I actually wonât get a newer version of Nextcloud?
I wondered the same thing, however, this is exactly what the Nextcloud Docker image documentation says youâre supposed to do. In fact, in their example they map a volume to /var/www/html and say this is âneeded for upgrades.â
It does seem like the opposite of what youâd expect, but Iâve done several upgrades on mine this way and had no issues. It always comes up immediately at the new version despite the web root being persistent storage.
have a look at the entrypoint script. at each startup the local version is checked vs. the image version.
and if the container version is smaller than the image version a rsync is performed. (line 61)
these folders are excluded:
https://github.com/nextcloud/docker/blob/master/17.0/fpm-alpine/upgrade.exclude#L1
so thatâs whatâs not get overwritten by an update. aka thatâs what you should backup beside your data and the database. 
@KarlF12 Thanks, that is interesting that itâs in the Docker documentation. I read your comment and was thinking about investigating the entrypoint script, then Reiner_Nippes commented in detail (thanks @Reiner_Nippes), thatâs what I was suspecting.
I still wonder what the reason is behind this choice. Not only are we mapping application code in a volume (which shouldnât be modified and doesnât need to be backed up), but that also means the new Docker container every time has to check and update the copy of the application code if you upgraded. To me that seems pretty strange, so I would still prefer to map only those specific files/folders that are excluded from the rsync, which obviously are the ones you want to save when the container gets destroyed.
Maybe itâs just easier to explain for new people using the docker image of Nextcloud instead of making you map 5 different volumes, but given a good docker-compose example it shouldnât be a big deal. I just canât put my finger on it, but it seems like we could eventually run into issues by mapping /var/www/html entirely.
Good discussion!
which is the recommended docker? Iâd like to keep up with the one that is updated most frequently. i only need the basic features.
the nextcloud images should be all updated automatically all at the same time.
the docker compose file you can choose based upon your needs and preferences. (nginx vs. apache, mysql vs. postgres, selfsigned vs. letencrypt)
Yep. Generally if youâre not sure, look at whatever the âlatestâ tag points to and use that. In this case itâs the apache version. Unless you have specific needs like storage considerations (then often times thereâs an alpine version), or if youâre going to have high traffic the maybe look at FPM.