mount_setattr(2)

✨ NAME ✨

mount_setattr — change properties of a mount or mount tree

Ok bestie, this is the mount_setattr(2) page, like, the Linux system call manual. Buckle up, part 1 of 4, there's a LOT here and it's all important. 💅

---

💖 LIBRARY 💖

Standard C library (libc, -lc)

---

🦋 SYNOPSIS 🦋

#include <fcntl.h>       /* Definition of AT_* constants */
#include <sys/mount.h>

int mount_setattr(int dirfd, const char *path, unsigned int flags,
                  struct mount_attr *attr, size_t size);

---

🌸 DESCRIPTION 🌸

So, mount_setattr() is part of the whole suite of file-descriptor-based mount facilities in Linux. It's giving modern, it's giving fd-based, it's iconic. 👑

What it does: it changes the mount properties of a mount or of an entire mount tree. Yes ma'am, whole tree if you want.

Now, path resolution 101, because this matters. If path is relative, then it's interpreted relative to the directory referred to by the file descriptor dirfd. And if dirfd is the special value AT_FDCWD, then path is interpreted relative to the current working directory of the calling process. Also!! If path is the empty string and AT_EMPTY_PATH is specified in flags, then the mount properties of the mount identified by dirfd are the ones getting changed. (If you're sitting there like "why is the dirfd argument even useful", go read openat(2) for that whole explanation.)

mount_setattr() uses an extensible structure (struct mount_attr) so the kernel can add stuff later without breaking everything. Any non-flag extensions to mount_setattr() will be implemented as new fields appended to this here structure, and a zero value in a new field makes the kernel behave as though that extension field was never even there. Which means: the caller MUST zero-fill this structure on initialization. Non-negotiable bestie. See the "Extensibility" subsection under NOTES for the whole tea.

About size: it should usually be sizeof(struct mount_attr). BUT — and this is lowkey clever — if you're using a kernel that supports an extended struct mount_attr, and you don't intend to use those new features, you can pass the size of an earlier version of the structure together with the extended structure. That way the kernel doesn't have to copy the later parts of the structure that aren't used anyway. Efficient. ✨ With each extension that changes the size of struct mount_attr, the kernel will expose a definition of the form MOUNT_ATTR_SIZE_VERnumber. For example, the macro for the size of the initial version of struct mount_attr is MOUNT_ATTR_SIZE_VER0. Cute, right?

The flags argument can be used to alter the pathname resolution behavior. The supported values are:

• AT_EMPTY_PATH — If path is the empty string, change the mount properties on dirfd itself.
• AT_RECURSIVE — Change the mount properties of the entire mount tree. 🌈
• AT_SYMLINK_NOFOLLOW — Don't follow trailing symbolic links.
• AT_NO_AUTOMOUNT — Don't trigger automounts.

The attr argument of mount_setattr() is a pointer to a mount_attr structure, described in mount_attr(2type).

So the attr_set and attr_clr members are the ones used to specify the mount properties that are supposed to be set or cleared for a mount or mount tree. Flags set in attr_set enable a property on a mount or mount tree, and flags set in attr_clr remove a property from a mount or mount tree. Simple as that.

Here's the order of operations, and the order really matters: when changing mount properties, the kernel will first clear the flags specified in the attr_clr field, and then set the flags specified in the attr_set field.

For example, these settings:

struct mount_attr attr = {
    .attr_clr = MOUNT_ATTR_NOEXEC | MOUNT_ATTR_NODEV,
    .attr_set = MOUNT_ATTR_RDONLY | MOUNT_ATTR_NOSUID,
};

are equivalent to the following steps:

unsigned int current_mnt_flags = mnt->mnt_flags;

/*
 * Clear all flags set in .attr_clr,
 * clearing MOUNT_ATTR_NOEXEC and MOUNT_ATTR_NODEV.
 */
current_mnt_flags &= ~attr->attr_clr;

/*
 * Now set all flags set in .attr_set,
 * applying MOUNT_ATTR_RDONLY and MOUNT_ATTR_NOSUID.
 */
