Yeah I’m only running it because truenas scale uses it

This could be it, but I also remember reading once it might be something to do with php.ini timeout settings too

I’m still too container stupid to understand the right way to do this. I’m running it in docker under kubernetes and sometimes I don’t update nextcloud for a long time then I do a container update and it’s all fucked because of incompatible php versions of some shit.

Updating from my experience is not Russian roulette. It always requires manual intervention and drives me mad. Half the time I just wget the new zip and copy my config file and restart nginx lol.

Camera upload has been fantastic for Android, but once in a while it shits its brains out thinking there are conflicts when there are none and I have to tell it to keep local AND keep server side to make them go away.

Not trying to sell you on it, you do what works best for you. Truenas scale is an operating system built on Debian. There will be no packages for it. It’s hard to explain until you start using it. I came from VMs on truenas core for many years and it was annoying to migrate to docker but after I used it for a while I liked it a lot more. It’s hard to explain without just using it, so if you’re not into playing around and what you have works great, then great. I’ve been working with jails and VMs and containers for well over 15 years since I work in IT so I’ve played with big and small systems. There are definitely some annoyances when it comes to the VM approach.

Your data footprint would be less. Maintenance is a breeze. If you update your image and it breaks, just roll it back. Less consumption of resources. No need to divide your storage and ram for VMs. There are millions of docker images so you can start something new in seconds. And the learning curve isn’t too bad if you’re on truenas scale. Truenas core is a NAS operating system built on freebsd (Unix), and truenas scale is built on Linux. Both use ZFS for the underlying storage.

On truenas scale though it’s just tiles in a web browser, it’s super easy. And since it runs on ZFS backups are easier too. Just click your way through periodic volume snapshot tasks.

Definitely a bit of a learning curve but it’s a sleek setup once you understand.

Used to be like you, then I moved from truenas core to scale where it’s now Linux and docker instead of freebsd and iocage jails.

So docker has this concept of persistent volumes. You configure all your settings in the initial setup command (docker compose) and define persistent volumes. This way you don’t lose your data.

Here’s an example, Plex. I run Plex in docker now. So my config directory is defined as a persistent volume. If I need to update Plex, or rebuild it or whatever, the container just updates and has all the data I need via the persistent volume. If the install is messed up or whatever I just get a newer image and run the docker compose and it fires up and mounts the persistent volume and off I go.

Basically it takes away the burden of having to figure out the OS configuration. Makes backups easier - and smaller. And the things are spun up, installed, and usable in seconds.

Out of curiosity, why not? I’ve come around.

I really don’t get your meaning of my apparent silly reason. You can’t use Acronis, Veeam, or other typical backup products with ZFS. My point is this is a barrier to entry. I disagree that it’s not silly for a home user to build another expensive NAS just to do ZFS send and receive which would be the proper way.

I don’t consider backups optional.

Because you can’t use typical back product software. If you do it the right way, you’re using my ZFS send and receive to another machine running ZFS which significantly adds to cost.

But ZFS has a learning curve and limits easy backup options… but it’s worth it.

And what is HeavyScript?

Wasn’t intending to come off condescending. IMO exposing your internal network to the internet without a proper firewall is a risk, one I wouldn’t take unless I had a DMZ and a dedicated VLAN.

In addition, you’d have to be on top of patch management. And when you do that, there’s a chance of something breaking too. My preference is not to have to muck around troubleshooting my own email server when a patch window goes bad since that’s what I deal with all day anyway. There will always be zero days, I’ll just pawn that off the the big boys.

Take it from someone who’s got over 15 years experience in the field… Or not. Your call :)

You’re in for a world of hurt. Email security is a pain in the ass. I used to do this full time and I’m so glad I don’t have to anymore.

Not trying to discourage you, it’s fun, it’s cool, but it can be a real PITA.

I’m a network engineer and >15 years of experience in IT. It’s never “safe”. Not even in corporate IT. You’re a home user and it’s less likely you’ll be targeted but bad actors do comb the internet for known vulnerabilities. Patch your shit, limit exposure, enable MFA on everything. I don’t run it, but I feel slightly sketched out not behind something like a Palo Alto. But again I’m just a small potato in a big sea and I patch everything.

There will always be risk. Just do what feels right for you. Follow beat practices.