mount - Unix, Linux Command

mount -a [-fFnrsvw] [-t vfstype] [-O optlist] 
mount [-fnrsvw] [-o options [,...]] device | dir 
mount [-fnrsvw] [-t vfstype] [-o options] device dir 

The standard form of the
mount command, is

mount -t type device dir This tells the kernel to attach the file system found on
device (which is of type
type) at the directory
dir. The previous contents (if any) and owner and mode of
dir become invisible, and as long as this file system remains mounted,
the pathname
dir refers to the root of the file system on
device. 

Three forms of invocation do not actually mount anything:

mount -h prints a help message;

mount -V prints a version string; and just
mount [-l] [-t type] lists all mounted file systems (of type
type). The option -l adds the (ext2, ext3 and XFS) labels in this listing.
See below.


Since Linux 2.4.0 it is possible to remount part of the
file hierarchy somewhere else. The call is

mount --bind olddir newdir After this call the same contents is accessible in two places.
One can also remount a single file (on a single file).


This call attaches only (part of) a single filesystem, not possible
submounts. The entire file hierarchy including submounts is attached
a second place using

mount --rbind olddir newdir 

Note that the filesystem mount options will remain the same as those
on the original mount point, and cannot be changed by passing the -o
option along with --bind/--rbind.


Since Linux 2.5.1 it is possible to atomically move a mounted tree
to another place. The call is

mount --move olddir newdir 

Since Linux 2.6.15 it is possible to mark a mount and its submounts as shared,
private, slave or unbindable. A shared mount provides ability to create mirrors
of that mount such that mounts and umounts within any of the mirrors propagate
to the other mirror. A slave mount receives propagation from its master, but
any not vice-versa.  A private mount carries no propagation abilities.  A
unbindable mount is a private mount which cannot cloned through a bind
operation. Detailed semantics is documented in Documentation/sharedsubtree.txt
file in the kernel source tree.

mount --make-shared mountpoint 
mount --make-slave mountpoint 
mount --make-private mountpoint 
mount --make-unbindable mountpoint 

The following commands allows one to recursively change the type of all the
mounts under a given mountpoint.

mount --make-rshared mountpoint 
mount --make-rslave mountpoint 
mount --make-rprivate mountpoint 
 "mount --make-runbindable mountpoint"


The
proc file system is not associated with a special device, and when
mounting it, an arbitrary keyword, such as
proc can be used instead of a device specification.
(The customary choice
none is less fortunate: the error message ‘none busy’ from
umount can be confusing.)


Most devices are indicated by a file name (of a block special device), like
/dev/sda1, but there are other possibilities. For example, in the case of an NFS mount,
device may look like
knuth.cwi.nl:/dir. It is possible to indicate a block special device using its
volume label or UUID (see the -L and -U options below).


The file
/etc/fstab (see
fstab(5)),
may contain lines describing what devices are usually
mounted where, using which options. This file is used in three ways:


(i) The command

mount -a [-t type] [-O optlist] (usually given in a bootscript) causes all file systems mentioned in
fstab (of the proper type and/or having or not having the proper options)
to be mounted as indicated, except for those whose line contains the
noauto keyword. Adding the
-F option will make mount fork, so that the
filesystems are mounted simultaneously.


(ii) When mounting a file system mentioned in
fstab, it suffices to give only the device, or only the mount point.


(iii) Normally, only the superuser can mount file systems.
However, when
fstab contains the
user option on a line, anybody can mount the corresponding system.


Thus, given a line

/dev/cdrom  /cd  iso9660  ro,user,noauto,unhide any user can mount the iso9660 file system found on his CDROM
using the command

mount /dev/cdrom or

mount /cd For more details, see
fstab(5).
Only the user that mounted a filesystem can unmount it again.
If any user should be able to unmount, then use
users instead of
user in the
fstab line.
The
owner option is similar to the
user option, with the restriction that the user must be the owner
of the special file. This may be useful e.g. for
/dev/fd if a login script makes the console user owner of this device.
The
group option is similar, with the restriction that the user must be
member of the group of the special file.


