How to Enable or Disable Apparmor on Ubuntu 26.04, 24.04 and 22.04

AppArmor is enabled by default on Ubuntu because it adds mandatory access control on top of normal Linux file permissions. Most systems should keep that protection active, but temporary troubleshooting, broken third-party profiles, lab systems, and rollback work sometimes require a clear way to disable one profile or disable AppArmor globally and then turn it back on.

On Ubuntu, enabling or disabling AppArmor can mean three different things: checking whether the kernel module is active, disabling one profile with AppArmor tools, or disabling the whole framework at boot with a kernel argument. Treat those paths separately so a service-state change does not get mistaken for real profile removal.

Check AppArmor Status on Ubuntu

Start with the current AppArmor state before changing anything. These checks distinguish the kernel module, the systemd profile loader, and the loaded profile set.

cat /sys/module/apparmor/parameters/enabled
systemctl is-active apparmor
systemctl is-enabled apparmor
sudo aa-status | head -n 4

A normal enabled Ubuntu system returns Y, an active and enabled service, and an aa-status summary showing loaded profiles. Profile counts vary by release, desktop packages, snaps, and installed services.

Y
active
enabled
apparmor module is loaded.
... profiles are loaded.
... profiles are in enforce mode.

The AppArmor service is a oneshot profile loader. The active (exited) state in full systemctl status output is normal because the unit loads profiles, exits, and leaves enforcement inside the kernel. For a compact state check without volatile timestamps, inspect the unit properties directly.

systemctl show apparmor --property=LoadState,ActiveState,SubState,UnitFileState

LoadState=loaded
ActiveState=active
SubState=exited
UnitFileState=enabled

If a profile-management command such as aa-disable, aa-enforce, or aa-complain is missing, install apparmor-utils. The base AppArmor package can provide aa-status without installing the extra management helpers.

command -v aa-disable

If no path prints, install the helper package before using profile-management commands.

sudo apt update
sudo apt install apparmor-utils

These commands use sudo because AppArmor profile loading, service state, and bootloader changes require root privileges. Add your account to sudoers on Ubuntu before continuing if normal administrative commands fail.

Disable AppArmor on Ubuntu

Choose the smallest disable path that solves the problem. Disabling one profile keeps the rest of AppArmor active, while disabling AppArmor globally removes the mandatory access control layer for the whole system after a reboot.

Task	Command Path	Effect	Best For
Disable one profile	aa-disable	Immediate and profile-specific	One app or service profile is causing a confirmed issue
Disable AppArmor globally	apparmor=0 boot argument	Applies after reboot and disables AppArmor kernel mediation	Lab systems, emergency isolation, or temporary broad troubleshooting
Stop or disable the systemd unit	systemctl stop apparmor or systemctl disable apparmor	Changes loader state but can leave kernel mediation and profiles active	Rare service-loader testing, not full disablement

Do not globally disable AppArmor to fix one application unless you have already confirmed that a specific profile change is not enough. A broad disable removes confinement for unrelated desktop apps, services, snaps, and helper processes.

Disable a Single AppArmor Profile

Use sudo aa-status for the loaded profile list, then confirm the matching profile file under /etc/apparmor.d. The exact profile inventory varies by release, desktop packages, snaps, and installed applications, but the example profile used here exists across Ubuntu 22.04, 24.04, and 26.04.

ls /etc/apparmor.d/lsb_release /etc/apparmor.d/usr.bin.man /etc/apparmor.d/usr.sbin.cupsd

/etc/apparmor.d/lsb_release
/etc/apparmor.d/usr.bin.man
/etc/apparmor.d/usr.sbin.cupsd

The example disables the lsb_release profile because it is a small profile commonly present on Ubuntu systems. Replace it with the exact profile that matches your target application.

sudo aa-disable /etc/apparmor.d/lsb_release

Disabling /etc/apparmor.d/lsb_release.

AppArmor disables the profile by creating a symlink under /etc/apparmor.d/disable/. Confirm the symlink target before assuming the profile is disabled.

readlink /etc/apparmor.d/disable/lsb_release

/etc/apparmor.d/lsb_release

Disable AppArmor Globally After Reboot

Full AppArmor disablement should be deliberate and reversible. On GRUB-based Ubuntu systems, add a small drop-in that appends apparmor=0 to the kernel command line, regenerate the GRUB menu, and reboot.

sudo install -d -m 755 /etc/default/grub.d
printf '%s\n' 'GRUB_CMDLINE_LINUX="$GRUB_CMDLINE_LINUX apparmor=0"' | sudo tee /etc/default/grub.d/99-disable-apparmor.cfg > /dev/null
sudo update-grub
sudo reboot

After the reboot, verify the kernel state. A globally disabled system reports N, and aa-status cannot inspect normal profile state because the AppArmor filesystem is not mounted. In this disabled state, aa-status and systemctl is-active apparmor can return nonzero statuses while still printing the expected diagnostic text.

cat /sys/module/apparmor/parameters/enabled
sudo aa-status
systemctl is-active apparmor

N
apparmor filesystem is not mounted.
apparmor module is loaded.
inactive

Ubuntu 22.04, 24.04, and 26.04 show the same disabled signals when this boot argument is active: kernel state N, the unmounted AppArmor filesystem message from aa-status, and an inactive profile-loader service.

Do not treat systemctl stop apparmor or systemctl disable apparmor as equivalent to the boot argument. On Ubuntu, stopping the oneshot unit can make the service state read inactive while aa-status still shows profiles loaded in the kernel. Disabling the unit for boot can also leave the kernel enabled and a reduced profile set loaded by other service integrations.

