TL;DR
If your AOSP build fails with:
[E] initCloneNs(): mount('/', '/', NULL, MS_REC|MS_PRIVATE, NULL): Permission denied
it almost always means your system is blocking unprivileged user namespaces under AppArmor. Set:
sudo sysctl kernel.apparmor_restrict_unprivileged_userns=0
echo 'kernel.apparmor_restrict_unprivileged_userns=0' | sudo tee -a /etc/sysctl.conf
sudo sysctl --system
Re-run the build. Done.
Note: This article is the quick workaround (set kernel.apparmor_restrict_unprivileged_userns=0). For a least-privilege fix that keeps the host at =1 and grants userns only for nsjail via AppArmor, see
What this post is (and isn’t)
- This is about the host OS (Ubuntu 24.04, kernel 6.8 series) restricting unprivileged user namespaces, which nsjail needs.
- It’s not tied to a specific AOSP version. You’ll hit it whenever your build actually runs nsjail (e.g., Trusty/AVF-related targets or tools wrapped by nsjail).
Symptoms you’ll see
- During
m, a target wrapped by nsjail fails with:
[E] initCloneNs(): mount('/', '/', NULL, MS_REC|MS_PRIVATE, NULL): Permission denied
[F] runChild(): Launching child process failed
- Sometimes earlier you may notice:
Build sandboxing disabled due to nsjail error.
(Soong occasionally “degrades gracefully”, but certain targets call nsjail directly and will hard-fail.)
Why it happens
Ubuntu 24.04 ships /usr/lib/sysctl.d/10-apparmor.conf setting:
kernel.apparmor_restrict_unprivileged_userns = 1
That blocks mounts inside unprivileged user namespaces, which nsjail relies on (e.g., MS_PRIVATE remount).
Quick checks
sysctl -n kernel.apparmor_restrict_unprivileged_userns # 1 = blocked (likely cause)
One–minute fix (host build)
Apply immediately and persist across reboots:
# Take effect now
sudo sysctl kernel.apparmor_restrict_unprivileged_userns=0
# Persist (read last, overrides any *.d)
echo 'kernel.apparmor_restrict_unprivileged_userns=0' | sudo tee -a /etc/sysctl.conf
# Reload all sysctl settings
sudo sysctl --system
# Verify
sysctl -n kernel.apparmor_restrict_unprivileged_userns # should print 0
FAQ
Q: Is lowering this setting “unsafe”?
A: It relaxes an AppArmor safeguard for unprivileged user namespaces. For dedicated build hosts, this is a common and pragmatic trade-off. If you’re on a multi-tenant machine with strict security requirements, consider building in a controlled container/VM with only the required permission scope.
Q: Why did this suddenly start failing?
A: Either (1) your build configuration started invoking a target that actually runs nsjail (e.g., Trusty/AVF), exposing the restriction, or (2) system updates ensured the restrictive sysctl was (re)applied. Using /etc/sysctl.conf ensures your override always wins.
Q: Can I make it temporary?
A: Yes, run only:
sudo sysctl kernel.apparmor_restrict_unprivileged_userns=0
It will revert to 1 after reboot unless persisted.