1mount(2)                      System Calls Manual                     mount(2)
2
3
4

NAME

6       mount - mount filesystem
7

LIBRARY

9       Standard C library (libc, -lc)
10

SYNOPSIS

12       #include <sys/mount.h>
13
14       int mount(const char *source, const char *target,
15                 const char *filesystemtype, unsigned long mountflags,
16                 const void *_Nullable data);
17

DESCRIPTION

19       mount()  attaches  the filesystem specified by source (which is often a
20       pathname referring to a device, but can also be the pathname of  a  di‐
21       rectory  or  file,  or  a dummy string) to the location (a directory or
22       file) specified by the pathname in target.
23
24       Appropriate privilege (Linux: the CAP_SYS_ADMIN capability) is required
25       to mount filesystems.
26
27       Values  for  the  filesystemtype  argument  supported by the kernel are
28       listed in  /proc/filesystems  (e.g.,  "btrfs",  "ext4",  "jfs",  "xfs",
29       "vfat",  "fuse",  "tmpfs",  "cgroup",  "proc", "mqueue", "nfs", "cifs",
30       "iso9660").  Further types may become available  when  the  appropriate
31       modules are loaded.
32
33       The  data  argument is interpreted by the different filesystems.  Typi‐
34       cally it is a string of  comma-separated  options  understood  by  this
35       filesystem.  See mount(8) for details of the options available for each
36       filesystem type.  This argument may be specified as NULL, if there  are
37       no options.
38
39       A  call  to mount() performs one of a number of general types of opera‐
40       tion, depending on the bits specified in  mountflags.   The  choice  of
41       which  operation  to  perform  is determined by testing the bits set in
42       mountflags, with the tests being conducted in the order listed here:
43
44       •  Remount an existing mount: mountflags includes MS_REMOUNT.
45
46       •  Create a bind mount: mountflags includes MS_BIND.
47
48       •  Change the propagation type of an  existing  mount:  mountflags  in‐
49          cludes one of MS_SHARED, MS_PRIVATE, MS_SLAVE, or MS_UNBINDABLE.
50
51       •  Move  an  existing  mount  to  a  new  location: mountflags includes
52          MS_MOVE.
53
54       •  Create a new mount: mountflags includes none of the above flags.
55
56       Each of these operations is detailed later in this page.  Further flags
57       may  be  specified  in mountflags to modify the behavior of mount(), as
58       described below.
59
60   Additional mount flags
61       The list below describes the additional flags that can be specified  in
62       mountflags.  Note that some operation types ignore some or all of these
63       flags, as described later in this page.
64
65       MS_DIRSYNC (since Linux 2.5.19)
66              Make directory changes on this  filesystem  synchronous.   (This
67              property  can be obtained for individual directories or subtrees
68              using chattr(1).)
69
70       MS_LAZYTIME (since Linux 4.0)
71              Reduce on-disk updates of inode timestamps (atime, mtime, ctime)
72              by  maintaining these changes only in memory.  The on-disk time‐
73              stamps are updated only when:
74
75              •  the inode needs to be updated for some  change  unrelated  to
76                 file timestamps;
77
78              •  the application employs fsync(2), syncfs(2), or sync(2);
79
80              •  an undeleted inode is evicted from memory; or
81
82              •  more than 24 hours have passed since the inode was written to
83                 disk.
84
85              This mount option significantly reduces writes needed to  update
86              the inode's timestamps, especially mtime and atime.  However, in
87              the event of a system crash, the atime and mtime fields on  disk
88              might be out of date by up to 24 hours.
89
90              Examples  of workloads where this option could be of significant
91              benefit include frequent random writes to preallocated files, as
92              well  as cases where the MS_STRICTATIME mount option is also en‐
93              abled.  (The advantage of combining MS_STRICTATIME and  MS_LAZY‐
94              TIME  is  that  stat(2) will return the correctly updated atime,
95              but the atime updates will be flushed to disk only in the  cases
96              listed above.)
97
98       MS_MANDLOCK
99              Permit  mandatory  locking on files in this filesystem.  (Manda‐
100              tory locking must still be enabled on a per-file basis,  as  de‐
101              scribed  in  fcntl(2).)   Since Linux 4.5, this mount option re‐
102              quires the CAP_SYS_ADMIN capability and a kernel configured with
103              the CONFIG_MANDATORY_FILE_LOCKING option.  Mandatory locking has
104              been fully deprecated in Linux 5.15, so this flag should be con‐
105              sidered deprecated.
106
107       MS_NOATIME
108              Do  not  update  access  times  for (all types of) files on this
109              filesystem.
110
111       MS_NODEV
112              Do not allow access to devices (special files) on this  filesys‐
113              tem.
114
115       MS_NODIRATIME
116              Do  not  update access times for directories on this filesystem.
117              This flag provides a subset of  the  functionality  provided  by
118              MS_NOATIME; that is, MS_NOATIME implies MS_NODIRATIME.
119
120       MS_NOEXEC
121              Do not allow programs to be executed from this filesystem.
122
123       MS_NOSUID
124              Do not honor set-user-ID and set-group-ID bits or file capabili‐
125              ties when executing programs from this filesystem.  In addition,
126              SELinux domain transitions require the permission nosuid_transi‐
127              tion, which in turn needs also  the  policy  capability  nnp_no‐
128              suid_transition.
129
130       MS_RDONLY
131              Mount filesystem read-only.
132
133       MS_REC (since Linux 2.4.11)
134              Used  in  conjunction  with  MS_BIND  to create a recursive bind
135              mount, and in conjunction with the propagation type flags to re‐
136              cursively  change the propagation type of all of the mounts in a
137              subtree.  See below for further details.
138
139       MS_RELATIME (since Linux 2.6.20)
140              When a file on this filesystem is accessed,  update  the  file's
141              last  access  time (atime) only if the current value of atime is
142              less than or equal to the file's last modification time  (mtime)
143              or  last  status change time (ctime).  This option is useful for
144              programs, such as mutt(1), that need to know  when  a  file  has
145              been  read  since it was last modified.  Since Linux 2.6.30, the
146              kernel defaults to the behavior provided by  this  flag  (unless
147              MS_NOATIME  was  specified),  and the MS_STRICTATIME flag is re‐
148              quired to obtain  traditional  semantics.   In  addition,  since
149              Linux  2.6.30,  the file's last access time is always updated if
150              it is more than 1 day old.
151
152       MS_SILENT (since Linux 2.6.17)
153              Suppress the display of certain (printk()) warning  messages  in
154              the  kernel log.  This flag supersedes the misnamed and obsolete
155              MS_VERBOSE flag (available since Linux 2.4.12),  which  has  the
156              same meaning.
157
158       MS_STRICTATIME (since Linux 2.6.30)
159              Always  update  the  last access time (atime) when files on this
160              filesystem are accessed.  (This was the default behavior  before
161              Linux  2.6.30.)   Specifying  this  flag overrides the effect of
162              setting the MS_NOATIME and MS_RELATIME flags.
163
164       MS_SYNCHRONOUS
165              Make writes on this filesystem synchronous (as though the O_SYNC
166              flag  to  open(2)  was  specified  for  all  file  opens to this
167              filesystem).
168
169       MS_NOSYMFOLLOW (since Linux 5.10)
170              Do not follow symbolic links  when  resolving  paths.   Symbolic
171              links  can still be created, and readlink(1), readlink(2), real‐
172              path(1), and realpath(3) all still work properly.
173
174       From Linux 2.4 onward, some of the above flags are settable on  a  per-
175       mount  basis,  while  others  apply  to  the  superblock of the mounted
176       filesystem, meaning that all mounts of the same filesystem share  those
177       flags.  (Previously, all of the flags were per-superblock.)
178
179       The per-mount-point flags are as follows:
180
181       •  Since  Linux  2.4: MS_NODEV, MS_NOEXEC, and MS_NOSUID flags are set‐
182          table on a per-mount-point basis.
183
184       •  Additionally, since Linux 2.6.16: MS_NOATIME and MS_NODIRATIME.
185
186       •  Additionally, since Linux 2.6.20: MS_RELATIME.
187
188       The  following  flags  are  per-superblock:  MS_DIRSYNC,   MS_LAZYTIME,
189       MS_MANDLOCK,  MS_SILENT,  and  MS_SYNCHRONOUS.  The initial settings of
190       these flags are determined on the first mount of  the  filesystem,  and
191       will be shared by all subsequent mounts of the same filesystem.  Subse‐
192       quently, the settings of the flags can be changed via a remount  opera‐
193       tion  (see below).  Such changes will be visible via all mounts associ‐
194       ated with the filesystem.
195
196       Since Linux 2.6.16, MS_RDONLY can be set or  cleared  on  a  per-mount-
197       point  basis  as  well as on the underlying filesystem superblock.  The
198       mounted filesystem will be writable only if neither the filesystem  nor
199       the mountpoint are flagged as read-only.
200
201   Remounting an existing mount
202       An  existing  mount may be remounted by specifying MS_REMOUNT in mount‐
203       flags.  This allows you to change the mountflags and data of an  exist‐
204       ing mount without having to unmount and remount the filesystem.  target
205       should be the same value specified in the initial mount() call.
206
207       The source and filesystemtype arguments are ignored.
208
209       The mountflags and data arguments should match the values used  in  the
210       original  mount()  call, except for those parameters that are being de‐
211       liberately changed.
212
213       The following mountflags  can  be  changed:  MS_LAZYTIME,  MS_MANDLOCK,
214       MS_NOATIME, MS_NODEV, MS_NODIRATIME, MS_NOEXEC, MS_NOSUID, MS_RELATIME,
215       MS_RDONLY, MS_STRICTATIME (whose effect is to clear the MS_NOATIME  and
216       MS_RELATIME flags), and MS_SYNCHRONOUS.  Attempts to change the setting
217       of the MS_DIRSYNC and MS_SILENT flags during a remount are silently ig‐
218       nored.   Note  that changes to per-superblock flags are visible via all
219       mounts of the associated filesystem (because the  per-superblock  flags
220       are shared by all mounts).
221
222       Since Linux 3.17, if none of MS_NOATIME, MS_NODIRATIME, MS_RELATIME, or
223       MS_STRICTATIME is specified in mountflags, then the  remount  operation
224       preserves the existing values of these flags (rather than defaulting to
225       MS_RELATIME).
226
227       Since Linux 2.6.26, the MS_REMOUNT flag can be  used  with  MS_BIND  to
228       modify only the per-mount-point flags.  This is particularly useful for
229       setting or clearing the "read-only" flag on a  mount  without  changing
230       the underlying filesystem.  Specifying mountflags as:
231
232           MS_REMOUNT | MS_BIND | MS_RDONLY
233
234       will  make  access through this mountpoint read-only, without affecting
235       other mounts.
236
237   Creating a bind mount
238       If mountflags includes MS_BIND (available since Linux 2.4),  then  per‐
239       form  a  bind  mount.  A bind mount makes a file or a directory subtree
240       visible at another point within the single directory  hierarchy.   Bind
241       mounts may cross filesystem boundaries and span chroot(2) jails.
242
243       The filesystemtype and data arguments are ignored.
244
245       The  remaining  bits (other than MS_REC, described below) in the mount‐
246       flags argument are also ignored.  (The bind mount has  the  same  mount
247       options  as  the underlying mount.)  However, see the discussion of re‐
248       mounting above, for a method of making an  existing  bind  mount  read-
249       only.
250
251       By  default,  when  a directory is bind mounted, only that directory is
252       mounted; if there are any submounts under the directory tree, they  are
253       not  bind mounted.  If the MS_REC flag is also specified, then a recur‐
254       sive bind mount operation is performed: all submounts under the  source
255       subtree  (other  than  unbindable  mounts) are also bind mounted at the
256       corresponding location in the target subtree.
257
258   Changing the propagation type of an existing mount
259       If mountflags includes  one  of  MS_SHARED,  MS_PRIVATE,  MS_SLAVE,  or
260       MS_UNBINDABLE  (all available since Linux 2.6.15), then the propagation
261       type of an existing mount is changed.  If more than one of these  flags
262       is specified, an error results.
263
264       The  only other flags that can be specified while changing the propaga‐
265       tion type are MS_REC (described below)  and  MS_SILENT  (which  is  ig‐
266       nored).
267
268       The source, filesystemtype, and data arguments are ignored.
269
270       The meanings of the propagation type flags are as follows:
271
272       MS_SHARED
273              Make  this  mount  shared.  Mount and unmount events immediately
274              under this mount will propagate to the  other  mounts  that  are
275              members of this mount's peer group.  Propagation here means that
276              the same mount or unmount will automatically occur under all  of
277              the  other  mounts in the peer group.  Conversely, mount and un‐
278              mount events that take place under peer mounts will propagate to
279              this mount.
280
281       MS_PRIVATE
282              Make this mount private.  Mount and unmount events do not propa‐
283              gate into or out of this mount.
284
285       MS_SLAVE
286              If this is a shared mount that is a member of a peer group  that
287              contains other members, convert it to a slave mount.  If this is
288              a shared mount that is a member of a peer group that contains no
289              other  members,  convert  it to a private mount.  Otherwise, the
290              propagation type of the mount is left unchanged.
291
292              When a mount is a slave, mount and unmount events propagate into
293              this  mount  from the (master) shared peer group of which it was
294              formerly a member.  Mount and unmount events under this mount do
295              not propagate to any peer.
296
297              A mount can be the slave of another peer group while at the same
298              time sharing mount and unmount events with a peer group of which
299              it is a member.
300
301       MS_UNBINDABLE
302              Make  this  mount unbindable.  This is like a private mount, and
303              in addition this mount can't be bind mounted.  When a  recursive
304              bind  mount  (mount() with the MS_BIND and MS_REC flags) is per‐
305              formed on a directory subtree, any unbindable mounts within  the
306              subtree  are  automatically  pruned  (i.e., not replicated) when
307              replicating that subtree to produce the target subtree.
308
309       By default, changing the  propagation  type  affects  only  the  target
310       mount.   If  the  MS_REC flag is also specified in mountflags, then the
311       propagation type of all mounts under target is also changed.
312
313       For further details regarding mount propagation  types  (including  the
314       default  propagation  type  assigned  to  new  mounts), see mount_name‐
315       spaces(7).
316
317   Moving a mount
318       If mountflags contains the flag MS_MOVE (available since Linux 2.4.18),
319       then  move  a  subtree:  source  specifies an existing mount and target
320       specifies the new location to which that mount is to be relocated.  The
321       move is atomic: at no point is the subtree unmounted.
322
323       The  remaining  bits in the mountflags argument are ignored, as are the
324       filesystemtype and data arguments.
325
326   Creating a new mount
327       If  none  of  MS_REMOUNT,  MS_BIND,  MS_MOVE,  MS_SHARED,   MS_PRIVATE,
328       MS_SLAVE,  or  MS_UNBINDABLE  is  specified in mountflags, then mount()
329       performs its default action: creating a new  mount.   source  specifies
330       the  source  for  the  new mount, and target specifies the directory at
331       which to create the mount point.
332
333       The filesystemtype and data arguments are employed,  and  further  bits
334       may be specified in mountflags to modify the behavior of the call.
335