current_mnt_flags |= attr->attr_set;

mnt->mnt_flags = current_mnt_flags;

As a result of this change, the mount or mount tree (a) is read-only; (b) blocks the execution of set-user-ID and set-group-ID programs; (c) allows execution of programs; and (d) allows access to devices. Four for four, we love to see it. 💖

Also good to know: multiple changes with the same set of flags requested in attr_clr and attr_set are guaranteed to be idempotent after the changes have been applied. Do it once, do it ten times, same result. Periodt.

The following mount attributes can be specified in the attr_set or attr_clr fields:

• MOUNT_ATTR_RDONLY — If set in attr_set, makes the mount read-only. If set in attr_clr, removes the read-only setting if set on the mount.
• MOUNT_ATTR_NOSUID — If set in attr_set, causes the mount not to honor the set-user-ID and set-group-ID mode bits and file capabilities when executing programs. If set in attr_clr, clears the set-user-ID, set-group-ID, and file capability restriction if set on this mount.
• MOUNT_ATTR_NODEV — If set in attr_set, prevents access to devices on this mount. If set in attr_clr, removes the restriction that prevented accessing devices on this mount.
• MOUNT_ATTR_NOEXEC — If set in attr_set, prevents executing programs on this mount. If set in attr_clr, removes the restriction that prevented executing programs on this mount.
• MOUNT_ATTR_NOSYMFOLLOW — If set in attr_set, prevents following symbolic links on this mount. If set in attr_clr, removes the restriction that prevented following symbolic links on this mount. 🦋
• MOUNT_ATTR_NODIRATIME — If set in attr_set, prevents updating access time for directories on this mount. If set in attr_clr, removes the restriction that prevented updating access time for directories. Note that MOUNT_ATTR_NODIRATIME can be combined with other access-time settings and is implied by the noatime setting. All other access-time settings are mutually exclusive.
• MOUNT_ATTR__ATIME - changing access-time settings — okay so the access-time values listed below are an enumeration that includes the value zero, expressed in the bits defined by the mask MOUNT_ATTR__ATIME.

Even though these bits are an enumeration (in contrast to the other mount flags such as MOUNT_ATTR_NOEXEC), they are nonetheless passed in attr_set and attr_clr for consistency with fsmount(2), which introduced this behavior. Consistency is the vibe. 🎀

⚠️ Note this carefully, bestie: since the access-time values are an enumeration rather than bit values, a caller wanting to transition to a different access-time setting cannot simply specify the access-time setting in attr_set, but must also include MOUNT_ATTR__ATIME in the attr_clr field. The kernel will verify that MOUNT_ATTR__ATIME isn't partially set in attr_clr (i.e., either all bits in the MOUNT_ATTR__ATIME bit field are either set or clear), and that attr_set doesn't have any access-time bits set if MOUNT_ATTR__ATIME isn't set in attr_clr.

• MOUNT_ATTR_RELATIME — When a file is accessed via this mount, update the file's last access time (atime) only if the current value of atime is less than or equal to the file's last modification time (mtime) or last status change time (ctime).

To enable this access-time setting on a mount or mount tree, MOUNT_ATTR_RELATIME must be set in attr_set and MOUNT_ATTR__ATIME must be set in the attr_clr field.

• MOUNT_ATTR_NOATIME — Do not update access times for (all types of) files on this mount.

To enable this access-time setting on a mount or mount tree, MOUNT_ATTR_NOATIME must be set in attr_set and MOUNT_ATTR__ATIME must be set in the attr_clr field.

• MOUNT_ATTR_STRICTATIME — Always update the last access time (atime) when files are accessed on this mount.

To enable this access-time setting on a mount or mount tree, MOUNT_ATTR_STRICTATIME must be set in attr_set and MOUNT_ATTR__ATIME must be set in the attr_clr field.

• MOUNT_ATTR_IDMAP — If set in attr_set, creates an ID-mapped mount. The ID mapping is taken from the user namespace specified in userns_fd and attached to the mount. 👑

