Hi selfhosted! Hope you’re having a good day :)
I’m pretty new to self-hosting and have been traipsing through a minefield attempting to make NextCloud AIO work inside Docker. The instance runs for a few days/weeks and then starts getting extremely slow on the website, then dies entirely. Usually, either the ClamAV or Apache containers get stuck in an unhealthy state that no number of reboots or reinstalls can fix.
Quick context for how this all works. I have one machine that runs Proxmox and a group of VMs for various purposes. One such VM runs my Nextcloud. This VM is running Ubuntu 23.10, Docker, and the NextCloud AIO package.
Another VM hosts OpenMediaVault, which contains a set of SMB Shares mounted to the host VM that act as storage for NextCloud. The symlinks (I think I’m using that word right) on the host VM have user and group permissions updated according to AIO’s documentation. Proxmox is configured to boot this VM first, then boot the rest in sequence once the files are available.
Right now I’ve got Nextcloud handling Synchronization of Files, Calendars, Contacts, and Kanban boards via the Deck Extension. Everything else can be abandoned at this point, these are the only functions I’m truly using. If this gives you an idea for an alternative app I’d love to hear it.
So after AIO broke for about the 5th time in the 8 months since I started trying to self-host it, I’ve been looking at alternatives. Before I go that route, I want to try installing Nextcloud without Docker. Some of the posts I’ve read here suggest that the Docker distribution of NextCloud has serious issues with stability and safely installing updates.
I plan to make a new VM entirely for this, Distro undecided. I still want to run it as a VM and still use my SMB shares for bulk storage.
So where would I begin if I planned to install NextCloud directly to the VM rather than through Docker?
How are you running Docker on your Ubuntu host? I had weird errors happening and realized that while I had installed Docker manually using the convenience script, at some point the Snap version got installed and that was a mess.
Switched to Debian, docker installed with convenience script, Nextcloud AIO has worked like a top since. All running as a VM on Proxmox as well, the host runs dozens of containers including a mailcow instance and several other stack beside the AIO, zero issues. I snapshot the VM before I do anything major like update NC so I can rollback easily. I might lose a few emails if I had to roll back, but never had to. Besides, everything is backed up via PBS hourly, so if I had to restore just the NC stack, that wouldn’t be hard.
I would also do the storage for NC locally, you can mount another dataset/virtual drive into the instance, but using Openmediavault Samba shares for your data store seems like a recipe for disaster. Samba on Linux is a convenience for interoperability with Windows, but using it as a backend for an app as complicated as NC is really not going to end well. I’m surprised you get it to work for more than a few hours, and I could see it losing data so easily.
I’ve only ever used the official repositories, basically followed the install documentation to get the letter. I do management of it through Portainer but that’s just a convenience for testing. Once I got the Compose file just right I’d docker up -d inside the folder on the VMs main drive.
The actual files were saved to a mounted SMB share, and I’m not sure if it’s related or not but I also had a media folder mounted as SMB and configured to be shared as External Storage within Nextcloud itself. I keep wondering if the database isn’t killing itself trying to read everything in there…
Yah, I just don’t think the SMB subsystem is robust enough to be used for that purpose. I can see pulling a few files on and off, but expecting the PHP backend to work with it to manage file locks etc on SMB is probably optimistic. Plus because docker is involved, I believe overlayfs would be involved there, unless it’s a bind mount. Then you have a layer between OMV managing the communication between it’s underlying filesystem to the samba server it implements. I’m really not 100% sure what the pipeline to the actual files would look like. But it seems horrendous.
I’d really just try it stock before you throw that baby out, because I’ve run NC every way you can possibly imagine since about V.8, and I’ve not had so little problems with it as with using the AIO. It’s head and shoulders above straight installation, somewhat better than NC-Pi. Snap was by far the worst for management and upgrade. And I would avoid Ubuntu as the host system, because I have no idea how docker snap got installed, but I don’t trust that it wouldn’t happen again. I sure as hell didn’t install the snap version, but there it was.
Also, with the AIO, I would avoid managing anything outside the interface of the master container, like by using portainer on the child containers.
I was really just using SMB for convenience sake, one less protocol for me to turn on and configure. I initially thought about NFS but when I realized how little I know about actually securing NFS I decided against it. Though, I suppose that’s led me to this point here.
Trying it stock is exactly what I was thinking, though what folks have said about NixOS makes me think that’s going to be the first thing I try.
Very first experience was NC-Pi, right before that project got canned. Loved it so much I spent a couple hundred on shared hosting and set v24 up there, but I’ve been trying to move to my homelab because A) One less bill B) I can use the 72TB RAID Array for storage instead of the 30GB storage I paid way too much for.
Honestly have had great experiences with Portainer so far, with Nextcloud being the only real exception. PiHole, Dashy, an introducer for Syncthing, and StashApp all run without a hitch via Compose files dropped into Portainer. Though I am definitely going to take Docker out of the picture for the next NC install which means taking Portainer out as well.
What’s really neat to do in Portainer is set up your compose stack off a git repo and set the webhook so it fires a pull and restart on the new docker-compose.yml when you update it in git.
I don’t use Portainer much anymore, I do my compose files manually with bind mounts locally to the compose file, and if I want an interface for the docker service, I run Lazydocker on the machine over SSH.