RETURN VALUE

337       On  success,  zero is returned.  On error, -1 is returned, and errno is
338       set to indicate the error.
339

ERRORS

341       The error values given below result from  filesystem  type  independent
342       errors.   Each  filesystem type may have its own special errors and its
343       own special behavior.  See the Linux kernel source code for details.
344
345       EACCES A component of a path was not searchable.  (See also  path_reso‐
346              lution(7).)
347
348       EACCES Mounting a read-only filesystem was attempted without giving the
349              MS_RDONLY flag.
350
351              The filesystem may be read-only for various reasons,  including:
352              it  resides  on a read-only optical disk; it is resides on a de‐
353              vice with a physical switch that has been set to mark the device
354              read-only; the filesystem implementation was compiled with read-
355              only support; or errors were detected  when  initially  mounting
356              the filesystem, so that it was marked read-only and can't be re‐
357              mounted as read-write (until the errors are fixed).
358
359              Some filesystems instead return the error EROFS on an attempt to
360              mount a read-only filesystem.
361
362       EACCES The  block device source is located on a filesystem mounted with
363              the MS_NODEV option.
364
365       EBUSY  An attempt was made to stack a new mount directly on top  of  an
366              existing  mount  point  that was created in this mount namespace
367              with the same source and target.
368
369       EBUSY  source cannot be remounted read-only,  because  it  still  holds
370              files open for writing.
371
372       EFAULT One  of  the  pointer  arguments points outside the user address
373              space.
374
375       EINVAL source had an invalid superblock.
376
377       EINVAL A remount operation (MS_REMOUNT) was attempted, but  source  was
378              not already mounted on target.
379
380       EINVAL A move operation (MS_MOVE) was attempted, but the mount tree un‐
381              der source includes unbindable mounts and target is a mount that
382              has propagation type MS_SHARED.
383
384       EINVAL A  move  operation (MS_MOVE) was attempted, but the parent mount
385              of source mount has propagation type MS_SHARED.
386
387       EINVAL A move operation (MS_MOVE) was attempted, but source was  not  a
388              mount, or was '/'.
389
390       EINVAL A bind operation (MS_BIND) was requested where source referred a
391              mount namespace magic link (i.e., a /proc/pid/ns/mnt magic  link
392              or  a bind mount to such a link) and the propagation type of the
393              parent mount of target was MS_SHARED, but propagation of the re‐
394              quested  bind  mount  could  lead  to a circular dependency that
395              might prevent the mount namespace from ever being freed.
396
397       EINVAL mountflags includes more  than  one  of  MS_SHARED,  MS_PRIVATE,
398              MS_SLAVE, or MS_UNBINDABLE.
399
400       EINVAL mountflags  includes  MS_SHARED, MS_PRIVATE, MS_SLAVE, or MS_UN‐
401              BINDABLE  and  also  includes  a  flag  other  than  MS_REC   or
402              MS_SILENT.
403
404       EINVAL An attempt was made to bind mount an unbindable mount.
405
406       EINVAL In  an  unprivileged  mount  namespace  (i.e., a mount namespace
407              owned by a user namespace that was created  by  an  unprivileged
408              user),  a  bind  mount operation (MS_BIND) was attempted without
409              specifying (MS_REC), which would have  revealed  the  filesystem
410              tree  underneath  one  of  the  submounts of the directory being
411              bound.
412
413       ELOOP  Too many links encountered during pathname resolution.
414
415       ELOOP  A move operation was attempted, and target is  a  descendant  of
416              source.
417
418       EMFILE (In case no block device is required:) Table of dummy devices is
419              full.
420
421       ENAMETOOLONG
422              A pathname was longer than MAXPATHLEN.
423
424       ENODEV filesystemtype not configured in the kernel.
425
426       ENOENT A pathname was empty or had a nonexistent component.
427
428       ENOMEM The kernel could not allocate a free page to copy  filenames  or
429              data into.
430
431       ENOTBLK
432              source is not a block device (and a device was required).
433
434       ENOTDIR
435              target, or a prefix of source, is not a directory.
436
437       ENXIO  The major number of the block device source is out of range.
438
439       EPERM  The caller does not have the required privileges.
440
441       EPERM  An attempt was made to modify (MS_REMOUNT) the MS_RDONLY, MS_NO‐
442              SUID, or MS_NOEXEC flag, or one of the "atime"  flags  (MS_NOAT‐
443              IME,  MS_NODIRATIME,  MS_RELATIME) of an existing mount, but the
444              mount is locked; see mount_namespaces(7).
445
446       EROFS  Mounting a read-only filesystem was attempted without giving the
447              MS_RDONLY flag.  See EACCES, above.
448