Since it is not supported to change the ID mapping of a mount after it has been ID mapped, it is invalid to specify MOUNT_ATTR_IDMAP in attr_clr.

For further details, see the subsection "ID-mapped mounts" under NOTES.

The propagation field is used to specify the propagation type of the mount or mount tree. This field either has the value zero, meaning leave the propagation type unchanged, or it has one of the following values:

• MS_PRIVATE — Turn all mounts into private mounts.
• MS_SHARED — Turn all mounts into shared mounts.
• MS_SLAVE — Turn all mounts into dependent mounts.
• MS_UNBINDABLE — Turn all mounts into unbindable mounts.

For further details on the above propagation types, see mount_namespaces(7).

---

⭐ RETURN VALUE ⭐

On success, mount_setattr() returns zero. 🎉 On error, -1 is returned and errno is set to indicate the error.

Part 1 done, but we are SO not finished — the rest of the tea is coming in the next parts. Don't go anywhere bestie 💜

💀 ERRORS 💀

okay bestie, when this syscall ghosts you, it leaves a lil note behind in errno. here's the whole roster of possible moods it can be in 🫶

• EBADF — you gave a relative path but dirfd is neither AT_FDCWD nor an actual valid file descriptor. like girl, that fd is not fd-ing 💀
• EBADF — userns_fd is not a valid file descriptor.
• EBUSY — you tried to flip the mount to MOUNT_ATTR_RDONLY, but the mount is still holding files open for writing. rude of them tbh. can't lock it down while people are still writing ✋
• EBUSY — you tried to create an ID-mapped mount by raising MOUNT_ATTR_IDMAP and specifying userns_fd, but the mount still holds files open for writing. same energy, different flag.
• EINVAL — the pathname you specified via the dirfd and path arguments to mount_setattr() isn't a mount point. that's not a mount bestie, that's just a path 🙈
• EINVAL — an unsupported value was set in flags.
• EINVAL — an unsupported value was specified in the attr_set field of mount_attr.
• EINVAL — an unsupported value was specified in the attr_clr field of mount_attr.
• EINVAL — an unsupported value was specified in the propagation field of mount_attr.
• EINVAL — more than one of MS_SHARED, MS_SLAVE, MS_PRIVATE, or MS_UNBINDABLE was set in the propagation field of mount_attr. pick ONE vibe, not four 😭
• EINVAL — an access-time setting was specified in the attr_set field without MOUNT_ATTR__ATIME being set in the attr_clr field.
• EINVAL — MOUNT_ATTR_IDMAP was specified in attr_clr. that one is not clearable, soz 💅
• EINVAL — a file descriptor value was specified in userns_fd which exceeds INT_MAX. too big, too bold.
• EINVAL — a valid file descriptor value was specified in userns_fd, but the file descriptor did not refer to a user namespace. wrong namespace, wrong girl ✨
• EINVAL — the underlying filesystem does not support ID-mapped mounts. it simply doesn't serve that 🍓
• EINVAL — the mount that is to be ID mapped is not a detached mount; that is, the mount has not previously been visible in a mount namespace.
• EINVAL — a partial access-time setting was specified in attr_clr instead of MOUNT_ATTR__ATIME being set. half a setting is not a setting bestie 💀
• EINVAL — the mount is located outside the caller's mount namespace. not your namespace, not your business 🔥
• EINVAL — the underlying filesystem has been mounted in a mount namespace that is owned by a noninitial user namespace.
• ENOENT — a pathname was empty or had a nonexistent component. it's giving nothing. literally nothing. ✨
• ENOMEM — when changing mount propagation to MS_SHARED, a new peer group ID needs to be allocated for all mounts without a peer group ID set. this allocation failed because there was not enough memory to allocate the relevant internal structures. ran out of memory, ran out of luck 😭
• ENOSPC — when changing mount propagation to MS_SHARED, a new peer group ID needs to be allocated for all mounts without a peer group ID set. this allocation failed because the kernel has run out of IDs. the kernel said "no more IDs, I'm full" 🫠
• EPERM — one of the mounts had at least one of MOUNT_ATTR_NOATIME, MOUNT_ATTR_NODEV, MOUNT_ATTR_NODIRATIME, MOUNT_ATTR_NOEXEC, MOUNT_ATTR_NOSUID, or MOUNT_ATTR_RDONLY set and the flag is locked. permission said no, periodt. mount attributes become locked on a mount if:
  • a new mount or mount tree is created causing mount propagation across user namespaces (i.e., propagation to a mount namespace owned by a different user namespace). the kernel will lock the aforementioned flags to prevent these sensitive properties from being altered. 🔒
  • a new mount and user namespace pair is created. this happens for example when specifying CLONE_NEWUSER | CLONE_NEWNS in unshare(2), clone(2), or clone3(2). the aforementioned flags become locked in the new mount namespace to prevent sensitive mount properties from being altered. since the newly created mount namespace will be owned by the newly created user namespace, a calling process that is privileged in the new user namespace would—in the absence of such locking—be able to alter sensitive mount properties (e.g., to remount a mount that was marked read-only as read-write in the new mount namespace). keeping it locked for a reason, iykyk 👑
