SOLVED: Docker Install, File Storage Outside Docker

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.


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:

1 Like

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?

1 Like

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.

1 Like

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:

so that’s what’s not get overwritten by an update. aka that’s what you should backup beside your data and the database. :wink:

1 Like

@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!

1 Like

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.