Fix 'Operation not permitted' Linux Mount Error (EPERM)

That error's a real pain, especially when you know the command is right. Let's get you unblocked.

The Quick Fix

If you're in a container or a restricted user session, the fix is usually one of these:

Use sudo – if you're not root, try sudo mount /dev/sdb1 /mnt. You'd be surprised how often that's all it is.
Check your namespace – if you're in a container, you might not have CAP_SYS_ADMIN. Run capsh --print and look for it. If it's missing, you need to start the container with --cap-add SYS_ADMIN (Docker) or adjust your systemd-nspawn settings.
Reboot your system – sounds dumb, but a stale mount namespace can cause this. A reboot clears it.

After you run the mount command again, you should see the filesystem mounted. Check with mount | grep /mnt or df -h /mnt. If you still get the error, move on to the next section.

Why It Happens

Linux has a security model that restricts mounting to processes with CAP_SYS_ADMIN in the right namespace. Even root in a container lacks that cap unless explicitly granted. The kernel checks this before letting you mount anything, and throws EPERM when you don't have it.

Also, since systemd became the default init, user sessions run in private mount namespaces. If you're trying to mount from a GUI terminal without proper privileges, the kernel sees you're not in the init namespace and denies you. The sudo fix works because it re-enters the root namespace and has the caps.

Check Your Caps Directly

Run this to see what your current shell can do:

capsh --print

Look for Current: = cap_sys_admin,cap_... If cap_sys_admin isn't listed, that's your problem.

Less Common Variations

Sometimes the standard fixes don't work because the cause is different. Here are a few I've seen in the wild:

1. Read-Only Mount Point

If the mount point directory itself is read-only (like on a read-only root filesystem), you'll get EPERM. Check with:

mount | grep ' / '

If it says ro, remount it read-write: mount -o remount,rw / – but be careful on production systems.

2. Filesystem-Specific Issues

Some filesystems like squashfs can't be mounted if the kernel module isn't loaded. The error might be EPERM instead of the usual ENODEV. Load it manually:

modprobe squashfs

Then try the mount again.

3. AppArmor or SELinux

These security modules can block mounts even for root. Check your logs:

dmesg | tail -20

If you see avc denials, you'll need to adjust your policy. For a quick test, you can temporarily disable SELinux with setenforce 0 (then re-enable after). AppArmor might require aa-complain /usr/bin/mount.

Prevention

The real fix is to set up your environment correctly from the start. Here's what I tell my junior techs:

If you're a developer running containers, always include --cap-add SYS_ADMIN when you need to mount inside them. Document it in your docker-compose file so it's not a surprise.
For systemd users, add MountFlags=shared to your service unit if it needs to mount. This prevents namespace isolation from biting you.
Keep your mount commands simple – avoid complex options unless you really need them. The more flags you pass, the more chances for a permission check to fail.
If you're on an NFS or FUSE setup, check that your user has the right entry in /etc/fstab with the user option. Otherwise you'll hit this every time.

With those in place, you won't see EPERM again. If you do, you'll know exactly where to look.