[Enhancement]: make a docker-compose.yml
This would allow users to upgrade the Nextcloud docker container (to a newer version) while keeping all data.
It's already working. In my installation it works with the following preferences very well:
-v /volume/nextcloud_docker/config:/usr/share/webapps/nextcloud/config
-v /volume/nextcloud/apps:/usr/share/webapps/nextcloud/apps
-v /volume/nextcloud/data:/usr/share/webapps/nextcloud/data
-v /volume/nextcloud/sslCert:/root/sslKeys
Sure. But ideally, this would be preconfigured in a docker-compose.yml. I guess most people finding this repo will just start the service, and then have an unhappy surprise when after an update, all their data is gone.
I think it should at least mention that additional work is needed to make it useful in the longer term, if not providing data volumes or mapped directories as default.
Also, please don't misunderstand - I am very grateful for you to provide this dockerized nextcloud. Thanks for your work!
I'm not so familiar with docker-compose, I'd be super happy to have help in forming the yml file. PRs welcome!
A nice example can be found here, for Mattermost:
https://github.com/mattermost/mattermost-docker
Great, can you modify that for this project and present it here?
If I had the time to do this with proper testing, you would have the prq already - sigh. Maybe this weekend....
I also linked the -v parameters with my local storage, in my docker create command, but I get a access/permission failure after I start the Nextcloud setup. Either Nextcloud can't access the data folder (because the chmod setting is wrong) or “all users can access" (after I setting chmod to 777, for testing) and Nextcloud won't continue.
What are the permission rights (chmod) for the folders (/config, /data, /apps) and what's the user/group?
Yeah, managing the permissions on various files that nextcloud touches is tricky, especially when volume mapping all over everything in a docker container.
Here is the section of the nextcloud manual that covers the permissions that it expects: https://docs.nextcloud.org/server/9/admin_manual/installation/installation_wizard.html#strong-perms-label
I've written a script that (re)sets these permissions: https://aur.archlinux.org/cgit/aur.git/tree/set-nc-perms.sh?h=nextcloud
You can run 'set-nc-perms runtime' in the container. That might fix everything.
Thanks for your advice. I've run your command and I think it worked. The permission error message has no longer appears.
But now, when I logged in Nextcloud, Safari (or Chrome) says: ERR_TOO_MANY_REDIRECTS. (on address: “https://my.local.server/nextcloud/index.php/apps/files/“). When I access “https://my.local.server/nextcloud/index.php/settings/personal“ directly, for example, the page show up.
I think there is still a problem with the /data/ folder permissions?!
//edit I removed my Nextcloud container and rebuild a new one to have a clean "install". Nextcloud Login page -> login /w user and pass -> same browser error - too many redirects. :(
+1 for storing data and config out of the docker image.
@Calprainn How did you resolve that?
@kmain4 No, sorry. In my case the container variant was too busy and unstable, so I installed Nextcloud native on my Ubuntu Server (with Apache and MariaDB) and it runs like a charm. In the meantime, I have already installed Nextcloud updates without any problems.
@Calprainn as in you couldn't find a resolution using the docker container? I'm having the exact same error as you describe above (including error message, and ability to go straight to settings via the direct url). I'm using the new nextcloud 11.0.0 image, and have just migrated from owncloud 9.1.2.5
FIXED - the problem was I was mounting an empty apps folder. Fixed by not mounting an apps folder (letting the docker container's default apps folder be used), allowing it to upgrade, then using docker cp to copy the folder out, and mounting that in future for persistent apps.
So is there any simple way to update to a newer version?
@wwwi7891: Yes, there is "simple" approach which I am currently scripting:
- Copy all required files from your running container to local directories on your host docker cp)
- Stop the local container
- Generate new image with a docker file pulling the latest Nextcloud image, add your exported files from Step 1 and start a container from the new local image.
I am not completely sure about which files to export and import but will report back. Step 3 would also leave peoples the option to add other files or do modifications (own SSL certs, move data to separate data directories, etc). I enjoy that this docker container is somewhat self contained and does not require external containers such as a database or reverse web proxy. So providing a docker-compose file seems a bit more overkill. It would be enough to make the usage of a volume for Nextcloud data simpler with the original container. May be simply some mountpoint under /opt/ncdata where you can first attach a volume for your personal data and configure this mountpoint at the first run.
I am still not completely confident how NC stores its data but when using sqlite I guess everything including contacts, calendar, etc is stored in the data directory.
I will post my update if I find the time to test
OK, things are looking good. I "migrated" my data and apps to a newer Docker container without manual intervention. So far I have not seen any missing data and my Nextcloud container looked identical with identical credentials. My Android Nextcloud App didn't complain when accessing the data.
Allow me a few more days working with the "migrated" container prior posting my Dockerfile and the corresponding scripts. While the scripts are only some lame Docker commands I think they are still a starting point for peoples to easily migrate they data once a while to a new container rather than sticking to an older version of Nextcloud mainly because they are too lazy to push their stuff around.
Do share! Maybe we can integrate them here!
@greyltc: I shurely will share them :-)
Just a bit more testing is needed. I found some files where Nextcloud told me they are not existing although I know they are there since I had at look into the file system of the new generated container.
I guess I need to enforce file permissions and ownerships after building the new image with the migrated data as described here: https://docs.nextcloud.com/server/11/admin_manual/installation/installation_wizard.html#strong-perms-label
Will report back this evening when I had a look into the issue.
I did a few changes to my scripts in my Linux VM at work but can't test them since I have no access to my physical server at home which hosts the container. Anyway, here is what I think will fix the rights issues if I am wrong. Keep in mind they are not tested.
I had to tar them since .sh Textfiles are not supported by github.
FYI---
I've already got a permissions setting script that follows that page in the manual. It's available in the container here as set-nc-perms
Here it is:
https://aur.archlinux.org/cgit/aur.git/tree/set-nc-perms.sh?h=nextcloud
Ah, nice....then the Dockerfile would look simpler:
# Pull newest images
FROM greyltc/nextcloud
# Add local data and configuration from old Nextcloud container
ADD ./nextcloud/config/* /usr/share/webapps/nextcloud/config/
ADD ./nextcloud/data/* /usr/share/webapps/nextcloud/data/
ADD ./nextcloud/apps/* /usr/share/webapps/nextcloud/apps/
# Correct rights and ownership of Nextcloud files
RUN set-nc-perms runtime
I'm not really sure it's best to actually keep your data inside the container. Maybe it would be smarter to use docker's volume mapping feature to map a folder on your host machine into the container.
Well, I am not shure about this. I guess from a security point of view containers are never 100% perfect and less isolated than running a KVM machine on the host with some Linux distro plus Nextcloud in it.
Sharing files from the host with a container provides faster access to them but also means you are "penetrating" the container (so to say).
What makes more sense to me would be to move the NC data out of the Webservers root in the first place since an attacker would then not have direct access to the file. This something the NC security hints suggest and which we also did for the NC server in our company.
For this you could simply add a subdirectory /opt/ncdata to your image which is writable for http:http. This way people could configure this as data directory after the first start of the container.
I would prefer the data inside the container for ease of backup (One liner to dump the whole container to a tar file) and encapsulating everything required to run my own NC instance.
Beside this migration of the data out of the container to use it for volumes as described by ngreen above would be a no-brainer.
In order to use those volumes
-v /volume/nextcloud_docker/config:/usr/share/webapps/nextcloud/config
-v /volume/nextcloud/apps:/usr/share/webapps/nextcloud/apps
-v /volume/nextcloud/data:/usr/share/webapps/nextcloud/data
-v /volume/nextcloud/sslCert:/root/sslKeys
One could extract the data from the running container like this:
docker cp nc:/usr/share/webapps/nextcloud/config /volume/nextcloud/
docker cp nc:/usr/share/webapps/nextcloud/data /volume/nextcloud/
docker cp nc:/usr/share/webapps/nextcloud/apps /volume/nextcloud/
docker cp nc:/root/sslKeys /volume/nextcloud/sslCerts
Well at least something like this with possibly some minor adjustments
Oh yes, and as I wrote above: I see, understand and use your image as base for a simple direct "out-of-the-box" implementation of Nextcloud. Everything is self-contained. Pull the image, launch a container, expose 443 via your router to www and BAM you are set :+1:
Much simpler than using another container solution with spawning three containers for reverse proxy, database and Nextcloud itself. For me this somewhat against the idea of Docker for providing a simple (!) solution to people in order to provide and use applications out there. I know about Docker, Docker swarm, Kubernetes and all those things but folks at home (possibly less technically skilled or low on time) will more aim for running such a container on either a commercial NAS with Docker support or (similar to me) on a small, silent Low Power PC.
Just my two cents, Holger
Here is my official recommendation for upgrading your NextCloud: https://github.com/greyltc/docker-nextcloud/blob/master/README.md#updating-nextcloud
Well, with all respect: Docker is meant to build images from scratch for updating anything that is delivered inside this image. Updating anything inside a running container is somewhat eliminating the benefits of docker. Similar to do manual modifications of running containers rather than using Docker files to apply changes to a base image.
Edit: BTW....when I tried to update my running NC11 container using the described approach the included updater failed and reported something like "assets found". I guess they refer to the data folder inside the nextcloud folder ?
So for me I will rather always use your freshly provided images and migrate the data. Possibly working with volumes is a good approach but doesn't drive my boat either. I will post my final "migration script" plus Dockerfile this evening or tomorrow if I had more time to test the result.
Anyone who likes can use them at own risk.
Thanks once again for your work on the NC image ! :+1:
Fair enough!
Ok, finally it worked. Migrating your apps will not always work. Neither if you use a volume for the NC app folder or simply copy them over to the next image.
Unfortunately the updating of my local copy of your base image didn't really work well. So I removed all local images and started the build process with the attached files again. The resulting image in my local registry started fine as container and upgraded itself (or the database ?) to Nextcloud 11.
As for the apps I had to re-enable them (contacts, calendar, etc). The data still remained there. My contacts are there, my calendar seems not to miss any birthdays.
Use those scripts at own risk. I will use my updated container in the mean time but in future it might switch to a KVM for hosting Nextcloud or possibly think about an external container with a database plus storing the data files on a volume.
Time will tell ;-)