Welcome the new Virtualmin Podman Plugin

Alright, Discourse SMTP can now be configured directly on its recipe deployment page in expand Email delivery → SMTP settings sub-section.

When Mail for domain is enabled, Virtualmin automatically fills the SMTP hostname, port, encryption, username, sender address, and, when available, the mailbox password. Replace any <USERNAME> or <PASSWORD> placeholder. You can also enter credentials from an external SMTP provider.

And, as you mentioned that before, after deployment, SMTP values can be changed under Manage Container Apps → Containers → Discourse web application container → Environment variables.

Also, note, that local Virtualmin SMTP routing from the Podman pod is handled automatically.

Lastly, you can test delivery in Discourse → Admin → Email settings → Server settings → Send test email.

Please let me know if it works for you this time.

app.yml belongs to the traditional discourse_docker launcher workflow. Our plugin runs the Discourse image directly with Podman, so there is no app.yml and equivalent DISCOURSE_* settings are container environment variables.

Alas, after updating the podman plugin, I still see the same 24 vars I had before, whcih do not include the ones needed. Maybe I did something wrong.

Also, after server reboots, my containerized apps are down: all of my Podman containers were showing as “Missing” in Webmin because they weren’t starting back up on their own. Even though lingering was active and the containers were set to “unless-stopped”, they weren’t restarting because Debian and Ubuntu don’t always include podman-restart.service in the user systemd templates by default. We fixed it by creating a standard podman-restart.service unit inside /etc/systemd/user/ and running systemctl --global enable podman-restart.service, which immediately got all rootless containers starting automatically on boot across every domain user.

I don’t know how universal of a problem that might be. I think I’ve solved it for my server with AI assitance to set a global policy to restart all containers after reboot, but letting you know - especially if others run into the same issue.

That said, I’ve been slow to play with all of the available containers because I’ve spent time on these issues, but I’m still quite excited for this and will be playing around with more containers. I will never stop saying thank you <3 But not just this, but Virtualmin has brought back the joy in hosting that died years ago with cPanel stupidity. heh

Like which vars do you expect to see? To be clear, just updating the webmin-virtualmin-podman package won’t make any changes to your currently deployed containers. You would have to either delete and reinstall it or manually edit the container’s env vars as I explained in my previous comment.

Thanks, that’s right, and I’m aware of it. Still, I’m not sure what the best way to solve it would be. I’ll update this ticket with progress on this particular issue…

And I will always be thankful for your kind words and for using our product! Thank you!

Alright, going forward the containers will restart correctly whenever the system reboots. Appreciate you pointing this out!

If you’re using the development Virtualmin repo/branch, everything should just work out of the box.

I don’t know why it took me so long to realize, but to add/edit the environmental variables, click on the container name in the list of containers. So I hope this helps anyone else who can’t figure this stuff out.

It’s incredibly easy… once you realize that’s where to go.

I’m happy to report that my SMTP settings are now working, and if ever I need to adjust a container’s vars, now I understand where and how to do that.

I’m incredibly appreciative of your patience with me.

Hi Ilia,

Sorry it took me a bit of time to run my first test, I had a lot going on.
Finally got to it, and here’s what I found.

I tested the Compose import with your phpBB example files first — worked perfectly, clean import, both services running as expected.

Then I tried importing my own wg-easy stack (WireGuard VPN, single service). As expected from the earlier discussion, the import rejected container_name, sysctls, and cap_add — I removed all three and the import succeeded fine, including a bind mount outside the domain home (/lib/modules, read-only) after enabling the two advanced overrides.

The problem: without NET_ADMIN and SYS_MODULE, WireGuard can’t create its network interface (RTNETLINK answers: Operation not permitted). The README mentions “Extra Linux capability controls” as a feature, so I expected to add these capabilities after import via the Edit Container page — but I don’t see any capability field there. I checked every section (port mappings, host volume mapping, environment variables, inspect metadata) and there’s nothing for capabilities.

Is this field just not exposed on the edit screen for imported containers, or is capability editing not implemented yet? Any workaround in the meantime (should I recreate manually with podman run and the right flags, keeping the same name/labels so the module still picks it up)?

Happy to share full logs/config if useful.

Thank you for your feedback! I really appreciate it!

“Extra capabilities” control is available in the “Privileged and host access” panel when enabled in the module configuration under “Podman Containers ⇾ Module Config: User interface settings ⇾ Visible panels on container create and edit pages”.

We wanted to keep it simpler from the start, long before I came up with adding recipes, so we only exposed basic controls by default.

Please let me know if that works for you.

Thanks for pointing me to the “hidden” configuration, capabilities are now editable and working.

Went further with a first test (wg-easy - WireGuard) and hit a real blocker: it needs actual NET_ADMIN/iptables access, which only works in rootful mode. Switched the container to rootful, and the import then failed with:

netavark: error while applying dns entries: IO error: aardvark-dns failed to start
Error starting server failed to bind udp listener on 10.89.0.1:53: IO error: Address already in use (os error 98)

Turns out my server runs BIND for DNS zones (default/standard with Virtualmin), and it’s listening on all interfaces including every bridge Podman creates. In rootful mode, aardvark-dns also wants port 53 on its new bridge and loses the race. Digging around, this appears to be a known upstream Podman limitation (containers/podman#15452 among others). Podman’s own docs confirm there’s no way to run aardvark-dns on a non-standard port yet, and the fix is to bind the host DNS server to specific IPs instead of “any”.

To be clear, this only bit me on the one service that needed rootful (real network/iptables access). My earlier phpBB test import, fully rootless, worked without any DNS conflict at all. So this isn’t a “every import breaks” issue. It’s specific to services that need rootful mode for kernel-level networking, which I’d guess is a minority case (VPNs, reverse proxies doing their own iptables, that kind of thing).

Have you run into this with Virtualmin + BIND + rootful containers? Curious if there’s a known-good way to configure BIND’s listen-on around it, since I’d guess anyone running Virtualmin’s default DNS alongside a rootful import that needs its own network will hit the same wall.

Two more small things while I was in there:

1. False “unsaved changes” warning on save
Saving changes under Module Config → “Privileged and host access” and “Container list columns” (User interface settings) triggers the browser’s “leave page / changes won’t be saved” warning — but the save actually goes through fine. A bit confusing since it implies the save might have failed.

2. Raw HTML tags in Runtime mode selector
On “Import Compose Stack” → “Import Behavior”, the Runtime mode dropdown shows literal tags instead of rendering them: Domain user (<tt>rootful</tt>) instead of formatted “rootful”. Looks like the <tt> isn’t being stripped in that select element.

Happy to share screenshots or logs for any of these.

You’d just set BIND under “Servers → BIND DNS Server → Addresses and Topology” to listen only on explicit host IPs, excluding Podman bridge addresses. We should not modify global DNS automatically in any way, if that’s what you’re asking/suggesting.

Thanks! This is a known theme bug that should already be fixed in the latest development version. We will push a Webmin update soon to address this and other small issues.

Please install the latest development build and let me know if the issue is fixed for you.