Yeah, it’s amazing how upvoted the previous comment is. Just a bunch of idiots jumping on the web-hate bandwagon when even basic media players like Kodi have a tough time playing back video on the Pi.

It just isn’t a very optimized device for video playback. The Pi 5 is actually a step backwards as well, providing only H265 hardware video decode which the web doesn’t even use.

LOL, same. I did a docker-compose pull and restarted, came here to look at the release notes, and almost started panicking whether I omitted some important upgrade steps. Turns out everything upgraded smoothly automatically though.

Interesting solution! Thanks for the info. Seems like Nginx Proxy Manager doesn’t support Proxy Protocol. Lmao, the world seems to be constantly pushing me towards Traefik all the time 🤣

I see. And the rest of your services are all exposed on localhost? Hmm, darn, it really looks like there’s no way to use user-defined networks.

I am guessing you’re not running Caddy itself in a container? Otherwise you’ll run into the same real IP issue.

I see! So I am assuming you had to configure Nginx specifically to support this? Problem is I love using Nginx Proxy Manager and I am not sure how to change that to use socket activation. Thanks for the info though!

Man, I often wonder whether I should ditch docker-compose. Problem is there’s just so many compose files out there and its super convenient to use those instead of converting them into systemd unit files every time.

Yeah, I thought about exposing ports on localhost for all my services just to get around this issue as well, but I lose the network separation, which I find incredibly useful. Thanks for chiming in though!

Pasta is the default, so I am already using it. It seems like for bridge networks, rootlesskit is always used alongside pasta and that’s the source of the problem.

Man, I have GOT to try Truenas Scale one of these days. I see it recommended so often, but I was just too used to a standard Linux ecosystem to bother learning something new. I am assuming it gets you closer to the feel of a pre-built NAS during administration tasks compared to Cockpit and a SSH session lmao.

I think I am just always afraid of being locked into a specific way of doing things by a vendor. I feel like I would get annoyed if something that I could do easily on standard Linux was harder to do on Truenas Scale.

I have zero trust in QNAP. QNAP knowingly sold several NASes with a known clock-drift defect in their Intel J1900 CPUs and then refused to provide any support. A bunch of community members had to figure out how to solder a resistor to temporarily revive their bricked NASes in order to retrieve their data. https://forum.qnap.com/viewtopic.php?t=135089

I had a TS-453 Pro and my friend had a TS-451. Both mine and his exhibited this issue and refused to boot. After this debacle and the extreme apathy from their support, I vowed to never buy a pre-built NAS.

You shouldn’t trust ANY brand’s pre-installed OS when it comes to your personal data to be honest.

The preloaded spyware OS

Nowhere in that video did it say this. I am all for DIY NAS and I have an Arch-based one at home, but saying this while implying that that’s what the source video you linked said is a bit disingenuous.

To be honest, nothing about this UGREEN is any different from any of the other off-the-shelf NAS solutions out there like QNAP, Synology, etc. If you don’t trust the UGREEN pre-installed OS, you shouldn’t trust any of the other ones either. I am not saying you should, but my point is that this pretty par for the course as far as pre-built NASes go.

Most companies do not provide support if you install a custom OS. That isn’t a sign of vendor lock-in, just a matter of keeping support feasible in the long-term, especially since they’re relatively new at this. If you want a custom OS, it is far easier and cheaper to just build your own.

I use podman with the podman-docker compatibility layer and native docker-compose. Podman + podman-docker is a drop-in replacement for actual docker. You can run all the regular docker commands and it will work. If you run it as rootful, it behaves in exactly the same way. Docker-compose will work right on top of it.

I prefer this over native Docker because I get the best of both worlds. All the tutorials and guides for Docker work just fine, but at the same time I can explore Podman’s rootless containers. Plus I enjoy it’s integration with Cockpit.

Cockpit definitely has the ability to create bridge devices. I haven’t found a tutorial specifically for cockpit, but you can follow something like this and apply the same principles to the “Add Bridge” dialog in Cockpit’s network settings.

Your containers show up in Cockpit under the “Podman containers” section and you can view logs, type commands into their consoles, etc. You can even start up containers, manage images, etc.

Are there any tutorials on how to do this from Cockpit?

I have not done this personally, but I would assume you need to create a bridge device in Network Manager or via Cockpit and then tell your VM to use that. Keep in mind, bridge devices only work over Ethernet.

I am using it as a migration tool tbh. I am trying to get to rootless, but some of the stuff I host just don’t work well in rootless yet, so I use rootful for those containers. Meanwhile, I am using rootless for dev purposes or when testing out new services that I am unsure about.

Podman also has good integration into Cockpit, which is nice for monitoring purposes.

It isn’t that much better. I use it as drop-in docker replacement. It’s better integrated with things like cockpit though and the idea is that it’s easier to eventually migrate to rootless if you’re already in the podman ecosystem.

podman-compose is different from docker-compose. It runs your containers in rootless mode. This may break certain containers if configured incorrectly. This is why I suggested podman-docker, which allows podman to emulate docker, and the native docker-compose tool. Then you use sudo docker-compose to run your compose files in rootful mode.

If you use firewalld, both docker and podman apply rules in a special zone separate from your main one.

That being said, podman is great. Podman in rootful mode, along with podman-docker and docker-compose, is basically a drop-in replacement for Docker.

Thanks! Yeah i am already using a nginx reverse proxy in a docker container to expose my other docker containers so I was thinking two reverse proxies in a row might be too inefficient. Will definitely look into nftables. Nftable rules are temporary though right? What’s the correct way to automate running these rules on boot?