• EPERM — a valid file descriptor value was specified in userns_fd, but the file descriptor refers to the initial user namespace.
• EPERM — an attempt was made to add an ID mapping to a mount that is already ID mapped. it's already got one, hun 🎀
• EPERM — the caller does not have CAP_SYS_ADMIN in the initial user namespace. no cap, literally.

---

🌈 STANDARDS 🌈

Linux. that's it, that's the standard 💅

---

🦋 HISTORY 🦋

Linux 5.12, glibc 2.36. vintage-ish but honestly iconic ✨

✨ NOTES ✨

🌈 ID-mapped mounts

ok so this is the part everyone opens the page for, bestie. 💅 Making an ID-mapped mount = you can change the ownership of every single file under a mount. Like, all of them. At once. And here's the slay: it's a temporary and localized situation.

Localized because the ownership glow-up is only visible through that one specific mount 🫶 — every other user and every other place the filesystem is hanging out? Completely unaffected. Iconic, no collateral damage.

Temporary because the ownership changes are tied to the lifetime of the mount. Mount dies, changes die. It's giving mayfly. 🦋

Whenever callers interact with the filesystem through an ID-mapped mount, the ID mapping of the mount gets applied to the user and group IDs hanging off filesystem objects. That covers:

• the user and group IDs attached to inodes, and
• these xattr(7) keys:
  • security.capability, whenever filesystem capabilities are stored or returned in the VFS_CAP_REVISION_3 format — that's the one that stores a root user ID right alongside the capabilities (peep capabilities(7) 💖).
  • system.posix_acl_access and system.posix_acl_default, whenever user IDs or group IDs get stored in ACL_USER or ACL_GROUP entries.

---

To create an ID-mapped mount, these conditions must all be met. All of them. No skipping, bestie. 💀

• The caller must have the CAP_SYS_ADMIN capability in the user namespace the filesystem was mounted in.
• The underlying filesystem must support ID-mapped mounts. Currently, the following filesystems do:
  • xfs(5) (since Linux 5.12)
  • ext4(5) (since Linux 5.12)
  • FAT (since Linux 5.12)
  • btrfs(5) (since Linux 5.15)
  • ntfs3 (since Linux 5.15)
  • f2fs (since Linux 5.18)
  • erofs (since Linux 5.19)
  • overlayfs (ID-mapped lower and upper layers supported since Linux 5.19)
  • squashfs (since Linux 6.2)
  • tmpfs (since Linux 6.3)
  • cephfs (since Linux 6.7)
  • hugetlbfs (since Linux 6.9)
• The mount must not already be ID-mapped. Which also means: the ID mapping of a mount cannot be altered. Ever. Pick a lane, it's permanent for that mount. 🙈
• The mount must not have any writers. Silence the crowd first. 🔇
• The mount must be a detached mount — i.e. it has to have been created by calling open_tree(2) with the OPEN_TREE_CLONE flag, and it must not already have been visible in a mount namespace. (Or, putting it another way: the mount must not have been attached to the filesystem hierarchy with a system call like move_mount(2).) It has to be fresh, unposted, not-yet-main-character. ✨

ID mappings can be created for user IDs, group IDs, and project IDs. An ID mapping is essentially a mapping of a range of user or group IDs into another (or the same!) range of user or group IDs.

ID mappings get written to map files as three numbers separated by white space:

1. the first two numbers specify the starting user or group ID in each of the two user namespaces
2. the third number specifies the range of the ID mapping

For example, a mapping for user IDs like "1000 1001 1" would say: user ID 1000 in the caller's user namespace maps to user ID 1001 in its ancestor user namespace. And since the map range is 1, only user ID 1000 is mapped. Just the one. Solo. ⭐

You can specify up to 340 ID mappings for each ID mapping type. And if any user IDs or group IDs are not mapped? Every file owned by that unmapped user or group ID will show up as being owned by the overflow user ID or overflow group ID respectively. (iykyk 😭)

Further details on setting up ID mappings live in user_namespaces(7).

In the common case, the user namespace you pass in userns_fd (together with MOUNT_ATTR_IDMAP in attr_set) to create an ID-mapped mount will be the user namespace of a container. Other times it'll be a dedicated user namespace tied to a user's login session, exactly like the portable home directories in systemd-homed.service(8). And honestly? It is also perfectly fine to create a dedicated user namespace just for the sake of ID mapping a mount. Do it. Treat yourself. 💅

ID-mapped mounts can be useful in the following and a variety of other scenarios:

• Sharing files or filesystems between multiple users or multiple machines, especially in complex scenarios. For example, ID-mapped mounts are what implement portable home directories in systemd-homed.service(8), where they let users move their home directory onto an external storage device and use it on multiple computers where they're assigned different user IDs and group IDs. This effectively makes it possible to assign random user IDs and group IDs at login time. 🎲
• Sharing files or filesystems from the host with unprivileged containers. This lets a user avoid having to change ownership permanently through chown(2).
• ID mapping a container's root filesystem. Users don't need to permanently change ownership through chown(2). Especially for large root filesystems, using chown(2) can be prohibitively expensive. 💸
• Sharing files or filesystems between containers with non-overlapping ID mappings.
• Implementing discretionary access (DAC) permission checking for filesystems lacking a concept of ownership.
• Efficiently changing ownership on a per-mount basis. In contrast to chown(2), changing ownership of large sets of files is instantaneous with ID-mapped mounts. This is especially useful when the ownership of an entire root filesystem of a virtual machine or container is to be changed as mentioned above. With ID-mapped mounts, a single mount_setattr() system call will be sufficient to change the ownership of all files. One call. Periodt. 👑
• Taking the current ownership into account. ID mappings specify precisely what a user or group ID is supposed to be mapped to. This contrasts with the chown(2) system call, which cannot by itself take the current ownership of the files it changes into account — it simply changes the ownership to the specified user ID and group ID. No thoughts, head empty. 🍓
• Locally and temporarily restricted ownership changes. ID-mapped mounts make it possible to change ownership locally, restricting the ownership changes to specific mounts, and temporarily, since the ownership changes only apply as long as the mount exists. By contrast, changing ownership via the chown(2) system call changes the ownership globally and permanently.

---

🔧 Mount attributes and filesystem parameters

Some mount attributes (traditionally associated with mount(8)-style options) have a sibling filesystem parameter with superficially similar user-facing behavior. Example: the -o ro option to mount(8) can refer to the "read-only" filesystem parameter, or the "read-only" mount attribute. Both of these result in mount objects becoming read-only, but bestie, they do have different behavior. 🙈

The distinction between these two kinds of option is:

• mount object attributes are applied per-mount-object — which allows different mount objects derived from a given filesystem instance to have different attributes
• filesystem instance parameters ("superblock flags" in kernel-developer parlance 💜) apply to all mount objects derived from the same filesystem instance

When using mount(2), the line between these two types of mount options was blurred. However, with mount_setattr() and fsconfig(2), the distinction is made much clearer. Mount attributes are configured with mount_setattr(), while filesystem parameters are configured using fsconfig(2). Clean separation, we love a glow-up. ✨

---

🧬 Extensibility

In order to allow for future extensibility, mount_setattr() requires the user-space application to specify the size of the mount_attr structure that it is passing. By providing this info, it's possible for mount_setattr() to give both forwards- and backwards-compatibility, with size acting as an implicit version number. (Because new extension fields will always be appended, the structure size will always increase.) This extensibility design is very similar to other system calls like perf_setattr(2), perf_event_open(2), clone3(2) and openat2(2). Same vibe, same family. 👑

Let usize be the size of the structure as specified by the user-space application, and let ksize be the size of the structure which the kernel supports. Then there are three cases to consider:

• If ksize equals usize, then there is no version mismatch and attr can be used verbatim. ✅
• If ksize is larger than usize, then there are some extension fields that the kernel supports which the user-space application is unaware of. Because a zero value in any added extension field signifies a no-op, the kernel treats all of the extension fields not provided by the user-space application as having zero values. This provides backwards-compatibility.
• If ksize is smaller than usize, then there are some extension fields which the user-space application is aware of but which the kernel does not support. Because any extension field must have its zero values signify a no-op, the kernel can safely ignore the unsupported extension fields if they are all zero. If any unsupported extension fields are non-zero, then -1 is returned and errno is set to E2BIG. This provides forwards-compatibility.

⚠️ Because the definition of struct mount_attr may change in the future (with new fields being added when system headers are updated), user-space applications should zero-fill struct mount_attr to ensure that recompiling the program with new headers will not result in spurious errors at run time. Do not skip this, bestie, it will ruin your whole day. 😭

The simplest way is to use a designated initializer:

struct mount_attr attr = {
    .attr_set = MOUNT_ATTR_RDONLY,
    .attr_clr = MOUNT_ATTR_NODEV
};

Alternatively, the structure can be zero-filled using memset(3) or similar functions:

struct mount_attr attr;
memset(&attr, 0, sizeof(attr));
attr.attr_set = MOUNT_ATTR_RDONLY;
attr.attr_clr = MOUNT_ATTR_NODEV;

