Adding upstream version 6.05.01.upstream/6.05.01

Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>

1 files changed, 971 insertions, 0 deletions

diff --git a/man2/mount.2 b/man2/mount.2
new file mode 100644
index 0000000..916b68c
--- /dev/null
+++ b/man2/mount.2
@@ -0,0 +1,971 @@
+.\" Copyright (C) 1993 Rickard E. Faith <faith@cs.unc.edu>
+.\" and Copyright (C) 1994 Andries E. Brouwer <aeb@cwi.nl>
+.\" and Copyright (C) 2002, 2005, 2016 Michael Kerrisk <mtk.manpages@gmail.com>
+.\"
+.\" SPDX-License-Identifier: Linux-man-pages-copyleft
+.\"
+.\" Modified 1996-11-04 by Eric S. Raymond <esr@thyrsus.com>
+.\" Modified 2001-10-13 by Michael Kerrisk <mtk.manpages@gmail.com>
+.\"	Added note on historical behavior of MS_NOSUID
+.\" Modified 2002-05-16 by Michael Kerrisk <mtk.manpages@gmail.com>
+.\"	Extensive changes and additions
+.\" Modified 2002-05-27 by aeb
+.\" Modified 2002-06-11 by Michael Kerrisk <mtk.manpages@gmail.com>
+.\"	Enhanced descriptions of MS_MOVE, MS_BIND, and MS_REMOUNT
+.\" Modified 2004-06-17 by Michael Kerrisk <mtk.manpages@gmail.com>
+.\" 2005-05-18, mtk, Added MNT_EXPIRE, plus a few other tidy-ups.
+.\" 2008-10-06, mtk: move umount*() material into separate umount.2 page.
+.\" 2008-10-06, mtk: Add discussion of namespaces.
+.\"
+.TH mount 2 2023-04-03 "Linux man-pages 6.05.01"
+.SH NAME
+mount \- mount filesystem
+.SH LIBRARY
+Standard C library
+.RI ( libc ", " \-lc )
+.SH SYNOPSIS
+.nf
+.B "#include <sys/mount.h>"
+.PP
+.BI "int mount(const char *" source ", const char *" target ,
+.BI "          const char *" filesystemtype ", unsigned long " mountflags ,
+.BI "          const void *_Nullable " data );
+.fi
+.SH DESCRIPTION
+.BR mount ()
+attaches the filesystem specified by
+.I source
+(which is often a pathname referring to a device,
+but can also be the pathname of a directory or file,
+or a dummy string) to the location (a directory or file)
+specified by the pathname in
+.IR target .
+.PP
+Appropriate privilege (Linux: the
+.B CAP_SYS_ADMIN
+capability) is required to mount filesystems.
+.PP
+Values for the
+.I filesystemtype
+argument supported by the kernel are listed in
+.I /proc/filesystems
+(e.g., "btrfs", "ext4", "jfs", "xfs", "vfat", "fuse",
+"tmpfs", "cgroup", "proc", "mqueue", "nfs", "cifs", "iso9660").
+Further types may become available when the appropriate modules
+are loaded.
+.PP
+The
+.I data
+argument is interpreted by the different filesystems.
+Typically it is a string of comma-separated options
+understood by this filesystem.
+See
+.BR mount (8)
+for details of the options available for each filesystem type.
+This argument may be specified as NULL, if there are no options.
+.PP
+A call to
+.BR mount ()
+performs one of a number of general types of operation,
+depending on the bits specified in
+.IR mountflags .
+The choice of which operation to perform is determined by
+testing the bits set in
+.IR mountflags ,
+with the tests being conducted in the order listed here:
+.IP \[bu] 3
+Remount an existing mount:
+.I mountflags
+includes
+.BR MS_REMOUNT .
+.IP \[bu]
+Create a bind mount:
+.I mountflags
+includes
+.BR MS_BIND .
+.IP \[bu]
+Change the propagation type of an existing mount:
+.I mountflags
+includes one of
+.BR MS_SHARED ,
+.BR MS_PRIVATE ,
+.BR MS_SLAVE ,
+or
+.BR MS_UNBINDABLE .
+.IP \[bu]
+Move an existing mount to a new location:
+.I mountflags
+includes
+.BR MS_MOVE .
+.IP \[bu]
+Create a new mount:
+.I mountflags
+includes none of the above flags.
+.PP
+Each of these operations is detailed later in this page.
+Further flags may be specified in
+.I mountflags
+to modify the behavior of
+.BR mount (),
+as described below.
+.\"
+.SS Additional mount flags
+The list below describes the additional flags that can be specified in
+.IR mountflags .
+Note that some operation types ignore some or all of these flags,
+as described later in this page.
+.\"
+.\" FIXME 2.6.25 Added MS_I_VERSION, which needs to be documented.
+.\" commit 7a224228ed79d587ece2304869000aad1b8e97dd
+.\" (This is a per-superblock flag)
+.\"
+.TP
+.BR MS_DIRSYNC " (since Linux 2.5.19)"
+Make directory changes on this filesystem synchronous.
+(This property can be obtained for individual directories
+or subtrees using
+.BR chattr (1).)
+.TP
+.BR MS_LAZYTIME " (since Linux 4.0)"
+.\" commit 0ae45f63d4ef8d8eeec49c7d8b44a1775fff13e8
+.\" commit fe032c422c5ba562ba9c2d316f55e258e03259c6
+.\" commit a26f49926da938f47561f386be56a83dd37a496d
+Reduce on-disk updates of inode timestamps (atime, mtime, ctime)
+by maintaining these changes only in memory.
+The on-disk timestamps are updated only when:
+.RS
+.IP \[bu] 3
+the inode needs to be updated for some change unrelated to file timestamps;
+.IP \[bu]
+the application employs
+.BR fsync (2),
+.BR syncfs (2),
+or
+.BR sync (2);
+.IP \[bu]
+an undeleted inode is evicted from memory; or
+.IP \[bu]
+more than 24 hours have passed since the inode was written to disk.
+.RE
+.IP
+This mount option significantly reduces writes
+needed to update the inode's timestamps, especially mtime and atime.
+However, in the event of a system crash, the atime and mtime fields
+on disk might be out of date by up to 24 hours.
+.IP
+Examples of workloads where this option could be of significant benefit
+include frequent random writes to preallocated files,
+as well as cases where the
+.B MS_STRICTATIME
+mount option is also enabled.
+(The advantage of combining
+.B MS_STRICTATIME
+and
+.B MS_LAZYTIME
+is that
+.BR stat (2)
+will return the correctly updated atime, but the atime updates
+will be flushed to disk only in the cases listed above.)
+.TP
+.B MS_MANDLOCK
+Permit mandatory locking on files in this filesystem.
+(Mandatory locking must still be enabled on a per-file basis,
+as described in
+.BR fcntl (2).)
+Since Linux 4.5,
+.\" commit 95ace75414f312f9a7b93d873f386987b92a5301
+this mount option requires the
+.B CAP_SYS_ADMIN
+capability and a kernel configured with the
+.B CONFIG_MANDATORY_FILE_LOCKING
+option.
+Mandatory locking has been fully deprecated in Linux 5.15, so
+this flag should be considered deprecated.
+.TP
+.B MS_NOATIME
+Do not update access times for (all types of) files on this filesystem.
+.TP
+.B MS_NODEV
+Do not allow access to devices (special files) on this filesystem.
+.TP
+.B MS_NODIRATIME
+Do not update access times for directories on this filesystem.
+This flag provides a subset of the functionality provided by
+.BR MS_NOATIME ;
+that is,
+.B MS_NOATIME
+implies
+.BR MS_NODIRATIME .
+.TP
+.B MS_NOEXEC
+Do not allow programs to be executed from this filesystem.
+.\" (Possibly useful for a filesystem that contains non-Linux executables.
+.\" Often used as a security feature, e.g., to make sure that restricted
+.\" users cannot execute files uploaded using ftp or so.)
+.TP
+.B MS_NOSUID
+Do not honor set-user-ID and set-group-ID bits or file capabilities
+when executing programs from this filesystem.
+In addition, SELinux domain
+transitions require the permission
+.IR nosuid_transition ,
+which in turn needs
+also the policy capability
+.IR nnp_nosuid_transition .
+.\" (This is a security feature to prevent users executing set-user-ID and
+.\" set-group-ID programs from removable disk devices.)
+.TP
+.B MS_RDONLY
+Mount filesystem read-only.
+.TP
+.BR MS_REC " (since Linux 2.4.11)"
+Used in conjunction with
+.B MS_BIND
+to create a recursive bind mount,
+and in conjunction with the propagation type flags to recursively change
+the propagation type of all of the mounts in a subtree.
+See below for further details.
+.TP
+.BR MS_RELATIME " (since Linux 2.6.20)"
+When a file on this filesystem is accessed,
+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).
+This option is useful for programs, such as
+.BR mutt (1),
+that need to know when a file has been read since it was last modified.
+Since Linux 2.6.30, the kernel defaults to the behavior provided
+by this flag (unless
+.B MS_NOATIME
+was specified), and the
+.B MS_STRICTATIME
+flag is required to obtain traditional semantics.
+In addition, since Linux 2.6.30,
+the file's last access time is always updated if it
+is more than 1 day old.
+.\" Matthew Garrett notes in the patch that added this behavior
+.\" that this lets utilities such as tmpreaper (which deletes
+.\" files based on last access time) work correctly.
+.TP
+.BR MS_SILENT " (since Linux 2.6.17)"
+Suppress the display of certain
+.RI ( printk ())
+warning messages in the kernel log.
+This flag supersedes the misnamed and obsolete
+.B MS_VERBOSE
+flag (available since Linux 2.4.12), which has the same meaning.
+.TP
+.BR MS_STRICTATIME " (since Linux 2.6.30)"
+Always update the last access time (atime) when files on this
+filesystem are accessed.
+(This was the default behavior before Linux 2.6.30.)
+Specifying this flag overrides the effect of setting the
+.B MS_NOATIME
+and
+.B MS_RELATIME
+flags.
+.TP
+.B MS_SYNCHRONOUS
+Make writes on this filesystem synchronous (as though
+the
+.B O_SYNC
+flag to
+.BR open (2)
+was specified for all file opens to this filesystem).
+.TP
+.BR MS_NOSYMFOLLOW " (since Linux 5.10)"
+.\" dab741e0e02bd3c4f5e2e97be74b39df2523fc6e
+Do not follow symbolic links when resolving paths.
+Symbolic links can still be created,
+and
+.BR readlink (1),
+.BR readlink (2),
+.BR realpath (1),
+and
+.BR realpath (3)
+all still work properly.
+.PP
+From Linux 2.4 onward, some of the above flags are
+settable on a per-mount basis,
+while others apply to the superblock of the mounted filesystem,
+meaning that all mounts of the same filesystem share those flags.
+(Previously, all of the flags were per-superblock.)
+.PP
+The per-mount-point flags are as follows:
+.IP \[bu] 3
+Since Linux 2.4:
+.BR MS_NODEV ", " MS_NOEXEC ", and " MS_NOSUID
+flags are settable on a per-mount-point basis.
+.IP \[bu]
+Additionally, since Linux 2.6.16:
+.B MS_NOATIME
+and
+.BR MS_NODIRATIME .
+.IP \[bu]
+Additionally, since Linux 2.6.20:
+.BR MS_RELATIME .
+.PP
+The following flags are per-superblock:
+.BR MS_DIRSYNC ,
+.BR MS_LAZYTIME ,
+.BR MS_MANDLOCK ,
+.BR MS_SILENT ,
+and
+.BR MS_SYNCHRONOUS .
+.\" And MS_I_VERSION?
+The initial settings of these flags are determined on the first
+mount of the filesystem, and will be shared by all subsequent mounts
+of the same filesystem.
+Subsequently, the settings of the flags can be changed
+via a remount operation (see below).
+Such changes will be visible via all mounts associated
+with the filesystem.
+.PP
+Since Linux 2.6.16,
+.B MS_RDONLY
+can be set or cleared on a per-mount-point basis as well as on
+the underlying filesystem superblock.
+The mounted filesystem will be writable only if neither the filesystem
+nor the mountpoint are flagged as read-only.
+.\"
+.SS Remounting an existing mount
+An existing mount may be remounted by specifying
+.B MS_REMOUNT
+in
+.IR mountflags .
+This allows you to change the
+.I mountflags
+and
+.I data
+of an existing mount without having to unmount and remount the filesystem.
+.I target
+should be the same value specified in the initial
+.BR mount ()
+call.
+.PP
+The
+.I source
+and
+.I filesystemtype
+arguments are ignored.
+.PP
+The
+.I mountflags
+and
+.I data
+arguments should match the values used in the original
+.BR mount ()
+call, except for those parameters that are being deliberately changed.
+.PP
+The following
+.I mountflags
+can be changed:
+.BR MS_LAZYTIME ,
+.\" FIXME
+.\" MS_LAZYTIME seems to be available only on a few filesystems,
+.\" and on ext4, it seems (from experiment that this flag
+.\" can only be enabled (but not disabled) on a remount.
+.\" The following code in ext4_remount() (kernel 4.17) seems to
+.\" confirm this:
+.\"
+.\"        if (*flags & SB_LAZYTIME)
+.\"                sb->s_flags |= SB_LAZYTIME;
+.BR MS_MANDLOCK ,
+.BR MS_NOATIME ,
+.BR MS_NODEV ,
+.BR MS_NODIRATIME ,
+.BR MS_NOEXEC ,
+.BR MS_NOSUID ,
+.BR MS_RELATIME ,
+.BR MS_RDONLY ,
+.B MS_STRICTATIME
+(whose effect is to clear the
+.B MS_NOATIME
+and
+.B MS_RELATIME
+flags),
+and
+.BR MS_SYNCHRONOUS .
+Attempts to change the setting of the
+.\" See the definition of MS_RMT_MASK in include/uapi/linux/fs.h,
+.\" which excludes MS_DIRSYNC and MS_SILENT, although SB_DIRSYNC
+.\" and SB_SILENT are split out as per-superblock flags in do_mount()
+.\" (Linux 4.17 source code)
+.B MS_DIRSYNC
+and
+.B MS_SILENT
+flags during a remount are silently ignored.
+Note that changes to per-superblock flags are visible via
+all mounts of the associated filesystem
+(because the per-superblock flags are shared by all mounts).
+.PP
+Since Linux 3.17,
+.\" commit ffbc6f0ead47fa5a1dc9642b0331cb75c20a640e
+if none of
+.BR MS_NOATIME ,
+.BR MS_NODIRATIME ,
+.BR MS_RELATIME ,
+or
+.B MS_STRICTATIME
+is specified in
+.IR mountflags ,
+then the remount operation preserves the existing values of these flags
+(rather than defaulting to
+.BR MS_RELATIME ).
+.PP
+Since Linux 2.6.26, the
+.B MS_REMOUNT
+flag can be used with
+.B MS_BIND
+to modify only the per-mount-point flags.
+.\" See https://lwn.net/Articles/281157/
+This is particularly useful for setting or clearing the "read-only"
+flag on a mount without changing the underlying filesystem.
+Specifying
+.I mountflags
+as:
+.PP
+.in +4n
+.EX
+MS_REMOUNT | MS_BIND | MS_RDONLY
+.EE
+.in
+.PP
+will make access through this mountpoint read-only, without affecting
+other mounts.
+.\"
+.SS Creating a bind mount
+If
+.I mountflags
+includes
+.B MS_BIND
+(available since Linux 2.4),
+.\" since Linux 2.4.0-test9
+then perform a bind mount.
+A bind mount makes a file or a directory subtree visible at
+another point within the single directory hierarchy.
+Bind mounts may cross filesystem boundaries and span
+.BR chroot (2)
+jails.
+.PP
+The
+.I filesystemtype
+and
+.I data
+arguments are ignored.
+.PP
+The remaining bits (other than
+.BR MS_REC ,
+described below) in the
+.I mountflags
+argument are also ignored.
+(The bind mount has the same mount options as
+the underlying mount.)
+However, see the discussion of remounting above,
+for a method of making an existing bind mount read-only.
+.PP
+By default, when a directory is bind mounted,
+only that directory is mounted;
+if there are any submounts under the directory tree,
+they are not bind mounted.
+If the
+.B MS_REC
+flag is also specified, then a recursive bind mount operation is performed:
+all submounts under the
+.I source
+subtree (other than unbindable mounts)
+are also bind mounted at the corresponding location in the
+.I target
+subtree.
+.\"
+.SS Changing the propagation type of an existing mount
+If
+.I mountflags
+includes one of
+.BR MS_SHARED ,
+.BR MS_PRIVATE ,
+.BR MS_SLAVE ,
+or
+.B MS_UNBINDABLE
+(all available since Linux 2.6.15),
+then the propagation type of an existing mount is changed.
+If more than one of these flags is specified, an error results.
+.PP
+The only other flags that can be specified while changing
+the propagation type are
+.B MS_REC
+(described below) and
+.B MS_SILENT
+(which is ignored).
+.PP
+The
+.IR source ,
+.IR filesystemtype ,
+and
+.I data
+arguments are ignored.
+.PP
+The meanings of the propagation type flags are as follows:
+.TP
+.B MS_SHARED
+Make this mount shared.
+Mount and unmount events immediately under this mount will propagate
+to the other mounts that are members of this mount's peer group.
+Propagation here means that the same mount or unmount will automatically
+occur under all of the other mounts in the peer group.
+Conversely, mount and unmount events that take place under
+peer mounts will propagate to this mount.
+.TP
+.B MS_PRIVATE
+Make this mount private.
+Mount and unmount events do not propagate into or out of this mount.
+.TP
+.B MS_SLAVE
+If this is a shared mount that is a member of a peer group
+that contains other members, convert it to a slave mount.
+If this is a shared mount that is a member of a peer group
+that contains no other members, convert it to a private mount.
+Otherwise, the propagation type of the mount is left unchanged.
+.IP
+When a mount is a slave,
+mount and unmount events propagate into this mount from
+the (master) shared peer group of which it was formerly a member.
+Mount and unmount events under this mount do not propagate to any peer.
+.IP
+A mount can be the slave of another peer group
+while at the same time sharing mount and unmount events
+with a peer group of which it is a member.
+.TP
+.B MS_UNBINDABLE
+Make this mount unbindable.
+This is like a private mount,
+and in addition this mount can't be bind mounted.
+When a recursive bind mount
+.RB ( mount ()
+with the
+.B MS_BIND
+and
+.B MS_REC
+flags) is performed on a directory subtree,
+any unbindable mounts within the subtree are automatically pruned
+(i.e., not replicated)
+when replicating that subtree to produce the target subtree.
+.PP
+By default, changing the propagation type affects only the
+.I target
+mount.
+If the
+.B MS_REC
+flag is also specified in
+.IR mountflags ,
+then the propagation type of all mounts under
+.I target
+is also changed.
+.PP
+For further details regarding mount propagation types
+(including the default propagation type assigned to new mounts), see
+.BR mount_namespaces (7).
+.\"
+.SS Moving a mount
+If
+.I mountflags
+contains the flag
+.B MS_MOVE
+(available since Linux 2.4.18),
+then move a subtree:
+.I source
+specifies an existing mount and
+.I target
+specifies the new location to which that mount is to be relocated.
+The move is atomic: at no point is the subtree unmounted.
+.PP
+The remaining bits in the
+.I mountflags
+argument are ignored, as are the
+.I filesystemtype
+and
+.I data
+arguments.
+.\"
+.SS Creating a new mount
+If none of
+.BR MS_REMOUNT ,
+.BR MS_BIND ,
+.BR MS_MOVE ,
+.BR MS_SHARED ,
+.BR MS_PRIVATE ,
+.BR MS_SLAVE ,
+or
+.B MS_UNBINDABLE
+is specified in
+.IR mountflags ,
+then
+.BR mount ()
+performs its default action: creating a new mount.
+.I source
+specifies the source for the new mount, and
+.I target
+specifies the directory at which to create the mount point.
+.PP
+The
+.I filesystemtype
+and
+.I data
+arguments are employed, and further bits may be specified in
+.I mountflags
+to modify the behavior of the call.
+.\"
+.SH RETURN VALUE
+On success, zero is returned.
+On error, \-1 is returned, and
+.I errno
+is set to indicate the error.
+.SH ERRORS
+The error values given below result from filesystem type independent
+errors.
+Each filesystem type may have its own special errors and its
+own special behavior.
+See the Linux kernel source code for details.
+.TP
+.B EACCES
+A component of a path was not searchable.
+(See also
+.BR path_resolution (7).)
+.TP
+.B EACCES
+Mounting a read-only filesystem was attempted without giving the
+.B MS_RDONLY
+flag.
+.IP
+The filesystem may be read-only for various reasons, including:
+it resides on a read-only optical disk;
+it is resides on a device with a physical switch that has been set to
+mark the device read-only;
+the filesystem implementation was compiled with read-only support;
+or errors were detected when initially mounting the filesystem,
+so that it was marked read-only
+and can't be remounted as read-write (until the errors are fixed).
+.IP
+Some filesystems instead return the error
+.B EROFS
+on an attempt to mount a read-only filesystem.
+.TP
+.B EACCES
+The block device
+.I source
+is located on a filesystem mounted with the
+.B MS_NODEV
+option.
+.\" mtk: Probably: write permission is required for MS_BIND, with
+.\" the error EPERM if not present; CAP_DAC_OVERRIDE is required.
+.TP
+.B EBUSY
+An attempt was made to stack a new mount directly on
+top of an existing mount point that was created in this
+mount namespace with the same
+.I source
+and
+.IR target .
+.TP
+.B EBUSY
+.I source
+cannot be remounted read-only,
+because it still holds files open for writing.
+.TP
+.B EFAULT
+One of the pointer arguments points outside the user address space.
+.TP
+.B EINVAL
+.I source
+had an invalid superblock.
+.TP
+.B EINVAL
+A remount operation
+.RB ( MS_REMOUNT )
+was attempted, but
+.I source
+was not already mounted on
+.IR target .
+.TP
+.B EINVAL
+A move operation
+.RB ( MS_MOVE )
+was attempted, but the mount tree under
+.I source
+includes unbindable mounts and
+.I target
+is a mount that has propagation type
+.BR MS_SHARED .
+.TP
+.B EINVAL
+A move operation
+.RB ( MS_MOVE )
+was attempted, but the parent mount of
+.I source
+mount has propagation type
+.BR MS_SHARED .
+.TP
+.B EINVAL
+A move operation
+.RB ( MS_MOVE )
+was attempted, but
+.I source
+was not a mount, or was \[aq]/\[aq].
+.TP
+.B EINVAL
+A bind operation
+.RB ( MS_BIND )
+was requested where
+.I source
+referred a mount namespace magic link (i.e., a
+.IR /proc/ pid /ns/mnt
+magic link or a bind mount to such a link)
+and the propagation type of the parent mount of
+.I target
+was
+.BR MS_SHARED ,
+.\" See commit 8823c079ba7136dc1948d6f6dcb5f8022bde438e
+but propagation of the requested bind mount could lead to a circular
+dependency that might prevent the mount namespace from ever being freed.
+.TP
+.B EINVAL
+.I mountflags
+includes more than one of
+.BR MS_SHARED ,
+.BR MS_PRIVATE ,
+.BR MS_SLAVE ,
+or
+.BR MS_UNBINDABLE .
+.TP
+.B EINVAL
+.I mountflags
+includes
+.BR MS_SHARED ,
+.BR MS_PRIVATE ,
+.BR MS_SLAVE ,
+or
+.B MS_UNBINDABLE
+and also includes a flag other than
+.B MS_REC
+or
+.BR MS_SILENT .
+.TP
+.B EINVAL
+An attempt was made to bind mount an unbindable mount.
+.TP
+.B EINVAL
+In an unprivileged mount namespace
+(i.e., a mount namespace owned by a user namespace
+that was created by an unprivileged user),
+a bind mount operation
+.RB ( MS_BIND )
+was attempted without specifying
+.RB ( MS_REC ),
+which would have revealed the filesystem tree underneath one of
+the submounts of the directory being bound.
+.TP
+.B ELOOP
+Too many links encountered during pathname resolution.
+.TP
+.B ELOOP
+A move operation was attempted, and
+.I target
+is a descendant of
+.IR source .
+.TP
+.B EMFILE
+(In case no block device is required:)
+Table of dummy devices is full.
+.TP
+.B ENAMETOOLONG
+A pathname was longer than
+.BR MAXPATHLEN .
+.TP
+.B ENODEV
+.I filesystemtype
+not configured in the kernel.
+.TP
+.B ENOENT
+A pathname was empty or had a nonexistent component.
+.TP
+.B ENOMEM
+The kernel could not allocate a free page to copy filenames or data into.
+.TP
+.B ENOTBLK
+.I source
+is not a block device (and a device was required).
+.TP
+.B ENOTDIR
+.IR target ,
+or a prefix of
+.IR source ,
+is not a directory.
+.TP
+.B ENXIO
+The major number of the block device
+.I source
+is out of range.
+.TP
+.B EPERM
+The caller does not have the required privileges.
+.TP
+.B EPERM
+An attempt was made to modify
+.RB ( MS_REMOUNT )
+the
+.BR MS_RDONLY ,
+.BR MS_NOSUID ,
+or
+.B MS_NOEXEC
+flag, or one of the "atime" flags
+.RB ( MS_NOATIME ,
+.BR MS_NODIRATIME ,
+.BR MS_RELATIME )
+of an existing mount, but the mount is locked; see
+.BR mount_namespaces (7).
+.TP
+.B EROFS
+Mounting a read-only filesystem was attempted without giving the
+.B MS_RDONLY
+flag.
+See
+.BR EACCES ,
+above.
+.\"
+.SH STANDARDS
+Linux.
+.SH HISTORY
+The definitions of
+.BR MS_DIRSYNC ,
+.BR MS_MOVE ,
+.BR MS_PRIVATE ,
+.BR MS_REC ,
+.BR MS_RELATIME ,
+.BR MS_SHARED ,
+.BR MS_SLAVE ,
+.BR MS_STRICTATIME ,
+and
+.B MS_UNBINDABLE
+were added to glibc headers in glibc 2.12.
+.PP
+Since Linux 2.4 a single filesystem can be mounted at
+multiple mount points, and multiple mounts can be stacked
+on the same mount point.
+.\" Multiple mounts on same mount point: since Linux 2.3.99pre7.
+.PP
+The
+.I mountflags
+argument may have the magic number 0xC0ED (\fBMS_MGC_VAL\fP)
+in the top 16 bits.
+(All of the other flags discussed in DESCRIPTION
+occupy the low order 16 bits of
+.IR mountflags .)
+Specifying
+.B MS_MGC_VAL
+was required before Linux 2.4,
+but since Linux 2.4 is no longer required and is ignored if specified.
+.PP
+The original
+.B MS_SYNC
+flag was renamed
+.B MS_SYNCHRONOUS
+in 1.1.69
+when a different
+.B MS_SYNC
+was added to \fI<mman.h>\fP.
+.PP
+Before Linux 2.4 an attempt to execute a set-user-ID or set-group-ID program
+on a filesystem mounted with
+.B MS_NOSUID
+would fail with
+.BR EPERM .
+Since Linux 2.4 the set-user-ID and set-group-ID bits are
+just silently ignored in this case.
+.\" The change is in patch-2.4.0-prerelease.
+.\"
+.SH NOTES
+.SS Mount namespaces
+Starting with Linux 2.4.19, Linux provides mount namespaces.
+A mount namespace is the set of filesystem mounts that
+are visible to a process.
+Mount namespaces can be (and usually are)
+shared between multiple processes,
+and changes to the namespace (i.e., mounts and unmounts) by one process
+are visible to all other processes sharing the same namespace.
+(The pre-2.4.19 Linux situation can be considered as one in which
+a single namespace was shared by every process on the system.)
+.PP
+A child process created by
+.BR fork (2)
+shares its parent's mount namespace;
+the mount namespace is preserved across an
+.BR execve (2).
+.PP
+A process can obtain a private mount namespace if:
+it was created using the
+.BR clone (2)
+.B CLONE_NEWNS
+flag,
+in which case its new namespace is initialized to be a
+.I copy
+of the namespace of the process that called
+.BR clone (2);
+or it calls
+.BR unshare (2)
+with the
+.B CLONE_NEWNS
+flag,
+which causes the caller's mount namespace to obtain a private copy
+of the namespace that it was previously sharing with other processes,
+so that future mounts and unmounts by the caller are invisible
+to other processes (except child processes that the caller
+subsequently creates) and vice versa.
+.PP
+For further details on mount namespaces, see
+.BR mount_namespaces (7).
+.\"
+.SS Parental relationship between mounts
+Each mount has a parent mount.
+The overall parental relationship of all mounts defines
+the single directory hierarchy seen by the processes within a mount namespace.
+.PP
+The parent of a new mount is defined when the mount is created.
+In the usual case,
+the parent of a new mount is the mount of the filesystem
+containing the directory or file at which the new mount is attached.
+In the case where a new mount is stacked on top of an existing mount,
+the parent of the new mount is the previous mount that was stacked
+at that location.
+.PP
+The parental relationship between mounts can be discovered via the
+.IR /proc/ pid /mountinfo
+file (see below).
+.\"
+.SS \fI/proc/\fPpid\fI/mounts\fP and \fI/proc/\fPpid\fI/mountinfo\fP
+The Linux-specific
+.IR /proc/ pid /mounts
+file exposes the list of mounts in the mount
+namespace of the process with the specified ID.
+The
+.IR /proc/ pid /mountinfo
+file exposes even more information about mounts,
+including the propagation type and mount ID information that makes it
+possible to discover the parental relationship between mounts.
+See
+.BR proc (5)
+and
+.BR mount_namespaces (7)
+for details of this file.
+.SH SEE ALSO
+.BR mountpoint (1),
+.BR chroot (2),
+.BR ioctl_iflags (2),
+.BR mount_setattr (2),
+.BR pivot_root (2),
+.BR umount (2),
+.BR mount_namespaces (7),
+.BR path_resolution (7),
+.BR findmnt (8),
+.BR lsblk (8),
+.BR mount (8),
+.BR umount (8)