STANDARDS

450       Linux.
451

HISTORY

453       The  definitions  of  MS_DIRSYNC, MS_MOVE, MS_PRIVATE, MS_REC, MS_RELA‐
454       TIME, MS_SHARED, MS_SLAVE, MS_STRICTATIME, and MS_UNBINDABLE were added
455       to glibc headers in glibc 2.12.
456
457       Since  Linux  2.4  a single filesystem can be mounted at multiple mount
458       points, and multiple mounts can be stacked on the same mount point.
459
460       The mountflags argument may have the magic number  0xC0ED  (MS_MGC_VAL)
461       in  the  top 16 bits.  (All of the other flags discussed in DESCRIPTION
462       occupy the low order 16 bits of mountflags.)  Specifying MS_MGC_VAL was
463       required  before  Linux  2.4, but since Linux 2.4 is no longer required
464       and is ignored if specified.
465
466       The original MS_SYNC flag was renamed MS_SYNCHRONOUS in 1.1.69  when  a
467       different MS_SYNC was added to <mman.h>.
468
469       Before  Linux  2.4  an attempt to execute a set-user-ID or set-group-ID
470       program on a filesystem mounted with MS_NOSUID would fail  with  EPERM.
471       Since Linux 2.4 the set-user-ID and set-group-ID bits are just silently
472       ignored in this case.
473

