If you prefer mysql or mariadb, changing the php database module should allow using it, but I prefer postgres for it's faster multi-user performance. The installation process does require you install a postgre docker container (I use postgre as it is faster than mariadb/mysql), and pre-creating a nextcloud user and empty nextcloud database owned by the nextcloud user for postgres (easily done via a pgadmin container or the CLI if you prefer CLI and want to bash into the posgres container) and a redis docker container, as neither of these are included in the setup but are required for nextcloud to run. I find this method very satisfactory as an LXC gives close to bare metal speed, just as docker does, but does not rely on a group like linuxserver to decide for me how updates should be done or what features I am allowd to use, so as long as nexcloud uses the updater.phar method, I still have it, and I have no feature restrictions. I can now use a slightly modified version of this script to install on bare metal or a VM or without modification as I am currently doing, on an Ubuntu (Nextcloud's recommended OS) LXC with a passthrough filesystem mounted in the mount point created by the script for the data directory. Shortly after nextcloud forked from owncloud, a bad owncloud update release broke a bunch of things and I switched to nextcloud, using the vm built by hanson IT in sweden as they were listed as the official VM, I was never pleased with the full VM approach as it was much more sluggish than bare metal, so I tried docker, but found that some of the features I like to use did not work in docker at the time, so I started writing/extracting the vmdk from the hanson IT vm to a drive to run bare metal again, but not have to go through the manual build up, but as is the case, things change over the years and I ended up developing an install script that installs everything I need without the extra stuff in the hanson IT vm and without the manual configuration. I used to run owncloud on bare metal using a manual build up from the documentation. Not trying to cloud the issue but here is my personal setup. This is why Linuxserver says above to pin a specific TAG on the YML.įor those who use "AUTO UPDATE", be extra carefull. If there's no prior backup, your container is gone. You can't downgrade even if setting a lower NC image on the YML. Now, let's say something goes wrong and your NC doesn't start or is with errors: If I'm seeing it right, as soon as you pull a latter image version with a latter NC version, the container will run the update on the NC base folders to reflect the update. This move now allows those who use watchtower (for eg) to update the container, to automagically update the version without the need of running the updater on the Nextcloud GUI. We recommend pinning a specific tagged version like lscr.io/linuxserver/nextcloud:version-27.0.0 and manually changing your image version when you are ready to upgrade. An important thing to keep in mind is that systems that automatically update your container will result in irreversible changes to your Nextcloud instance.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |