Dennis HilkLinux Fix LabDE

SSH, Security & Permissions

AppArmor blocks an application operation

An AppArmor denial names the profile and operation that were blocked. Check the intended path before adding a narrowly reviewed rule.

Editorial source review: Start with the evidenceShare this guide
On this page
  1. Symptoms & scope
  2. Possible causes
  3. Diagnose safely
  4. Evidence-guided next steps
  5. References & review
  6. Related problems

Symptoms & scope

  • One application cannot access a path available to the account.
  • Kernel audit records include apparmor="DENIED".

Relevant environment

AppArmor-enabled Linux; full profile status and kernel audit logs can require administrator read access.

Recognizable messages (synthetic examples)
audit: type=1400 apparmor="DENIED" operation="open" profile="/usr/bin/example" name="/srv/example/data" denied_mask="r"

The profile and named path narrow the investigation; Unix permissions can still be a separate restriction.

audit: type=1400 apparmor="DENIED" operation="sendmsg" profile="/usr/bin/example" family="inet" sock_type="stream" denied_mask="send"

Inspect the profile’s network rules and intended destination before treating this as a connectivity outage.

Possible causes

These are possible explanations, not a confirmed diagnosis. Several independent faults can coexist.

  • The application may have moved to a path outside its profile’s allowed locations.
  • An updated program may require an operation absent from its installed profile.

Diagnose safely

Run one command at a time in the relevant session. Read the explanation first. Uppercase placeholders need your own values; tools and privileges vary by distribution. These commands are displayed here and never executed by the website.

Check 1

Reads this boot’s kernel denials; use an account allowed to read the kernel journal.

journalctl -k -b --no-pager --grep='apparmor="DENIED"'

Interpret the result: Correlate profile, operation, name and denied_mask with the failing action. No visible denial does not rule out explicit deny rules or incomplete logs.

Check 2

Lists loaded profiles and their modes; administrator read privileges may be necessary.

aa-status

Interpret the result: An enforcing profile can block access. Complain mode generally logs permitted violations; inspect the exact profile instead of assuming all profiles behave alike.

Evidence-guided next steps

Use a path already allowed by the profile

If the application was pointed at an unintended custom path, restore its documented data or configuration location. Move data only through a supported migration with a backup, and recheck the operation against the named profile.

Precautions: Preserve application ownership and ordinary permissions; AppArmor does not replace those checks.

Recovery / rollback: Restore the application’s saved path setting and data backup if the migration must be undone.

Did this solution help you?

Share this solution#

Add a reviewed minimal local profile rule

If the blocked action is legitimate, review the exact event with aa-logprof and add only its necessary path and access in a supported local include. Back up the include first, reload the single affected profile and check that it remains enforcing.

Precautions: Do not approve every suggestion or disable AppArmor globally. Network denials need network rules, not a broad file wildcard.

Recovery / rollback: Restore the saved local include and reload the same profile; remove only the rule added for this investigation.

Did this solution help you?

Share this solution#

References & review

This guide was prepared from primary project or distribution sources and reviewed on the date shown. This is an editorial source check, not evidence that a fix was reproduced on your hardware. Diagnostic log examples are synthetic fixtures. Version-dependent details must be checked against your installed release.