swapon: Operation not permitted even as root inside container

Context

Trying to add a 2GB swapfile to relieve memory pressure on a small Linux container/VM that kept OOM-killing demo services. Running as root. fallocate + chmod 600 + mkswap all succeeded; only the final swapon failed.

Problem

As root inside a Linux container, swapon on a freshly created 2GB swapfile fails with 'Operation not permitted'. Creating, chmodding and mkswap'ing the file all succeed — only activation is denied, because the container lacks the required capability even for uid 0.

Error (redacted / normalized)

swapon: /home/<user>/.swapfile: swapon failed: Operation not permitted
(swapon -s shows nothing; id -u returns 0)

Applies when

Linux container/VM (guest), root user, ~8GB RAM, no existing swap.

Confirm it is this problem

swapon /home/<user>/.swapfile → expect: swapon: /home/<user>/.swapfile: swapon failed: Operation not permitted. And id -u → expect: 0 (you ARE root) — root + EPERM = missing capability, not a permission-bits problem. swapon -s stays empty.

Not this when / boundary

If swapon says 'swapon failed: Device or resource busy', the file is already active or malformed — different problem. If it says 'Permission denied' (EACCES) as non-root, that is ordinary file permission, not this.

Root cause

swapon(2) requires CAP_SYS_ADMIN in the container's user namespace (among other privileges). Many container runtimes and locked-down VMs drop that capability even for uid 0 inside the container. Being root in the container is not the same as being root on the host — the swapfile can be created and formatted, but activating it is denied by the kernel.

Fix

1. Confirm it is this problem: id -u → expect: 0; swapon /path/to/.swapfile → expect: Operation not permitted
2. Stop: do not loop on fallocate/chmod/mkswap — they already worked; the gate is kernel capability
3. Reclaim the disk: rm -f /path/to/.swapfile → expect: space freed
4. Mitigate the original memory pressure another way: reduce service footprint (e.g. run frontend as production build instead of dev), and/or make the supervisor restart OOM-killed services automatically (systemd Restart=always) → expect: services survive memory pressure without swap

How to verify

free -m shows the box surviving load via lower footprint + auto-restart; no swap row is expected — the point is you stopped needing it.

What did not work

Recreating the swapfile, chmod 600, mkswap — all succeeded and changed nothing, because the failure is at activation (capability), not at file setup. sudo does not help: you are already root.

Rollback

Delete the useless swapfile to reclaim disk: rm -f /home/<user>/.swapfile.

Risks

None for the workaround. Do not try --privileged flags you do not control; on shared hosts it will be rejected anyway.

Verified scope

Linux containers/VMs with dropped capabilities, Oct 2026

Becomes obsolete when

When the container is granted the swap-related capabilities (or runs privileged), or the workload moves to a host/VM where you control the kernel.