sys-utils/fstab.5

   1 .\" Copyright (c) 1980, 1989, 1991 The Regents of the University of California.
   2 .\" All rights reserved.
   3 .\"
   4 .\" Redistribution and use in source and binary forms, with or without
   5 .\" modification, are permitted provided that the following conditions
   6 .\" are met:
   7 .\" 1. Redistributions of source code must retain the above copyright
   8 .\"    notice, this list of conditions and the following disclaimer.
   9 .\" 2. Redistributions in binary form must reproduce the above copyright
  10 .\"    notice, this list of conditions and the following disclaimer in the
  11 .\"    documentation and/or other materials provided with the distribution.
  12 .\" 3. All advertising materials mentioning features or use of this software
  13 .\"    must display the following acknowledgement:
  14 .\"     This product includes software developed by the University of
  15 .\"     California, Berkeley and its contributors.
  16 .\" 4. Neither the name of the University nor the names of its contributors
  17 .\"    may be used to endorse or promote products derived from this software
  18 .\"    without specific prior written permission.
  19 .\"
  20 .\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
  21 .\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
  22 .\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
  23 .\" ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
  24 .\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
  25 .\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
  26 .\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
  27 .\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
  28 .\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
  29 .\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
  30 .\" SUCH DAMAGE.
  31 .\"
  32 .\"     @(#)fstab.5     6.5 (Berkeley) 5/10/91
  33 .\"
  34 .\" Modified Sat Mar  6 20:45:03 1993, faith@cs.unc.edu, for Linux
  35 .\" Sat Oct  9 10:07:10 1993: converted to man format by faith@cs.unc.edu
  36 .\" Sat Nov 20 20:47:38 1993: hpfs documentation added
  37 .\" Sat Nov 27 20:23:32 1993: Updated authorship information
  38 .\" Wed Jul 26 00:00:00 1995: Updated some nfs stuff, joey@infodrom.north.de
  39 .\" Tue Apr  2 00:38:28 1996: added info about "noauto", "user", etc.
  40 .\" Tue Jun 15 20:02:18 1999: added LABEL and UUID
  41 .\" Sat Jul 14 2001: Michael K. Johnson <johnsonm@redhat.com> added -O
  42 .\"
  43 .TH FSTAB 5 "August 2010" "util-linux" "File Formats"
  44 .SH NAME
  45 fstab \- static information about the filesystems
  46 .SH SYNOPSIS
  47 .B /etc/fstab
  48 .SH DESCRIPTION
  49 The file
  50 .B fstab
  51 contains descriptive information about the various file systems.
  52 .B fstab
  53 is only read by programs, and not written; it is the duty of the system
  54 administrator to properly create and maintain this file.  Each filesystem
  55 is described on a separate line; fields on each line are separated by tabs or
  56 spaces.  Lines starting with '#' are comments, blank lines are ignored. The
  57 order of records in
  58 .B fstab
  59 is important because
  60 .BR fsck (8),
  61 .BR mount (8),
  62 and
  63 .BR umount (8)
  64 sequentially iterate through
  65 .B fstab
  66 doing their thing.
  67
  68 .B The first field
  69 .RI ( fs_spec ).
  70 .RS
  71 This field describes the block special device or
  72 remote filesystem to be mounted.
  73 .LP
  74 For ordinary mounts it will hold (a link to) a block special
  75 device node (as created by
  76 .BR mknod (8))
  77 for the device to be mounted, like `/dev/cdrom' or `/dev/sdb7'.
  78 For NFS mounts one will have <host>:<dir>, e.g., `knuth.aeb.nl:/'.
  79 For procfs, use `proc'.
  80 .LP
  81 Instead of giving the device explicitly, one may indicate
  82 the filesystem that is to be mounted by its UUID or
  83 LABEL (cf.
  84 .BR e2label (8)
  85 or
  86 .BR xfs_admin (8)),
  87 writing LABEL=<label> or UUID=<uuid>,
  88 e.g., `LABEL=Boot' or `UUID=3e6be9de\%-8139\%-11d1\%-9106\%-a43f08d823a6'.
  89
  90 It's also possible to use PARTUUID= and PARTLABEL=. These partitions identifiers
  91 are supported for GUID Partition Table (GPT) and MAC partition table only.
  92
  93 See
  94 .BR blkid (8)
  95 or
  96 .BR lsblk (8)
  97 for more details about devices identifiers.
  98
  99 .LP
 100 Note that
 101 .BR mount (8)
 102 uses UUIDs as strings. The string representation of the UUID should be based on
 103 lower case characters.
 104 .RE
 105
 106 .B The second field
 107 .RI ( fs_file ).
 108 .RS
 109 This field describes the mount point for the filesystem.  For swap partitions, this
 110 field should be specified as `none'. If the name of the mount point
 111 contains spaces these can be escaped as `\\040'.
 112 .RE
 113
 114 .B The third field
 115 .RI ( fs_vfstype ).
 116 .RS
 117 This field describes the type of the filesystem.  Linux supports lots
 118 of filesystem types, such as
 119 .IR adfs ,
 120 .IR affs ,
 121 .IR autofs ,
 122 .IR coda ,
 123 .IR coherent ,
 124 .IR cramfs ,
 125 .IR devpts ,
 126 .IR efs ,
 127 .IR ext2 ,
 128 .IR ext3 ,
 129 .IR hfs ,
 130 .IR hpfs ,
 131 .IR iso9660 ,
 132 .IR jfs ,
 133 .IR minix ,
 134 .IR msdos ,
 135 .IR ncpfs ,
 136 .IR nfs ,
 137 .IR ntfs ,
 138 .IR proc ,
 139 .IR qnx4 ,
 140 .IR reiserfs ,
 141 .IR romfs ,
 142 .IR smbfs ,
 143 .IR sysv ,
 144 .IR tmpfs ,
 145 .IR udf ,
 146 .IR ufs ,
 147 .IR umsdos ,
 148 .IR vfat ,
 149 .IR xenix ,
 150 .IR xfs ,
 151 and possibly others. For more details, see
 152 .BR mount (8).
 153
 154 For the filesystems currently supported by the running kernel, see
 155 .IR /proc/filesystems .
 156
 157 An entry
 158 .I swap
 159 denotes a file or partition to be used
 160 for swapping, cf.\&
 161 .BR swapon (8).
 162 An entry
 163 .I ignore
 164 causes the line to be ignored.  This is useful
 165 to show disk partitions which are currently unused.
 166 An entry
 167 .I none
 168 is useful for bind or move mounts.
 169
 170 .BR mount (8)
 171 and
 172 .BR umount (8)
 173 support filesystem
 174 .IR subtypes .
 175 The subtype is defined by '.subtype' suffix.  For
 176 example 'fuse.sshfs'. It's recommended to use subtype notation rather than add
 177 any prefix to the first fstab field (for example 'sshfs#example.com' is
 178 deprecated).
 179 .RE
 180
 181 .B The fourth field
 182 .RI ( fs_mntops ).
 183 .RS
 184 This field describes the mount options associated with the filesystem.
 185
 186 It is formatted as a comma separated list of options.  It contains at least
 187 the type of mount plus any additional options appropriate to the filesystem
 188 type. For documentation on the available mount options, see
 189 .BR mount (8).
 190 For documentation on the available swap options, see
 191 .BR swapon (8).
 192
 193 Basic file system independent options are:
 194 .TP
 195 .B defaults
 196 use default options: rw, suid, dev, exec, auto, nouser, and async.
 197 .TP
 198 .B noauto
 199 do not mount when "mount -a" is given (e.g., at boot time)
 200 .TP
 201 .B user
 202 allow a user to mount
 203 .TP
 204 .B owner
 205 allow device owner to mount
 206 .TP
 207 .B comment
 208 for use by fstab-maintaining programs
 209 .TP
 210 .B nofail
 211 do not report errors for this device if it does not exist.
 212 .RE
 213
 214 .B The fifth field
 215 .RI ( fs_freq ).
 216 .RS
 217 This field is used for these filesystems by the
 218 .BR dump (8)
 219 command to determine which filesystems need to be dumped.  If the fifth
 220 field is not present, a value of zero is returned and
 221 .B dump
 222 will assume that the filesystem does not need to be dumped.
 223 .RE
 224
 225 .B The sixth field
 226 .RI ( fs_passno ).
 227 .RS
 228 This field is used by the
 229 .BR fsck (8)
 230 program to determine the order in which filesystem checks are done at
 231 reboot time.  The root filesystem should be specified with a
 232 .I fs_passno
 233 of 1, and other filesystems should have a
 234 .I fs_passno
 235 of 2.  Filesystems within a drive will be checked sequentially, but
 236 filesystems on different drives will be checked at the same time to utilize
 237 parallelism available in the hardware.  If the sixth field is not present
 238 or zero, a value of zero is returned and
 239 .B fsck
 240 will assume that the filesystem does not need to be checked.
 241 .RE
 242
 243 The proper way to read records from
 244 .B fstab
 245 is to use the routines
 246 .BR getmntent (3)
 247 or
 248 .BR libmount .
 249 .SH FILES
 250 .IR /etc/fstab ,
 251 .I <fstab.h>
 252 .SH "SEE ALSO"
 253 .BR mount (8),
 254 .BR swapon (8),
 255 .BR fs (5),
 256 .BR nfs (5),
 257 .BR xfs (5),
 258 .BR proc (5),
 259 .BR getmntent (3)
 260 .SH HISTORY
 261 The ancestor of this
 262 .B fstab
 263 file format appeared in 4.0BSD.
 264 .\" But without comment convention, and options and vfs_type.
 265 .\" Instead there was a type rw/ro/rq/sw/xx, where xx is the present 'ignore'.
 266 .SH AVAILABILITY
 267 This man page is part of the util-linux package and is available from
 268 ftp://ftp.kernel.org/pub/linux/utils/util-linux/.