Docker containers fail to start inside LXC on TrueNAS SCALE after reboot — sysctl “ip_unprivileged_port_start reopen fd permission denied”

vasi · February 11, 2026, 11:03am

Hi everyone,

I’m running TrueNAS SCALE 25.04.2.6 and have a lxc container where I run Docker (Portainer, Nginx Proxy Manager, WireGuard, etc.).

Everything was working fine for months. After a recent reboot, Docker containers inside this container no longer start.

Docker version 28.5.2
containerd containerd.io v2.2.1
runc version 1.3.4

and after the reboot, the portainer stopped working. When I tried to restrart portainer, I get the below error

docker: Error response from daemon: failed to create task for container:
failed to create shim task: OCI runtime create failed:
runc create failed: unable to start container process:
error during container init:
open sysctl net.ipv4.ip_unprivileged_port_start file:
reopen fd 8: permission denied

I did not upgrade to the latest version of TrueNAS, as I wish to pass a dedicated GPU to the VM, which I still need to buy. The current version does support passing integracted graphics to the VM and doesn’t complain about the host needs graphics.

Can anyone help me in this regard? Thank you.

LarsR · February 11, 2026, 11:10am

sounds a lot like

github.com/opencontainers/runc

CVE-2025-52881: fd reopening causes issues with AppArmor profiles (`open sysctl net.ipv4.ip_unprivileged_port_start file: reopen fd 8: permission denied`)

opened 02:51AM - 06 Nov 25 UTC

closed 02:39PM - 17 Nov 25 UTC

cyphar

kind/bug

