Linux Audit Framework · Event AVC
SELinux: avc denied — a policy blocked something
SELinux refused an operation that ordinary file permissions would have allowed. The message names the process, what it wanted, and what it wanted it on — in SELinux's own vocabulary of labels, which is the only genuinely hard part of reading it.
Also written as avc: deniedtype=AVC selinux deniedselinux denial logsetroubleshoot avc denied
- How oftenFires regularly
- Vendor calls itaudit
- Logaudit
What it means for you
For an analyst
Read scontext, tcontext and tclass together — the source label, the target label, and the kind of object — because that triple is what a policy rule actually matches on and it is what any fix has to address. Two things worth knowing. Denials can be silenced by dontaudit rules, so a genuinely blocked operation can produce nothing at all; 'semodule -DB' turns those off temporarily and frequently reveals the denial people were looking for. And permissive=1 in the record means the operation was allowed and only logged, which is the single most common reason people conclude SELinux is broken when it is actually in permissive mode.
The fields that decide it
Everything else in the log line is context.
- scontext
- The security label of the process that was denied, in user:role:type:level form. The type — the third part, ending in _t — is the part that matters.
- tcontext
- The label of the thing it was denied access to. Comparing this against what the policy expects is usually where the answer is.
-
default_t or unlabeled_tThe file has no meaningful label, which almost always means it was created or moved somewhere the policy does not expect. A relabel fixes it. -
A type from a different serviceContent placed in another service's directory, or moved rather than copied so it kept its old label. -
The expected type for the serviceThe label is right and the policy genuinely does not permit this operation. Needs a policy change, not a relabel. - tclass
- What kind of object — file, dir, tcp_socket, capability. Denials on tcp_socket or capability classes are not fixed by relabelling anything and are a different conversation entirely.
- permissive
- Whether SELinux actually blocked it.
-
permissive=0Enforcing. The operation was blocked. -
permissive=1Permissive. The operation was allowed and merely logged. Nothing was actually prevented. - comm and path
- The short process name and the object it wanted. Together with the labels this usually identifies the misconfiguration outright.
Common questions
How do I fix an SELinux avc denied error?
Work out first whether the label is wrong or the policy is. If the file is in an unexpected place or was moved rather than copied, its label is wrong and 'restorecon -Rv <path>' fixes it — this is the answer most of the time. If the label is correct and the policy genuinely does not allow the operation, you need a policy module, which audit2allow can generate from the denial. Never reach for 'setenforce 0' as a fix; that disables the control rather than resolving anything.
Should I use audit2allow to make the error go away?
Only after understanding what it is about to allow. audit2allow writes a rule permitting exactly what was denied, which is fine when the denial is a genuine policy gap and dangerous when the denial was correct. Read the generated rule before loading it. If it grants something broad, that is a sign the underlying problem is a mislabelled file rather than a missing policy.
Why do I see no AVC denial even though something is clearly being blocked?
Because of dontaudit rules, which suppress denials the policy authors considered noise. Run 'semodule -DB' to disable them, reproduce the problem, and the missing denial usually appears. Remember to run 'semodule -B' afterwards to put them back, or your audit log will fill with the noise they were suppressing.
What does permissive=1 mean in an AVC record?
That SELinux logged the denial but allowed the operation anyway, because the system or that specific domain is in permissive mode. Nothing was blocked. This catches people out regularly: they see denials, assume SELinux is causing their problem, and spend time on it when the real cause is elsewhere. Check 'getenforce' before investigating any denial.
Read next
- Read alongside auditd type=SYSCALL: the record everything else hangs off The SYSCALL record attached to the same event, which gives the process identity and the return value.
- Read alongside auditd type=PATH: which file the operation actually touched The PATH records naming the files involved.
- Related auditd type=CONFIG_CHANGE: the audit rules themselves changed Changes to the audit configuration, which govern whether these records are captured.
- Usually comes after Failed to start: a systemd service did not come up A service failing to start, which is what an SELinux denial usually looks like before you find the denial.
Mentioned by
Vendor documentation
Last reviewed 6 September 2026