Issue httpd service failed to start after plesk 18.0.75 upgradre

[bulent]

Server operating system version

almalinux 10 on proxmox 9 lcx container

Plesk version and microupdate number

18.0.74 update 3

Plesk with almalinux 10 on proxmox 9 in lcx container failed to start httpd sevice after update to latest version.

systemd[1]: httpd.service: Main process exited, code=exited, status=226/NAMESPACE

Failed to start httpd.service - The Apache HTTP Server.

some of the errors

 

[scsa20]

Do you have any custom configs configured outside of plesk? If so try removing those custom configs. You can run sudo apachectl configtest and plesk repair web -validate-configuration to test the configs.

Looking through and providing logs will also be useful. You can refer to https://support.plesk.com/hc/en-us/...r-Linux-services-logs-and-configuration-files to find where all the log files are located at (it will also show you generic config files locations).

Otherwise you could try using Plesk repair to fix the configs (see Plesk Repair Utility: Web)

 

[Bitpalast]

status=226/NAMESPACE is a systemd failure at the “namespace setup” step, i.e. systemd tried to apply one of its sandboxing/isolation features (mount/user/tmp/dev namespaces, etc.) for httpd.service and the kernel/container runtime didn’t allow it.

In LXC containers (especially unprivileged ones on Proxmox), this is most commonly triggered after an update because the service unit gained/changed hardening options like PrivateTmp=, ProtectSystem=, ProtectHome=, PrivateDevices=, ProtectKernel*= or other namespace-related protections. Then systemd tries to set up a mount namespace and gets Permission denied, causing 226/NAMESPACE. This pattern is widely reported for services inside Proxmox LXC. (Stack Overflow)

What it usually looks like in logs​

Run this inside the container:

journalctl -u httpd -b --no-pager
systemctl status httpd -l

If you see something like “Failed to set up mount namespacing: Permission denied” or references to /run/systemd/unit-root/..., that confirms it’s the container restrictions vs. systemd sandboxing. (GitHub)

---

Likely causes in your exact setup (Plesk + AlmaLinux 10 + Proxmox 9 LXC)​

1) LXC container doesn’t allow the required namespaces/mount operations​

Proxmox LXC often needs nesting enabled (and sometimes additional allowances) for systemd services that use these protections. This is a common fix reported by Proxmox users when services start failing with 226/NAMESPACE. (Proxmox Support Forum)

Proxmox-side things to check (container config):

• Is the container unprivileged? (more likely to hit this)
• Is nesting enabled?
• Is AppArmor profile restrictive?

Typical Proxmox LXC config knobs people use:

• features: nesting=1,keyctl=1
• sometimes (as a diagnostic) lxc.apparmor.profile: unconfined (not ideal long-term, but confirms the cause)

(Exact config depends on your Proxmox version and security posture.)

2) httpd.service hardening options added/changed by update​

A package update can change /usr/lib/systemd/system/httpd.service and suddenly the unit uses options that are fine on a VM/bare metal, but not in your LXC constraints. This is exactly what many “worked before upgrade, broke after upgrade” cases boil down to. (Stack Overflow)

---

Two practical ways to fix it​

Option A (preferred): Allow the needed container features​

On Proxmox, enable the container features that let systemd do mount namespacing properly (often “nesting”). This preserves the service hardening and is the “right” direction if you want a stable platform for Plesk.

Option B (quick workaround): Override the systemd unit to disable the offending sandboxing​

Inside the container:

systemctl edit httpd

Then add a drop-in override like (you may not need all of these; start minimal):

[Service]
PrivateTmp=false
ProtectSystem=off
ProtectHome=false
PrivateDevices=false

Then:

systemctl daemon-reload
systemctl restart httpd

This matches the known resolution pattern where removing e.g. PrivateTmp=true (or related protections) eliminates 226/NAMESPACE. (Arch Linux Foren)

---

What I’d do first (fast triage)​

1. Confirm the exact failing sandbox step:
   journalctl -u httpd -b -n 200 --no-pager
   
   
2. If it says mount namespacing Permission denied, fix via Option A (container features) if you can.
3. If you need it up immediately, apply Option B (drop-in override), then circle back to a proper container config.

If you paste the last ~50 lines of journalctl -u httpd -b (especially the line that mentions “Failed to set up … namespacing”), I can tell you which specific unit directive is triggering it and the smallest safe override.