The programs
mount and
umount maintain a list of currently mounted file systems in the file
/etc/mtab. If no arguments are given to
mount, this list is printed.


When the
proc filesystem is mounted (say at
/proc), the files
/etc/mtab and
/proc/mounts have very similar contents. The former has somewhat
more information, such as the mount options used,
but is not necessarily up-to-date (cf. the
-n option below). It is possible to replace
/etc/mtab by a symbolic link to
/proc/mounts, and especially when you have very large numbers of mounts
things will be much faster with that symlink,
but some information is lost that way, and in particular
working with the loop device will be less convenient,
and using the "user" option will fail.




Options available for the
mount command:


For most types all the
mount program has to do is issue a simple
mount(2)
system call, and no detailed knowledge of the filesystem type is required.
For a few types however (like nfs, nfs4, cifs, smbfs, ncpfs) ad hoc code is
necessary. The nfs ad hoc code is built in, but cifs, smbfs, and ncpfs
have a separate mount program. In order to make it possible to
treat all types in a uniform way, mount will execute the program
/sbin/mount.TYPE (if that exists) when called with type
TYPE. Since various versions of the
smbmount program have different calling conventions,
/sbin/mount.smbfs may have to be a shell script that sets up the desired call.


If no
-t option is given, or if the
auto type is specified, mount will try to guess the desired type.
If mount was compiled with the blkid library, the guessing is done
by this library. Otherwise, mount guesses itself by probing the
superblock; if that does not turn up anything that looks familiar,
mount will try to read the file
/etc/filesystems, or, if that does not exist,
/proc/filesystems. All of the filesystem types listed there will be tried,
except for those that are labeled "nodev" (e.g.,
devpts, proc, nfs, and
nfs4). If
/etc/filesystems ends in a line with a single * only, mount will read
/proc/filesystems afterwards.


The
auto type may be useful for user-mounted floppies.
Creating a file
/etc/filesystems can be useful to change the probe order (e.g., to try vfat before msdos
or ext3 before ext2) or if you use a kernel module autoloader.
Warning: the probing uses a heuristic (the presence of appropriate ‘magic’),
and could recognize the wrong filesystem type, possibly with catastrophic
consequences. If your data is valuable, don’t ask
mount to guess.


More than one type may be specified in a comma separated
list.  The list of file system types can be prefixed with
no to specify the file system types on which no action should be taken.
(This can be meaningful with the
-a option.)


For example, the command:


It is different from
-t in that each option is matched exactly; a leading
no at the beginning of one option does not negate the rest.


The
-t and
-O options are cumulative in effect; that is, the command


A commonly used option for removable media is
context=system_u:object_r:removable_t. 

Two other options are
fscontext= and
defcontext=, both of which are mutually exclusive of the context option. This means you
can use fscontext and defcontext with each other, but neither can be used with
context.


The
fscontext= option works for all filesystems, regardless of their xattr
support. The fscontext option sets the overarching filesystem label to a
specific security context. This filesystem label is separate from the
individual labels on the files. It represents the entire filesystem for
certain kinds of permission checks, such as during mount or file creation.
Individual file labels are still obtained from the xattrs on the files
themselves. The context option actually sets the aggregate context that
fscontext provides, in addition to supplying the same label for individual
files.


You can set the default security context for unlabeled files using
defcontext= option. This overrides the value set for unlabeled files in the policy and requires a
file system that supports xattr labeling.


For more details see
selinux(8)




What options are supported depends a bit on the running kernel.
More info may be found in the kernel source subdirectory
Documentation/filesystems. 

















% mount /k -o minixdf; df /k; umount /k
Filesystem   1024-blocks  Used Available Capacity Mounted on
/dev/sda6      2630655   86954  2412169      3%   /k
% mount /k -o bsddf; df /k; umount /k
Filesystem   1024-blocks  Used Available Capacity Mounted on
/dev/sda6      2543714      13  2412169      0%   /k



