[SweetAndLow]

✍️ Description

(Drafted with AI assistance using Gemini 3.8 Flash, Reasoning Level: High)

In unprivileged Ubuntu 24.04 LXC containers on modern Proxmox kernels (6.8+), systemd-journald repeatedly triggers AppArmor audit denials when attempting to forward datagrams to rsyslog over the /run/systemd/journal/dev-log socket:

apparmor="DENIED" operation="sendmsg" class="file" namespace="root//lxc-XXX_<-var-lib-lxc>" profile="rsyslogd" name="/run/systemd/journal/dev-log" comm="systemd-journal"

Because unprivileged containers cannot reload host AppArmor profiles (apparmor_parser), this cannot be resolved via local profile overrides from inside the container.

Furthermore, rsyslog is completely redundant in this container:

• systemd-journald manages all system logs natively (journalctl).
• Plex Media Server writes directly to its own application logs (Plex Media Server.log).

Changes

1. install/plex-install.sh: Masks rsyslog and disables syslog.socket immediately after container initialization (before update_os), preventing AppArmor denials right from first boot and during the apt installation phase.
2. ct/plex.sh: Adds an idempotent check (systemctl is-active --quiet rsyslog) in update_script() to cleanly disable and mask rsyslog on existing container deployments when updated.

🔗 Related Issue

Fixes #

✅ Prerequisites (x in brackets)

• Self-review completed – Code follows project standards.
• Tested thoroughly – Changes work as expected.
• No security risks – No hardcoded secrets, unnecessary privilege escalations, or permission issues.

Tested on: PVE 9.2 (Kernel 7.0.2-6-pve) / Ubuntu 24.04 LXC (Unprivileged) / fresh install + update verification

---

🤖 AI Assistance (X in brackets)

If you used an AI tool (GitHub Copilot, Claude, ChatGPT, etc.) to write or generate any scripts in this PR, you must confirm compliance below.
Select exactly one option.

• No AI used – Scripts were written without AI assistance.
• AI was used – I confirm the scripts were built using AGENTS.md and .github/agents/pve-script-creator.agent.md as guidance, and the output has been reviewed and corrected to match those guidelines.

---

🛠️ Type of Change (X in brackets)

• 🐞 Bug fix – Resolves an issue without breaking functionality.
• ✨ New feature – Adds new, non-breaking functionality.
• 💥 Breaking change – Alters existing functionality in a way that may require updates.
• 🆕 New script – A fully functional and tested script or script set.
• 🌍 Website update – Changes to script metadata (PocketBase/website data).
• 🔧 Refactoring / Code Cleanup – Improves readability or maintainability without changing functionality.
• 📝 Documentation update – Changes to README, AppName.md, CONTRIBUTING.md, or other docs.

---

💥 Breaking Change Advisory (only if you checked "Breaking change")

[github-actions]

Try this branch

The engine and the scripts resolve independently, so this runs the changed
ct/ and install/ scripts against the production engine:

export COMMUNITY_SCRIPTS_URL=https://raw.githubusercontent.com/SweetAndLow/ProxmoxVE/main
bash -c "$(curl -fsSL "$COMMUNITY_SCRIPTS_URL/ct/plex.sh")"

Both lines are needed. Without COMMUNITY_SCRIPTS_URL the engine falls back to
main, so curling the branch URL on its own gives you the ct/ script from
this PR and the install/ script from main. Frequently the one you meant to test.

The same command works on an Incus host: the engine detects the platform and
loads the matching backend, while the scripts still come from this branch.

Useful while testing

dev_mode=net logs every fetch with status and URL, which is the quickest way
to confirm the branch is really being used. dev_mode=keep stops a failed
build from deleting the container along with the evidence.

export COMMUNITY_SCRIPTS_URL=https://raw.githubusercontent.com/SweetAndLow/ProxmoxVE/main
dev_mode=net,keep bash -c "$(curl -fsSL "$COMMUNITY_SCRIPTS_URL/ct/plex.sh")"

[MickLesk]

#11998

[SweetAndLow]

@MickLesk Thanks for taking a look. I understand the perspective that this originates from Ubuntu's stock packaging, but I’d like to share why this specifically impacts this script and why upstream won't resolve it:

1. Interaction with Unprivileged LXCs: Upstream Ubuntu and Canonical package rsyslog assuming standard kernel capabilities (or a VM / privileged container). In our environment, the Plex script deliberately deploys an unprivileged LXC container, where rsyslog is denied permission to read /proc/kmsg, resulting in recurring permission errors and log spam.

2. Upstream Won't Fix It: Canonical considers unprivileged container limitations an edge case for base images that include traditional syslog daemons. They won't adjust Ubuntu's default services for downstream unprivileged LXC environments.

3. Consistency Across the Project: Many community scripts already clean up or disable redundant or broken services inside unprivileged containers to ensure clean journal logs and avoid unnecessary background failures. Since systemd-journald is already handling logging inside the container, rsyslog is superfluous here (notably, Debian base images have already dropped rsyslog entirely for this reason).

Because the decision to deploy unprivileged is made by the script, handling this cleanup directly in the install script ensures users get a clean, error-free deployment out of the box without noisy system log failures.

Would you be open to reconsidering if we keep the fix minimal, or alternatively, considering a migration of the Plex script to a Debian base in the future?

[MickLesk]

If upstream treats this as expected behavior for unprivileged containers and won't change it, that's not a reason for us to work around it. It means it's how the Ubuntu template behaves. We don't patch around distro or kernel behavior in individual install scripts.

On consistency: when scripts clean up, it's at the application level (build leftovers, unused packages). This is about how the host kernel's AppArmor handles the guest's rsyslog profile. It's a different layer, and not something an installer should interfere with.

The workaround is documented in #11998 for anyone who wants it.

[SweetAndLow]

Switch to Debian a possibility?

[MickLesk]

Official Plex force Ubuntu. You can switch by your own. But there are no support from us.