Re-enable AppArmor on Ubuntu

Re-enable the same layer you disabled. A disabled profile needs its disable symlink removed and the profile reloaded. A globally disabled system needs the boot argument removed and a reboot.

Re-enable a Disabled AppArmor Profile

Remove the disable symlink, reload the profile into the kernel, and place it back into enforce mode.

sudo rm -f /etc/apparmor.d/disable/lsb_release
sudo apparmor_parser -r /etc/apparmor.d/lsb_release
sudo aa-enforce /etc/apparmor.d/lsb_release

Setting /etc/apparmor.d/lsb_release to enforce mode.

Confirm the profile appears in the loaded profile list again.

sudo aa-status | head -n 12

Re-enable AppArmor After a Global Disable

Remove the GRUB drop-in that added apparmor=0, regenerate GRUB, make sure the AppArmor service is enabled for boot, and reboot.

sudo rm -f /etc/default/grub.d/99-disable-apparmor.cfg
sudo update-grub
sudo systemctl enable apparmor
sudo reboot

After the reboot, confirm AppArmor returned to the normal enabled state.

cat /sys/module/apparmor/parameters/enabled
systemctl is-active apparmor
systemctl is-enabled apparmor
sudo aa-status | head -n 4

Y
active
enabled
apparmor module is loaded.
... profiles are loaded.
... profiles are in enforce mode.

Troubleshoot AppArmor Enable and Disable Issues

aa-disable or aa-enforce Command Not Found

Install apparmor-utils when helper commands are missing. Ubuntu can still have AppArmor enabled even when those profile-management tools are not installed.

sudo apt update
sudo apt install apparmor-utils

AppArmor Still Looks Enabled After systemctl stop or disable

This is expected on Ubuntu. The AppArmor service loads profiles and exits, while enforcement remains in the kernel. Disabling the service at boot can reduce the loaded profile set, but it is still not the same as booting with AppArmor disabled. Use aa-disable for one profile or the apparmor=0 boot argument for a global disable.

sudo systemctl stop apparmor
systemctl is-active apparmor
cat /sys/module/apparmor/parameters/enabled
sudo aa-status | head -n 3
sudo systemctl start apparmor

inactive
Y
apparmor module is loaded.
... profiles are loaded.
... profiles are in enforce mode.

AppArmor Stays Disabled After Re-enabling the Service

If cat /sys/module/apparmor/parameters/enabled still prints N, the kernel is still booting with apparmor=0. Check the live kernel command line, remove the remaining boot argument from GRUB or another bootloader configuration source, regenerate the boot menu, and reboot.

cat /proc/cmdline

A Profile Does Not Load After Re-enabling

Parse the profile before loading it. Syntax errors, stale paths, or a broken local edit can prevent AppArmor from accepting the profile.

sudo apparmor_parser -Q /etc/apparmor.d/lsb_release
sudo apparmor_parser -r /etc/apparmor.d/lsb_release

Ubuntu 24.04 or 26.04 Sandbox Errors Are Different

Ubuntu 24.04 and 26.04 can restrict unprivileged user namespaces through AppArmor. Errors involving kernel.apparmor_restrict_unprivileged_userns, Electron sandboxes, browser sandboxes, or terminal sandbox startup are not the same as disabling AppArmor globally.

sysctl kernel.apparmor_restrict_unprivileged_userns

kernel.apparmor_restrict_unprivileged_userns = 1

Ubuntu 24.04 and 26.04 normally return 1. Ubuntu 22.04 normally returns 0, so the sandbox-specific branch usually points to a newer Ubuntu system or a custom policy change rather than a normal 22.04 AppArmor disablement issue.

A temporary diagnostic change can use sudo sysctl -w kernel.apparmor_restrict_unprivileged_userns=0, but capture the original value first and restore it after testing unless the package vendor documents that setting as the supported workaround. Persistent fixes should prefer the package’s supported profile, package source, or upstream guidance. Canonical’s AppArmor user namespace restriction guidance explains that newer sandbox behavior in detail.

original_userns=$(sysctl -n kernel.apparmor_restrict_unprivileged_userns)
sudo sysctl -w kernel.apparmor_restrict_unprivileged_userns=0
sudo sysctl -w kernel.apparmor_restrict_unprivileged_userns="$original_userns"

kernel.apparmor_restrict_unprivileged_userns = 0
kernel.apparmor_restrict_unprivileged_userns = 1

The restore command returns the value captured before the test. On Ubuntu 24.04 and 26.04 that normally means returning to 1; on a system that started at 0, the restore command returns it to 0 instead.

Do Not Purge AppArmor Just to Disable It

Removing the apparmor package is a rougher change than disabling a profile or using a reversible boot argument. Purging AppArmor can remove Ubuntu’s default security tooling and create package-management side effects without giving you a cleaner rollback path.

Official AppArmor References

• Ubuntu AppArmor wiki for Ubuntu-specific AppArmor background.
• AppArmor project site for upstream project information.
• AppArmor documentation for profile syntax and deeper policy work.

Related Ubuntu Security Tasks

• Configure UFW on Ubuntu when network filtering also matters.
• Check your Ubuntu version before applying release-specific AppArmor troubleshooting.

Conclusion

AppArmor is either active again with profiles loaded, or intentionally disabled through a reversible boot drop-in that you can remove later. For most Ubuntu systems, keep global AppArmor enabled and disable only the confirmed problem profile while you troubleshoot. That preserves the rest of Ubuntu’s application confinement instead of turning off a system-wide security layer.