A user-space application that wishes to determine which extensions the running kernel supports can do so by conducting a binary search on size with a structure which has every byte nonzero (to find the largest value which doesn't produce an error of E2BIG). Detective work, but make it C. 🔍

✨ EXAMPLES ✨

Okay bestie, buckle UP, because this is the moment you've been waiting for: a whole actual program that shows off everything this syscall can do 💅

So here's the vibe — this little demo lets whoever runs it make a new detached mount and then set a bunch of properties on it. Detached mount = it exists, it's cloned, but it's not attached to your namespace yet. Iconic behaviour, truly.

/*
 * This program allows the caller to create a new detached mount
 * and set various properties on it.
 */
#define _GNU_SOURCE
#include <err.h>
#include <fcntl.h>
#include <getopt.h>
#include <sys/mount.h>
#include <sys/types.h>
#include <stdbool.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>

static const struct option longopts[] = {
    {"map-mount",       required_argument,  NULL,  'a'},
    {"recursive",       no_argument,        NULL,  'b'},
    {"read-only",       no_argument,        NULL,  'c'},
    {"block-setid",     no_argument,        NULL,  'd'},
    {"block-devices",   no_argument,        NULL,  'e'},
    {"block-exec",      no_argument,        NULL,  'f'},
    {"no-access-time",  no_argument,        NULL,  'g'},
    { NULL,             0,                  NULL,   0 },
};

int
main(int argc, char *argv[])
{
    int                fd_userns = -1;
    int                fd_tree;
    int                index = 0;
    int                ret;
    bool               recursive = false;
    const char         *source;
    const char         *target;
    struct mount_attr  *attr = &(struct mount_attr){};

    while ((ret = getopt_long_only(argc, argv, "",
                                   longopts, &index)) != -1) {
        switch (ret) {
        case 'a':
            fd_userns = open(optarg, O_RDONLY | O_CLOEXEC);
            if (fd_userns == -1)
                err(EXIT_FAILURE, "open(%s)", optarg);
            break;
        case 'b':
            recursive = true;
            break;
        case 'c':
            attr->attr_set |= MOUNT_ATTR_RDONLY;
            break;
        case 'd':
            attr->attr_set |= MOUNT_ATTR_NOSUID;
            break;
        case 'e':
            attr->attr_set |= MOUNT_ATTR_NODEV;
            break;
        case 'f':
            attr->attr_set |= MOUNT_ATTR_NOEXEC;
            break;
        case 'g':
            attr->attr_set |= MOUNT_ATTR_NOATIME;
            attr->attr_clr |= MOUNT_ATTR__ATIME;
            break;
        default:
            errx(EXIT_FAILURE, "Invalid argument specified");
        }
    }

    if ((argc - optind) < 2)
        errx(EXIT_FAILURE, "Missing source or target mount point");

    source = argv[optind];
    target = argv[optind + 1];

    /* In the following, -1 as the 'dirfd' argument ensures that
       open_tree() fails if 'source' is not an absolute pathname.  */

    fd_tree = open_tree(-1, source,
                        OPEN_TREE_CLONE | OPEN_TREE_CLOEXEC |
                        AT_EMPTY_PATH | (recursive ? AT_RECURSIVE : 0));
    if (fd_tree == -1)
        err(EXIT_FAILURE, "open(%s)", source);

    if (fd_userns >= 0) {
        attr->attr_set  |= MOUNT_ATTR_IDMAP;
        attr->userns_fd = fd_userns;
    }

    ret = mount_setattr(fd_tree, "",
                        AT_EMPTY_PATH | (recursive ? AT_RECURSIVE : 0),
                        attr, sizeof(struct mount_attr));
    if (ret == -1)
        err(EXIT_FAILURE, "mount_setattr");

    close(fd_userns);

    /* In the following, -1 as the 'to_dirfd' argument ensures that
       open_tree() fails if 'target' is not an absolute pathname.  */

    ret = move_mount(fd_tree, "", -1, target,
                     MOVE_MOUNT_F_EMPTY_PATH);
    if (ret == -1)
        err(EXIT_FAILURE, "move_mount() to %s", target);

    close(fd_tree);

    exit(EXIT_SUCCESS);
}

A few notes so you're not out here confused, bestie 🫶

• The program sets <cyan>attr->attr_set</cyan> bits for whatever flags you pass — -c gives you MOUNT_ATTR_RDONLY, -d gives MOUNT_ATTR_NOSUID, -e gives MOUNT_ATTR_NODEV, -f gives MOUNT_ATTR_NOEXEC. Very choose-your-own-adventure ✨
• -g is the drama queen of the bunch: it sets MOUNT_ATTR_NOATIME and clears MOUNT_ATTR__ATIME in attr->attr_clr, because the atime bits are a little family that has to be handled together, no cap.
• Both comments about passing -1 as the dirfd argument are doing real work, okay? Passing -1 as the dirfd argument ensures that open_tree() fails if the relevant pathname isn't absolute. It's a guard rail, and we love her for it 💖
• -a opens the user namespace and lights up MOUNT_ATTR_IDMAP with attr->userns_fd set to that fd. That's the id-mapping moment, iykyk.

---

🌈 SEE ALSO 🌈

Go read these next, they're all part of the same friend group:

• newgidmap(1), newuidmap(1)
• clone(2), mount(2), unshare(2)
• proc(5)
• capabilities(7), mount_namespaces(7), user_namespaces(7), xattr(7)

---

And that's a wrap on the whole page, bestie 🎀 no notes, you understood the assignment, absolute main character energy.

This one came to you courtesy of Linux man-pages 6.20, dated 2026-02-11, and it's mount_setattr(2) — go forth and clone mounts responsibly 💅✨🌸