CAP_SYS_ADMIN requirement for mounts inside user namespaces – inconsistent behavior

Direct answer

Inside a new user namespace you do hold CAP_SYS_ADMIN, but it is scoped to that user namespace. A mount succeeds only when the mount namespace is owned by that user namespace and the filesystem type is allowed for user namespaces.

Confirmed across 5.10–6.1 mainline: mount(2) first checks ns_capable(mnt_ns->user_ns, CAP_SYS_ADMIN). If the check passes, the kernel then applies filesystem rules. Filesystems marked FS_USERNS_MOUNT such as tmpfs, ramfs, fuse, and overlayfs can be mounted unprivileged inside the user namespace. Bind and remount of an existing visible, unlocked mount is generally allowed in a user-namespaced mount namespace. Block device mounts, loop device attachment, and any filesystem without FS_USERNS_MOUNT still require CAP_SYS_ADMIN in the initial user namespace.

Confirmed facts vs likely explanation

Confirmed: CAP_SYS_ADMIN is namespaced. It is not a smaller capability; the capability check is performed against the owning user namespace of the mount namespace. The set of mountable types is gated by FS_USERNS_MOUNT and by whether the mount namespace was created inside the user namespace.

Likely explanation for inconsistent behavior: EPERM is overloaded. The same error appears for different causes: mount namespace not owned by the user namespace, a non-userns-mountable filesystem, a locked inherited mount, missing loop/device access, or an LSM denial. Bind mounts can fail when the source mount was inherited locked, or when trying to clear nodev/nosuid/noexec/atime on a locked mount. Loop mounts fail because attaching a backing file to a loop device and mounting the resulting block device is not a user-namespace operation; it needs initial-namespace privilege or a pre-provisioned device and helper.

Minimal safe setup for this case

• Create both user and mount namespaces together so the mount namespace is owned by the new user namespace. Example check:

unshare -Ur -m sh -c 'grep CapEff /proc/self/status; readlink /proc/self/ns/user /proc/self/ns/mnt; mount -t tmpfs none /mnt && echo tmpfs-ok'

Success shows the namespace ownership is correct.

• Use only FS_USERNS_MOUNT filesystems and bind/remount of unlocked mounts inside the namespace. Do not attempt ext4/xfs block mounts or loop mounts without a privileged helper.
• For loop images, provision the loop device outside the namespace or use a privileged helper. Unprivileged loop is not a capability-only problem.

Version and distro effects: the core model is stable in 5.10–6.1, but backports change outcomes. FS_USERNS_MOUNT coverage, locked-mount handling, mount_setattr behavior, and unprivileged_userns_clone / user.max_user_namespaces settings are distro-specific. Mainline version alone is insufficient.

One missing diagnostic that changes the recommendation: which exact mount syscall is failing, with which errno, and on which kernel build/distro. The kernel build identifier and the exact mount command distinguish a capability/ownership problem from an LSM denial or a locked mount.