In general, container root filesystems and the images backing them will not function on NFS. When deploying containers, you should be mounting data volumes into the containers rather than storing things on the container root filesystems. Hopefully you are already doing that, otherwise you’re going to need to manually copy data out of the containers. Personally, if all you’re talking about is 32 gigs max, I would just stop all of the containers, copy everything to the new NFS locations, and then re-create the containers to point at the new NFS locations.

All this said though, some applications really don’t like their data stored on NFS. I know Plex really doesn’t function well when it’s database is on NFS. But, the Plex media directories are fine to host from NFS.

Check out minisforum, for example this intel mini-pc. They have a ton of selection, not just that one example.

From the article, “These systems range from ground-based lasers that can blind optical sensors on satellites to devices that can jam signals or conduct cyberattacks to hack into adversary satellite systems.”

Recently LTT built a $100k PC desk for a Minecraft streamer. Sometimes the over the top engineering/materials (and thus cost) around something is the entire point. If they gave it a fair shake, and still called it a bad product, and then returned it. There wouldn’t be an issue. It being a bad product isn’t the issue.

In the LastPass case, I believe it was a native Plex install with a remote code execution vulnerability. But still, even in a Linux container environment, I would not trust them for security isolation. Ultimately, they all share the same kernel. One misconfiguration on the container or an errant privilege escalation exploit and you’re in.

You are not being overly cautious. You should absolutely practice isolation. The LastPass hack happened because one of their engineers had a vulnerable Plex server hosted from his work machine. Honestly, next iteration of my home network is going to probably have 4 segments. Home/Users, IOT, Lab, and Work.

Keep in mind, RAID is fault tolerant, not fault proof. For critical data, keep in mind the 3-2-1 rule. Stored in 3 locations, 2 separate mediums, 1 offsite.

I’ll second this. 4k at 25 mbps might be OK for a sitcom or drama without much action or on-screen movement. But as soon as there’s any action, it’s gonna be a pixelated mess. 25 mbps is kinda the sweet spot for full fidelity 1080p, and I’d much rather watch that than “4K”.

No thanks!

At it’s most basic, a satellite will have two systems. A highly robust command and control system with a fairly omnidirectional antenna. And then the more complex system that handles the payload(s). So yea, if the payload system crashes, you can restart it via C&C.

Annoying yes, but I’d argue that’s likely the simplest and most performant approach. At best (IPTables NAT), you’d be adding in an extra network hop to your SMB connections which would effect latency, and SMB is fairly latency sensitive especially for small files. And at worst (Traefik), you’d adding in a user-space layer 7 application that needs to forward every bit of traffic going over your SMB connection.

PS. Also to confirm since you mention LetsEncrypt, you aren’t planning to expose your smb server over the internet are you?

I have a feeling routing SMB traffic through Traefik is going to be a performance and latency nightmare. Is your TrueNAS VM’s network interface bridged to your home network? If so, use a static IP and just have clients connect directly. If not, your best bet is likely iptables NAT to forward a port from your Proxmox servers IP to the TrueNAS VM.