The same inode can appear with different ownership through two mount points without any recursive chown(). Linux idmapped mounts attach an ID mapping to a mount, so VFS ownership presentation and permission checks can translate user and group IDs for that view while the ownership stored by the filesystem remains unchanged.

This property separates persistent inode metadata from the identity view exposed at a particular mount. It is especially useful when a filesystem tree must be shared with a container whose user namespace maps IDs differently from the host.

The mapping belongs to the mount

An idmapped mount carries an ID mapping derived from a user namespace. mount_setattr() applies it with MOUNT_ATTR_IDMAP, using userns_fd to identify the namespace that supplies the mapping.

The mapping is not written into every inode. A second mount of the same filesystem can retain its ordinary identity mapping and continue to report the original ownership. The remapping is localized to the idmapped mount and lasts with that mount.

This is materially different from:

chown -R 100000:100000 tree/

A recursive ownership rewrite mutates filesystem metadata, touches each affected inode, and changes what every mount observes. An idmapped mount changes the ownership interpretation at a VFS boundary instead.

Ownership crosses several ID domains

Filesystem permission checks cannot treat a numeric UID as globally meaningful. A caller has IDs interpreted through its user namespace, an inode has ownership represented in the filesystem’s ID domain, and an idmapped mount can add another translation between them.

Conceptually, a path lookup through an idmapped mount involves a relationship like:

caller identity
      |
caller user namespace
      |
mount ID mapping
      |
filesystem ownership domain
      |
inode uid/gid

Kernel VFS helpers perform the required translations when ownership is reported or permission decisions are made. The exact internal representation is an implementation concern; the architectural property is that permission logic receives the mount mapping rather than pretending the raw inode ID is already in the caller’s identity domain.

An ID outside the configured mapping cannot be translated normally. Such gaps therefore matter when a mapping covers only a selected range.

Permission checks use the translated ownership

The feature is not merely cosmetic output for stat(). VFS operations that support idmapped mounts use the mount mapping in ownership-sensitive checks and metadata changes.

Suppose files on disk are owned by a host ID that corresponds to UID 0 inside a container’s user namespace. Exposing the tree through a suitable idmapped mount can make those files appear owned by the container identity and allow ownership-based checks to operate with that translated relationship. The ordinary host mount can still expose the original host ownership.

This avoids a common conflict in container storage: shifting ownership on disk for one container can make the same tree inconvenient for the host or another container using a different mapping. Per-mount translation lets separate views coexist without repeatedly rewriting the tree.

Idmapping does not bypass mode bits, ACL policy, LSM decisions, mount flags, or other access-control layers. It changes the identity values used where the VFS explicitly applies the mount mapping.

Metadata containing IDs also needs mapping semantics

UID and GID fields are not the only filesystem metadata that can contain identities. POSIX ACL entries may carry user or group IDs, and some file capability formats carry a root user ID.

Idmapped-mount support therefore extends beyond the values printed as inode owner and group. Supported VFS paths translate relevant identity-bearing metadata so its meaning remains coherent with the mount’s ownership view.

This also defines a boundary for filesystem implementations. A filesystem must support idmapped mounts correctly; user space cannot assume that attaching an arbitrary mapping is valid for every filesystem. mount_setattr() can reject MOUNT_ATTR_IDMAP when the underlying filesystem does not support it.

Creating the mapping has explicit constraints

The classic mount_setattr() path does not permit arbitrary mutation of an already visible mount into a new identity view. The mount used for this operation is a detached mount created from a cloned mount tree, commonly through open_tree() with OPEN_TREE_CLONE.

The caller also needs the required administrative capability in the user namespace associated with the filesystem mount, and the filesystem must support idmapped mounts. The mount must satisfy the kernel’s writer and state constraints for the operation.

A typical control flow is therefore:

existing mount
     |
open_tree(..., OPEN_TREE_CLONE)
     |
detached mount fd
     |
mount_setattr(..., MOUNT_ATTR_IDMAP, userns_fd)
     |
move_mount(...)
     |
idmapped view becomes visible

This sequence makes the identity transformation part of constructing a mount view rather than an unrestricted metadata mutation on a live hierarchy.

The mapping of an idmapped mount is also not a mutable policy knob that can simply be replaced in place. Applications should treat the chosen mapping as part of the mount object’s identity and construct a new mount view when a different mapping is required.

Containers avoid recursive ownership shifting

Rootless and user-namespaced containers often use non-identity mappings. For example, container UID 0 may correspond to a nonzero host UID range. Without mount-level remapping, a storage tree prepared for one ID range may require recursive ownership changes before another identity domain can use it naturally.

Recursive chown() has costs beyond execution time. It mutates persistent metadata, can create large write amplification on trees with many inodes, changes observable ownership for other users of the filesystem, and complicates sharing the same data between mappings.

An idmapped mount keeps the persistent ownership stable and moves the translation to access time. That makes the lifetime of the alternate ownership view explicit: remove the mount, and the alternate view disappears without a reverse ownership rewrite.

The mechanism does not make unrelated container mappings automatically compatible. The configured ranges still need to map the identities required by the workload, and permissions outside those ranges remain constrained by normal mapping and access rules.

The security boundary remains the filesystem access path

Idmapped mounts alter identity interpretation; they do not grant a process authority unrelated to that mapping. A container cannot use an idmapped view as a generic path to host privilege. Namespace capabilities, VFS permission checks, LSM policy, filesystem restrictions, and mount topology still participate in the access decision.

The distinction matters when evaluating a deployment. A statement such as “the files appear owned by root in the container” describes a translated view, not a claim that the inode became host-root-owned or that container root gained host-root authority.

The durable property is narrower and more useful: a mount can present filesystem ownership through a selected ID mapping, and VFS operations that support the mechanism apply that mapping consistently to ownership-sensitive behavior. This gives container and storage systems a localized identity boundary without converting ownership adaptation into a bulk inode rewrite.

Software Engineering Linux Filesystems Containers