# TL; DR This is caused by a design flaw in AppArmor when running runc (or Dock…er/Podman/containerd) inside a nested container that has an AppArmor profile applied (the very short explanation is that AppArmor incorrectly thinks that when runc accesses `/proc/sys/...` that it is accessing `/sys/...` and it rejects the access attempt because it violates the configured AppArmor policy). We currently cannot work around this issue within runc, so other projects need to modify their AppArmor profiles to avoid this problem. As of 2025-11-17: * Incus has already been patched (in https://github.com/lxc/incus/pull/2624). You can switch to the daily builds to get a fixed version of Incus while you wait for the next release which will contain the fix (Incus 6.19). * Proxmox has released a patched version of `lxc-pve` (`6.0.5-2`) which resolves the issue. Updating to this package (or newer) will resolve the issue. * *Direct* users of LXC will still need to make use of the below workarounds (users of the default profile need to modify `/etc/apparmor.d/abstractions/lxc/container-base`, users of `lxc.apparmor.profile = generated` need to disable AppArmor or switch to the non-generated profile). The issue is being tracked in https://github.com/lxc/lxc/issues/4606. <details> <summary><h2>Outdated Workarounds</h2></summary> ## PLEASE DO NOT LEAVE COMMENTS IF THESE SOLUTIONS WORKED FOR YOU ## ## LXC Users ## This section applies to *direct* users of LXC. You need to relax the `/sys` restrictions of the AppArmor profile used for LXC containers. The simplest way is to comment out all of the `deny /sys` lines in `/etc/apparmor.d/abstractions/container-base`: ``` % sudo sed -i.old '/deny \/sys/ s/^/#/g' /etc/apparmor.d/abstractions/lxc/container-base % sudo apparmor_parser -r /etc/apparmor.d/lxc-containers % # This should've worked, but you may need to restart your LXC containers. ``` This will disable the problematic `/sys` rules. You can also be more strategic by only changing the `deny /sys/[^fdc]*{,/**} wklx` rule to `deny /sys/[^fdcn]*{,/**} wklx` (to permit the `net.ipv4.ip_unprivileged_port_start` sysctl to be written to) but this requires a bit more care. If you use `lxc.apparmor.profile = generated` then unfortunately you will need to disable AppArmor (using `lxc.apparmor.profile = unconfined`) and wait for an LXC patch that fixes their internal hardcoded AppArmor profile. (This is the same boat Proxmox users find themselves in --see that section for some additional information.) ## Incus Users ## Incus generates its own AppArmor rules which you cannot directly modify. However, Incus has already been patched (in https://github.com/lxc/incus/pull/2624) so if you switch to the daily builds then the problem should already be resolved for you. Unfortunately there is no `raw.lxc.*` workaround possible. ## Proxmox Users ## Similar to Incus, Proxmox generates its own AppArmor rules (using `lxc.appamor.profile = generated`) which you also cannot directly modify. However, Proxmox has released `lxc-pve-6.0.5-2` which includes a patch to resolve this issue. > [!NOTE] > [A bug report was opened for Proxmox](https://bugzilla.proxmox.com/show_bug.cgi?id=7006), along with [a patch](https://lore.proxmox.com/pve-devel/20251113130914.789691-1-f.gruenbichler@proxmox.com) which has been released in the repos. https://github.com/lxc/lxc/issues/4606 is tracking the issue for upstream LXC to improve its `lxc.apparmor.profile = generated` handling for nested containers. As Proxmox makes use of `lxc.apparmor.profile = generated`, the above mitigations do not work (modifying the profiles in `/etc/apparmor.d` doesn't do anything because a new profile is generated automatically based on hard-coded strings in LXC). You instead need to add the following configuration to `/etc/pve/lxc/$ctr.conf`: ``` lxc.apparmor.profile: unconfined lxc.mount.entry: /dev/null sys/module/apparmor/parameters/enabled none bind 0 0 ``` And restart the container. The `/dev/null` bind-mount is needed in order to trick Docker into thinking that AppArmor is disabled on the system. If you do not include this line, you may see the error `Error response from daemon: Could not check if docker-default AppArmor profile was loaded: open /sys/kernel/security/apparmor/profiles: permission denied`. This is caused by a non-configurable security policy within AppArmor related to namespace nesting -- the only real solution for this is for the generated profile by LXC be fixed. > [!NOTE] > The `/dev/null` bind mount may be unnecessary for some guests (some users have reported that Debian guests just work with `lxc.apparmor.profile = unconfined`). > [!NOTE] > In principle you could configure a different AppArmor profile based on `lxc-container-default-with-nesting` and use that instead, but based on my testing the default profile doesn't permit `overlayfs` mounts -- fixing that is left as an exercise for the reader. ## Regarding Downgrades ## A lot of people have commented that they will just downgrade runc. If you are going to do this (instead of the far less drastic workarounds we've outlined above), please do not go overboard. runc **1.2.7** and **1.3.2** are the latest releases that *do not* contain the security patches which caused these errors. Downgrading to earlier versions than that (especially something as old as runc 1.1.0) is overkill and is needlessly opening yourself up to 4-year-old vulnerabilities. I also want to re-iterate that while AppArmor can in principle protect against some attacks, by downgrading you are **intentionally** opening yourself up to actual attacks that we know exist (**AND CAN BYPASS APPARMOR** in the case of CVE-2025-52881). </details> <details> <summary><h2>Detailed Analysis</h2></summary> There is an issue that has been reported when running runc inside LXC where the AppArmor profile for LXC causes permission errors when we try to re-open fds for procfs operations. This was reported in https://github.com/containerd/containerd/issues/12484, https://github.com/moby/moby/issues/51405, and https://github.com/lxc/incus/issues/2623. Here is my breakdown of the cause: > Okay, I've figured it out. This is really dumb. tl;dr: This is really an AppArmor bug (or even a design flaw if you prefer). > > For context, the file we are trying to write to is `/proc/sys/net/ipv4/ip_unprivileged_port_start`. @stgraber figured out that the problematic AppArmor rules are the rules they have which block writing to most **`/sys`** files. How is it possible that one affects the other? > > Well, the problem is that runc now uses a detached mount of `procfs` to operate on (this avoids mount race attacks). Because detached mounts have not been attached to the filesystem, `d_name` (the kernel's facility for generating names for dentries) just generates a name that looks like `/foo` if you try to open a file `foo` inside the detached `procfs` mount. AFAICS this is what AppArmor uses to determine what file you are trying to write to (because AppArmor is path-based, and `d_name` is the only way to get pathnames from dentries). > > This means that when we try to write to `/proc/sys/net/ipv4/ip_unprivileged_port_start`, AppArmor sees this as us trying to write to `/sys/net/ipv4/ip_unprivileged_port_start` which is forbidden by the `/sys` denial rules. I have attached a program that can show this behaviour using a detached `tmpfs` mount, it's very trivial to trigger: > > ``` > % ./aa-bug & > c1:~ # ./aa-bug & > fd: /proc/2061/fd/5 > [1] 2061 > c1:~ # mkdir /proc/2061/fd/5/sys > c1:~ # mkdir /proc/2061/fd/5/sys/foo > mkdir: cannot create directory ‘/proc/2061/fd/5/sys/foo’: Permission denied > ``` > > [aa-bug.go.txt](https://github.com/user-attachments/files/23379918/aa-bug.go.txt) > > There is a trivial workaround for this particular sysctl: > > ``` > - deny /sys/[^fdck]*{,/**} wklx, > + deny /sys/[^fdckn]*{,/**} wklx, > ``` > > (In `/etc/apparmor.d/abstractions/lxc/container-base`.) > > But this doesn't help in the general case for all sysctls. @stgraber has just submitted https://github.com/lxc/incus/pull/2624 which just removes these rules entirely. I think AppArmor should not do this, because it's incredibly broken (literally any detached mount could match against a rule by accident), but this is unfortunately how AppArmor's design works. > > From runc's side, we could in theory use this to our advantage -- if we created a `tmpfs` with a subpath like `.go-away-apparmor` and then attached our procfs mount to that path, we might be able to subvert AppArmor. However, this has a risk of causing lifetime issues that would require a rework of how we do lookups -- the `tmpfs` must not be closed after we attach to it because it will lazy-unmount the procfs... _Originally posted by @cyphar in [#12484](https://github.com/containerd/containerd/issues/12484#issuecomment-3494405793)_ </details>

