- Similar/related info
When mounting a drive, two key pieces of required information are the name assigned to the drive, and the destination location. This destination location is what is typically called the “mount point”. As for the name assigned to the drive, this is discussed on the page about making a filesystem: section about a destination name. (Mounting generally suggests that the filesystem had already been created, so don't plan to follow all of the steps about making a filesystem, but the specific section about the destination name may provide details about the name of the device.)
- Deciding what mount point(s) to use
This isn't something that is strictly needed to be decided before partitioning: setting up mount points is something that occurs after partitioning. For instance, if one big MBR partition is made, the data could later be organized by a BSDlabel/disklabel so there is basically one filesystem, or multiple. Such a decision could, in theory, be made after the MBR partitioning is completed.
However, decisions about mount points need to be made (whether manually or automatically) at some point in time, and there may be some cases where this could impact decisions about how partitions are made. Some people will likely have strong opinions or feelings about disk layouts being better when certain directories have their own mount points. Considering these mount points may have an impact on partitions.
Why have different mount points? Perhaps one reason is to use partition size as a method of acting like a quota. Then if there is a problem, such as outgoing E-Mail in /var/spool being too large, that problem may affect E-Mail but won't be as likely to also cause other problems, like /var/log being unable to further log things because /var filled up. Similarly, if a problem gets logged several times per second and /var/log fills up, incoming E-Mail can still function if /var/mail is on a separate mount point. Separating the mount points doesn't fix the problem which still needs to be fixed, and of course such problems are best to entirely avoid from happening in the first place (by monitoring free disk space and making adjustments if needed), but the mount point separation can simply reduce the expected negative impacts caused by certain disk areas filling up.
Another reason for different mount points is so that different mount options may be used. There can be some advantages, including security advantages, to doing this.
Moving data from one partition to another disk with more space may be easiest to do by copying data and then mounting a new location, stored on the new disk, at the old mount point. By having smaller mount points, this option may easily exist for smaller modules of data. err, re-write that.
Safety. If an entire operating system is going to be re-installed, someone can unmount /home and then not worry so much about whether a command will recursively traverse mount points of the mounted partitions.
Another reason is that creating a separate partition can allow the partition to be formatted. OpenBSD FAQ 4: (more) Disklabel information) describes why the OpenBSD installer may, by default if space allows, create a separate mount point for /usr/obj/. “Having this directory a separate mount point allows it to be formatted rather than erased file by file, which can be significantly faster.”
- Mount points for DOS
Typically the only “mount points” commonly used by software running in DOS would be the DOS drive letters. These drive letters get assigned to primary paritions, and appropriate spaces in the first detected “extended partition”, but only for sections of the disk are using one of the specifically supported values for its partition “type” identifier. Whether or not there is a valid file system does not matter. (If there is not a valid file system, a drive letter will be assigned anyway. This allows the
command to create a file system if needed.)
As a generalized rule, the first usable fixed disk primary partition is assigned the letter C:. The letter A: is used for a floppy disk drive, or perhaps a device acting like a floppy disk, such as a CD-ROM's floppy disk image when El Torito is being used. The B: is typically meant to be a second floppy disk drive, although it may be a clone of A: if there is no second drive. If El Torito is emulated a floppy disk, B: may actually be the first floppy disk drive.
There may be some variations in how these are assigned: Some versions of DOS may hide all primary partitions after the first recognized parimary partition on a drive. Another version may assign a drive letter to such primary partitions after the first recognized primary partition of each drive has been assigned a drive letter.
Microsoft KB Q51978: Order in Which MS-DOS and Windows Assign Drive Letters, Microsoft KB Q62571: Converting Drive Letters to MS-DOS INT 13H Disk Drive Numbers, Wikipedia's article on “Drive letter assignment”.
(Note that although the KB Q51978 mentions that up to eight physical drives are supported, a lot of hardware from that era relied on IDE configurations that supported two standard IDE ports, each capable of two drives. Also there may have been one floppy drive port capable of two drives, but supporting eight physical drives was not commonly supported by most consumer-level equipment.)
Other drives, such as devices using ATAPI (like optical drives) or RAM drives, will be assigned a drive letter as determined by the driver. Typically this may end up being the first available drive letter that comes after the last drive letter that was automatically assigned to a partition on a fixed disk.
Some drive letters may be a bit customizable, such as those created with
or, if Microsoft networking is being used, “
”. There might be a way to swap drive letters using
(e.g. as shown by MS KB Q61848) although using the
command may be dangerous, so this method is generally not recommended. Drive letters may be swapped using Robert Muchsel's
SwapDrv is free” as noted by the program's documentation: this is bundled with HPFSDOS 1.00.
- Mount points for Windows
The available options depend a bit on the version of Windows. Windows 3.x and Win9x will be similar to MS-DOS. Microsoft KB Q234048: How Windows 2000 Assigns, Reserves, and Stores Drive Letters, Microsoft KB Q93373: Default Drive Letters and Partitions in Windows NT says, “Note: Only recognized partition types (1, 4, 6, 7) are assigned drive letters. ”
Drives may also be commonly referenced by the device object names. (See: Device Names/device adadresses.) Using a device name (that starts with \Device) might not (and probably is not) not most end users directly reference a device, but it may be fairly frequently done indirectly because software may commonly reference a drive using a name that starts with \Device.
Mount points are often specified by means other than just automatic detection during the system's starutp. In an Active Directory environment, a user's home directory may be specified on the user's Profile tab in the Active Directory Users & Computers program. Scripts may be loaded from somewhere like (the following example may need to be adjusted) \\Servername\SYSVol\domainName\scripts\. Other scripts may be stored elsewhere under \\Servername\SYSVol\ and referenced by group policies. Home directoreis may be specified with command lines, as noted by Microsoft KB Q320043.
Commonly when a user logs in, mount points may become mounted. For a network, this may include a reference to one or more network drives. Commonly, a home directory may be set up for a user: Microsoft KB Q101507: How Windows NT Determines a User's Home Directory
Additional methods to create a mounted drive may exist. For example, some software may be downloaded: see disk images which, for example, describes software for mounting CD ISO images.
NirSoft has a program called DriveLetterView that may show or impact some drive letter assignments (especially USB devices that have been used, possibly even if they are not actively connected).
- Mount points for Unix
Mount points that are being used are any mount points that show up in the third column (after the second column which is the word “
”) when running the
command with no parameters. This may include manually-created mount points (that were created by manually running the
with parameters). The most common reference point for available, easily used mount points that have been pre-defined is by looking in the “file system table” which is in the /etc/fstab file.
To quote OpenBSD's FAQ as an example: “For your first attempt at an experimentation system, one big / partition and swap may be easiest until you know how much space you need. By doing this you will be sacrificing some of the default security features of OpenBSD that require separate filesystems for /, /tmp, /var, /usr and /home. However, you probably should not be going into production with your first OpenBSD install.”
What that sentence doesn't elaborate on is what the additional security features may be. Note that various versions of Unix may have some variances: for example, some configuration files may be stored in /usr and that folder may need to be writable. For some other operating systems, /usr really does not need to be written to except when installing programs (to whatever area where the system tends to store installed programs: often that may be under /usr and perhaps more specifically under /usr/local). For such systems, the /usr directory should writable early when the operating system is set up and other programs need to be installed. However, after writing the critical programs, /usr may be able to be set read-only. This could reduce the ease of an attacker that may want to place modified code into /usr/. Other practices may include /dev being part of / but assigning most other folders with the “nodev” mount option, and assigning “nosuid” to folders other than / and /usr.
Note that there is some standardization about mount points and where files are located, although different versions of Unix and derivatives/clones may have their own variances. Some may value their variations, perhaps due to historical reasons, more than a desire to standardize (particularly if the method specified by the standards is something that the operating system developers disagree with, perhaps with notable reasons). For some details, see a man page called hier (e.g. OpenBSD's man page for “hier”), documentation meant for new system administrators of an operating system (e.g. OpenBSD's installation software refers new system administrators to OpenBSD's man page for “afterboot”), and other standardization efforts (Linux's “Filesystem Hierarchy Standard” (“FHS”), and perhaps others like LSB?).
Here are some subdirectories that may have their own mount points. (For others, see the documented standards for the platform, referencing the documentation mentioned above.)
- [#slashdir]: /
The top-level directory is often called the “root” directory. Care should be taken to avoid confusion with the /root directory, perhaps by calling / the top-level directory and referencing the punctuation whenever referring to /root (by calling it “slash root”).
Generally operating system kernels will go on this mount point (either in the top-level (/, often called “root”) folder or a subdirectory under this folder (such as the /boot/ directory. /etc/ may frequently, typically, go under this mount point. (The /etc/ folder may be used for storing information about what happens when the system starts, including scripts that are run automatically and including the /etc/fstab file that stores information about the other mount points.)
Other directories that may commonly go here is /media/ and /mnt/ because the file system used for / is typically sufficient, both in terms of feature offered and in terms of space available. (Having enough space available is not primarily due to / typically being overly large, as / is very often not very large. Rather, it is because the /media/ and /mnt/ directories typically house empty directories and directories that are used as mount points, so these two directories don't require much space.
- [#saltroot]: /altroot/
- Basically a copy of a root directory. (Is that / or ~root?) Implemented by OpenBSD. (Not sure how much more widespread this is.)
- [#sdevdir]: /dev/
The /dev location is typically filled with “devices” rather than standard files. /dev may be implemented using a “file system” which is called devfs and is designed to make these sort of “devices”. By making device objects which are accessible via the file system, software can communicate to actual devices using the same standardized communication procedures that can be used to read from a file and write to a file. This capability has cleverly been implemented in some very useful ways, such as allowing user-based permissions to be implemented for device as easily as they are implemented for files.
- [#shomedir]: /home/
This is meant to be where end user data is often stored.
Actually, data for a specific end user is most commonly in whatever location is specified, by the /etc/passwd file, for that end user. That folder is the HOME environmental variable, and many shells can reference the variable with a syntax such as $HOME. Many shells will allow the folder to be specified with a syntax of ~ to refer to the logged in user, and ~username to specify any arbitrary username.
However, despite all these conventions, there is also a location which is most common for a user's data to be stored. That is to have the folder be stored under /home/ and be named after the end user. If the user's username is “uname”, then the folder may be /home/uname/.
- [#soptdir]: /opt/
- Part of FHS, this is a location where packages may be installed to. However, this may be more theoritical than something widely put into practice. Many operating systems will actually store such information into /usr (quite often in /usr/local).
- [#sprocdir]: /proc/
This directory may be implemented using the “procfs” file system and the objects that seem similar to files may not really be static files. They may be dynamically generated objects created as needed by the implementation of the procfs file system that is mounted at /proc.
Typically supported on Linux, a subset of the functionality may be implemented on similar systems, such as BSD systems. For example, OpenBSD Manual Page for the
command describes an offering. If the support isn't bundled with the operating system, perhaps it is available after installing an external package that provides the functionality. (The relevant package may be rather specific to implemented procfs or the /proc folder, or it may be a larger package that provides even more compatability with Linux or LSB or a variation of Linux such as Fedora Core.)
Perhaps see also: kernfs. e.g. OpenBSD CVSWeb: Kernfs code (in an attic). This had been mounted as shown by kernfs mounting shows using a command line, while Virtual Ethernet Tunneling shows an example using the /etc/fstab file.
Wayback Machine @ Archive.org's cache of a file about the /proc filesystem, and another copy of the file about the /proc filesystem, and a formatted MJMWired Kernel Documentation: file about the /proc filesystem. Linux Mafia Suse documentation: chapter 3 may have some of the same info. OpenBSD Manual Page for the
command mentions the purpose of subdirectories supported by the implementation being documented.
- [#ssrvdir]: /srv/
- Part of FHS. The intent of /srv is to store data related to the primary services of this computer. However, in reality, such data often has other pre-established locations, such as /var/spool for outgoing mail. How much sense it makes to have this be a mount point may depend largely on how much space is taken up by the data in /srv/.
- [#stmpdir]: /tmp/
- /tmp is typically writable by any users. This may be one of only two folders that users typically can write to directly with very little restriction. The other such folder is the user's individual home directory. However, unlike the user's home directory which is typically not shared for other users to have access to, /tmp is a single location that multiple end users may have file system permissions to write to. Furthermore, it is generally not desirable that end users can read the files of other end users, so permissions for /tmp is a bit unique. Although not universally implemented in all Unix operating systems, at least one implementation (OpenBSD) may delete /tmp as part of the operating system's startup procedure. It is therefore essential that there is not an intent to store important data in /tmp on a long term basis.
- [#susrdir]: /usr/
(This description also covers other /usr/local/
*that match /usr/
*, such as a /usr/local/src/ directory).
- [#usurobj]: /usr/obj/
- OpenBSD FAQ 4: (more) Disklabel information) describes why the OpenBSD installer may, by default if space allows, create a separate mount point for /usr/obj/. “Having this directory a separate mount point allows it to be formatted rather than erased file by file, which can be significantly faster.”
- [#usursrc]: /usr/src
Source code (for the operating system).
In the case of OpenBSD, this is typically where the base operating system goes. Some other categories of source code may go in other locations (e.g. /usr/ports/ for source code related to third party software, and /usr/xenocara/ for the X Windows distribution). Using OpenBSD as an example, details about using this sort of data is covered in the section about updating OpenBSD via source code.
- e.g. /usr/X11R6
- [#svardir]: /var
- [#varcrash]: /var/crash
OpenBSD's manual page for “crash” says, “When the system crashes it writes (or at least attempts to write) an image of memory, including the kernel image, onto the dump device. On reboot, the kernel image and memory image are separated and preserved in the directory /var/crash.” (That manual page goes on to describe how to use the files.) Based on the filenames mentioned by that manual page, it appears the files get placed there using the command described by OpenBSD's manual page for the
- [#svarslog]: /var/log
- [#svarmail]: /var/mail
Incoming mail spool. By having a separate filesystem for this, if incoming mail fills up the filesystem, the remaining portions of the server might be less likely to experience negative consequences, limiting the impact from problems.
- [#varspool]: /var/spool
- Outgoing mail spool/queue. By having a separate filesystem for this, if the outgoing mail queue fills up the filesystem, the remaining portions of the server might be less likely to experience negative consequences, limiting the impact from problems.
- [#svarstmp]: /var/tmp
- [#svarswww]: /var/www
- Web pages. Subfolders may belong to end users, and a symlink may commonly be placed in end user folders which redirects them so files can easily be placed here. Quotas which are individualized for each end user may be applied and enforced.
In addition to those directories which are commonly given mount points, here are some directories that are commonly used and may be worth knowing about (even if they aren't typically implemented using separate mount points).
- [#sbindir]: /bin
Contains some of the most basic commands that may often be needed by end user programs. (Basic commands that may commonly require superuser access may commonly be placed in the /sbin/ directory.) As a generalization, commands in this directory may commonly be designed to work with end user files. (Commands that make changes to other aspects of a system, like working with disks/partitions or changing network settings, may be more commonly placed in the /sbin/ directory.)
- [#setcdir]: /etc/
Wikipedia's “Filesystem Hierarchy Standard” section on “Directory Structure” notes about that despite some disagreements, “in early versions of the UNIX Implementation Document from Bell labs, the section for /etc is clearly commented as etcetra directory,” “as this directory historically held everything that did not belong elsewhere”. (The Wikipedia quotes cite a PDF file.) However, some modern implementations have /etc limited strictly to text files. These text files are frequently configuration files, although many are also scripts that can be “executed” (by an interpretor).
This directory's name is clearly understood to be the common abbrviation for the word “etcetra”. Many people who discuss Unix may commonly say “etsee” when referring to this directory name.
- [#slostfnd]: /lost+found/
Files may be placed here by the file system checking command
. (For further details, see testing/repairing filesystem volumes: section about found file fragments.
- [#slshmedi]: /media/
The FHS standard has specified that removable media should be mounted under /media. A common example may be to have the data from the /dev/cdrom “device” object be mounted under /media/cdrom. This is a relatively new standard: older systems may have such media mounted under /mnt/.
- [#smntdir]: /mnt/
Currently this is the recommended place for the mount points used for fixed drives and remote file systems. In the past, /mnt had been used for all sorts of mount points, although FHS has specified that /media be used for local removable media.
- [#ssbindir]: /sbin/
An area for superuser binary executable files. This may contain some core utilities, like
, which an administrator may commonly need, but which end users may commonly not need to be running on a multi-user machine. This doesn't necessarily mean that all commands in this directory are dangerous:
may be found in here.
- [#dirssys]: /sys/
- Wikipedia's page on “Filesystem Hierarchy Standard” notes, “Modern Linux distributions include a /sys directory as a virtual filesystem (sysfs, comparable to /proc, which is a procfs), which stores and allows modification of the devices connected to the system, whereas many traditional UNIX and Unix-like operating systems use /sys as a symbolic link to the kernel source tree.” It may be best to try using a different directory name, particularly if using the traditional usage of a standard directory which might conflict with defaults that might be set automatically on newer systems.