% mount /k -o minixdf; df /k; umount /k
Filesystem   1024-blocks  Used Available Capacity Mounted on
/dev/sda6      2630655   86954  2412169      3%   /k
% mount /k -o bsddf; df /k; umount /k
Filesystem   1024-blocks  Used Available Capacity Mounted on
/dev/sda6      2543714      13  2412169      0%   /k












For file systems mounted in binary mode, a conversion tool
(fromdos/todos) is available.








Normal
iso9660 filenames appear in a 8.3 format (i.e., DOS-like restrictions on filename
length), and in addition all characters are in upper case.  Also there is
no field for file ownership, protection, number of links, provision for
block/character devices, etc.


Rock Ridge is an extension to iso9660 that provides all of these unix like
features.  Basically there are extensions to each directory record that
supply all of the additional information, and when Rock Ridge is in use,
the filesystem is indistinguishable from a normal UNIX file system (except
that it is read-only, of course).












Especially useful options include




Especially useful options include




























Defines the behaviour for creation and display of filenames which fit into
8.3 characters. If a long name for a file exists, it will always be
preferred display. There are four modes:


The default is "lower".













  mount /tmp/fdimage /mnt -t msdos -o loop=/dev/loop3,blocksize=1024 


will set up the loop device
/dev/loop3 to correspond to the file
/tmp/fdimage, and then mount this device on
/mnt. 

This type of mount knows about three options, namely
loop, offset and encryption, that are really options to
 losetup(8).
(These options can be used in addition to those specific
to the filesystem type.)


If no explicit loop device is mentioned
(but just an option ‘-o loop’ is given), then
mount will try to find some unused loop device and use that.
If you are not so unwise as to make
/etc/mtab a symbolic link to
/proc/mounts then any loop device allocated by
mount will be freed by
umount. You can also free a loop device by hand, using ‘losetup -d’, see
losetup(8).







mount (2)
mount (2)
umount (2)
umount (2)
umount (8)
umount (8)
swapon (8)
swapon (8)
e2label (8)
e2label (8)
xfs_admin (8)
xfs_admin (8)
mountd (8)
mountd (8)
nfsd (8)
nfsd (8)
mke2fs (8)
mke2fs (8)
tune2fs (8)
tune2fs (8)
losetup (8)
losetup (8)

Some Linux file systems don’t support
-o sync and -o dirsync (the ext2, ext3, fat and vfat file systems
do support synchronous updates (a la BSD) when mounted with the
sync option).


The
-o remount may not be able to change mount parameters (all
ext2fs-specific parameters, except
sb, are changeable with a remount, for example, but you can’t change
gid or
umask for the
fatfs). 

Mount by label or uuid will work only if your devices have the names listed in
/proc/partitions. In particular, it may well fail if the kernel was compiled with devfs
but devfs is not mounted.


It is possible that files
/etc/mtab and
/proc/mounts don’t match. The first file is based only on the mount command options, but the
content of the second file also depends on the kernel and others settings (e.g.
remote NFS server. In particular case the mount command may reports unreliable
information about a NFS mount point and the /proc/mounts file usually contains
more reliable information.)


Checking files on NFS filesystem referenced by file descriptors (i.e. the
fcntl and
ioctl families of functions) may lead to inconsistent result due to the lack of
consistency check in kernel even if noac is used.


Advertisements


    129 Lectures 
     23 hours 

 Eduonix Learning Solutions

    5 Lectures 
     4.5 hours 

 Frahaan Hussain

    35 Lectures 
     2 hours 

 Pradeep D

    41 Lectures 
     2.5 hours 

 Musab Zayadneh

    46 Lectures 
     4 hours 

 GUHARAJANM

    6 Lectures 
     4 hours 

 Uplatz
 Print
 Add Notes
 Bookmark this page