vasi · February 11, 2026, 11:30am

Thank you for the reply.

However, I did not fully understand the solution for this. I tried to go with the lxc solution, but couldn’t find the file - /etc/apparmor.d/abstractions/lxc/container-base.

And for the incus, the post says, I cannot directly modify the apparmor. However, Incus has already been patched (in lxc/incus#2624). How do I get the daily builds?

LarsR · February 11, 2026, 11:38am

Truenas uses incus as the lxc backend, you’d have to patch the incus version truenas uses, which you can’t do yourself. And since incus will be removed later this year with the truenas 26 update I doubt it will be fixed on truenas. If I remember correctly the issue started with a certain version of docker. You may be able the install an older release …

Edit:
Truenas uses incus version 6.0.4 and it was patched in 6.19

vasi · February 11, 2026, 12:22pm

Yep, downgrading containerd is the solution for now. Thank you for the advise.

Docker 28.5.2
containerd 1.7.28
runc 1.3.0

LarsR · February 11, 2026, 12:33pm

When I’m home from work I’ll probably still file a report on jira and hope that 25.10.2 will include an update to incus to patch the cve…

fgero · March 2, 2026, 7:15am

Nope.
25.10.2 here, Incus still in 6.0.4-2+deb13u4…and exactly the same error as vasi.
…and the downgrade to containerd v1 works (but it was painful…)

Topic		Replies	Views
Latest docker/containerd updates breaks Docker in Incus container Apps and Virtualization SCALE , Incus	6	1394	November 11, 2025
Update incus to at least 6.19 or newer Feature Requests	2	126	February 11, 2026
[Accepted] LXC/Incus support in TrueNAS Scale Feature Requests SCALE	22	4207	July 31, 2024
TrueNAS 24.10-RC.2 is Now Available! Announcements SCALE	127	8138	October 29, 2024
TrueNAS 25.04.0 now available! Announcements	199	7541	June 13, 2025

Docker containers fail to start inside LXC on TrueNAS SCALE after reboot — sysctl “ip_unprivileged_port_start reopen fd permission denied”

Related topics