NOTES

475   Mount namespaces
476       Starting with Linux 2.4.19, Linux provides mount namespaces.   A  mount
477       namespace  is  the  set  of  filesystem  mounts  that  are visible to a
478       process.  Mount namespaces can be (and usually are) shared between mul‐
479       tiple  processes,  and  changes  to the namespace (i.e., mounts and un‐
480       mounts) by one process are visible to all other processes  sharing  the
481       same  namespace.   (The pre-2.4.19 Linux situation can be considered as
482       one in which a single namespace was shared by every process on the sys‐
483       tem.)
484
485       A child process created by fork(2) shares its parent's mount namespace;
486       the mount namespace is preserved across an execve(2).
487
488       A process can obtain a private mount namespace if: it was created using
489       the  clone(2) CLONE_NEWNS flag, in which case its new namespace is ini‐
490       tialized to be a copy of the  namespace  of  the  process  that  called
491       clone(2);  or  it  calls  unshare(2)  with  the CLONE_NEWNS flag, which
492       causes the caller's mount namespace to obtain a  private  copy  of  the
493       namespace  that it was previously sharing with other processes, so that
494       future mounts and unmounts by the caller are invisible  to  other  pro‐
495       cesses  (except  child  processes that the caller subsequently creates)
496       and vice versa.
497
498       For further details on mount namespaces, see mount_namespaces(7).
499
500   Parental relationship between mounts
501       Each mount has a parent mount.  The overall  parental  relationship  of
502       all mounts defines the single directory hierarchy seen by the processes
503       within a mount namespace.
504
505       The parent of a new mount is defined when the mount is created.  In the
506       usual  case,  the  parent of a new mount is the mount of the filesystem
507       containing the directory or file at which the new  mount  is  attached.
508       In  the  case where a new mount is stacked on top of an existing mount,
509       the parent of the new mount is the previous mount that was  stacked  at
510       that location.
511
512       The  parental  relationship  between  mounts  can be discovered via the
513       /proc/pid/mountinfo file (see below).
514
515   /proc/pid/mounts and /proc/pid/mountinfo
516       The Linux-specific /proc/pid/mounts file exposes the list of mounts  in
517       the  mount  namespace  of  the  process  with  the  specified  ID.  The
518       /proc/pid/mountinfo file exposes even more  information  about  mounts,
519       including  the  propagation type and mount ID information that makes it
520       possible to discover the parental  relationship  between  mounts.   See
521       proc(5) and mount_namespaces(7) for details of this file.
522

SEE ALSO

524       mountpoint(1),     chroot(2),     ioctl_iflags(2),    mount_setattr(2),
525       pivot_root(2),  umount(2),   mount_namespaces(7),   path_resolution(7),
526       findmnt(8), lsblk(8), mount(8), umount(8)
527
528
529
530Linux man-pages 6.05              2023-04-03                          mount(2)
Impressum