The guide explains how to manage Ubuntu 22.04’s AppArmor security system by checking its status with systemctl, toggling individual profiles into “complain” mode using aa-complain (and later back to enforcement with aa-enforce) for selective debugging, and completely stopping or masking the AppArmor daemon via systemctl stop/mask when broader troubleshooting is needed. It also shows how to restore protection by unmasking, starting, and enabling the service at boot. Additionally, it warns common mistakes such as forgetting to reload edited profiles with apparmor_parser -r or using masking for temporary stops. A concise cheat‑sheet of commands for each action rounds out the tutorial.

Enable & Disable AppArmor on Ubuntu 22.04 LTS

If you’ve ever been locked out of a program because its AppArmor profile went rogue, this guide will show you how to flip those profiles on and off without rebooting into recovery mode. By the end you’ll know exactly which commands to run, where the config lives, and why each step matters.

What is AppArmor and why would I touch it?

AppArmor is Ubuntu’s built‑in Mandatory Access Control system. It wraps programs in a sandbox and says “you may read this file, but not that one.” Most of the time it works silently, but after a kernel update or a misbehaving third‑party app you’ll see errors like “Permission denied (apparmor)” in syslog. I’ve seen it happen after installing Docker’s latest version – the container tried to mount a directory and AppArmor threw a fit.

Quick check: is AppArmor running?

Open a terminal and type:

sudo systemctl status apparmor.service

If you see active (running) you’re good. If it says inactive or failed, the service is already down – no need to waste time enabling it again.

Disabling a single profile

Sometimes you only need to relax one program, not shut down the whole framework.

1. Find the exact profile name

   sudo aa-status | grep "loaded profiles"
   

   The output lists something like usr.bin.firefox. Knowing the full path avoids disabling the wrong thing.

2. Put the profile into complain mode

   sudo aa-complain /etc/apparmor.d/usr.bin.firefox
   

   Complain lets the program run unrestricted while AppArmor logs violations. This is safer than a hard disable because you can still see what would have been blocked.

3. Verify the change

   sudo aa-status | grep "complaining"
   

   You should now see your profile listed under “complain mode”.

Why complain? It gives you a chance to review the audit log (/var/log/syslog or journalctl -k) and decide whether you need a custom rule instead of turning protection off completely.

Disabling the entire AppArmor subsystem

If you’re troubleshooting a batch of apps that all break after an update, you can stop the service. Remember: this removes a layer of security, so turn it back on as soon as you’ve verified everything works.

sudo systemctl stop apparmor.service

The command stops the daemon immediately; any processes already confined stay in their current state until they exit. To make sure nothing restarts it automatically, mask the unit:

sudo systemctl mask apparmor.service

Masking creates a symbolic link to /dev/null, preventing any other service from pulling AppArmor back up.

Re‑enabling AppArmor

When you’re ready to bring the guard back:

1. Unmask (if you masked it)

   sudo systemctl unmask apparmor.service
   

2. Start and enable at boot

   sudo systemctl start apparmor.service
   sudo systemctl enable apparmor.service
   

   enable writes a symlink into the appropriate run‑level directory so the daemon launches on every boot.

3. Put any previously complained profiles back to enforce mode

   sudo aa-enforce /etc/apparmor.d/usr.bin.firefox
   

   This restores the original confinement rules for that program.

Common pitfalls

• Forgot to reload after editing a profile – after tweaking /etc/apparmor.d/... you must run sudo apparmor_parser -r /path/to/profile. Skipping this leaves the old version active.
• Masking instead of disabling – masking is overkill if you just want a temporary stop. A simple systemctl stop lets the service start again on reboot without extra unmask steps.

TL;DR cheat sheet

Action	Command
Check status	sudo systemctl status apparmor.service
Disable whole thing (stop)	sudo systemctl stop apparmor.service
Prevent auto‑start (mask)	sudo systemctl mask apparmor.service
Re‑enable (unmask + start)	sudo systemctl unmask apparmor.service && sudo systemctl start apparmor.service && sudo systemctl enable apparmor.service
Put one profile into complain mode	sudo aa-complain /etc/apparmor.d/<profile>
Return that profile to enforce	sudo aa-enforce /etc/apparmor.d/<profile>

That’s it. Play around, break a few things, and then lock them down again – that’s how you learn what AppArmor really does.