MOUNT(2)
π MOUNT(2) π
okay bestie, this is the System Calls Manual page for MOUNT(2), and we're about to make file systems make sense. buckle up π
πΈ NAME πΈ
mount, nmount, unmount β mount or dismount a file system
π©· LIBRARY π©·
Standard C Library (libc, -lc) β that's the one you're already linking against, no cap β¨
β¨ SYNOPSIS β¨
#include <sys/param.h>
#include <sys/mount.h>
int
mount(const char *type, const char *dir, int flags, void *data);
int
unmount(const char *dir, int flags);
#include <sys/uio.h>
int
nmount(struct iovec *iov, u_int niov, int flags);
π¦ DESCRIPTION π¦
okay so mount() is the system call that grafts a file system object onto the system file tree, right at the point dir. the data argument describes the file system object that's getting mounted, and type tells the kernel how to interpret data (peep type down below π). once it's mounted, the contents of that file system become available through the new mount point dir. and the way that any files that were chillin' in dir at the time of a successful mount get swept under the carpet (their words, not mine π) and are unavailable until the file system is unmounted? iconic. not you losing your files to a mount, bestie, it's giving trapdoor.
nmount() behaves similarly to mount(), except the mount options (file system type name, device to mount, mount-point name, etc.) get passed as an array of name-value pairs in the array iov, containing niov elements. the following options are required by all file systems:
fstypeβ file system type name (e.g., βprocfsβ)fspathβ mount point pathname (e.g., β/procβ)
depending on the file system type, other options may be recognized or required; for example, most disk-based file systems require a βfromβ option containing the pathname of a special device, in addition to the options listed above. so read the fine print, bestie π«Ά
by default only the super-user may call the mount() system call. this restriction can be removed by setting the vfs.usermount sysctl(8) variable to a non-zero value; see the BUGS section for more information (and like, actually see it, it's important π).
the following flags may be specified to suppress default semantics which affect file system access:
MNT_RDONLYβ the file system should be treated as read-only; even the super-user may not write on it. specifyingMNT_UPDATEwithout this option will upgrade a read-only file system to read/write. glow-up but make it filesystem πMNT_NOEXECβ do not allow files to be executed from the file system.MNT_NOSUIDβ do not honor setuid or setgid bits on files when executing them. this flag is set automatically when the caller is not the super-user.MNT_NOATIMEβ disable update of file access times.MNT_SNAPSHOTβ create a snapshot of the file system. this is currently only supported on UFS2 file systems, seemksnap_ffs(8)for more information.MNT_SUIDDIRβ directories with the SUID bit set chown new files to their own owner. this flag requires theSUIDDIRoption to have been compiled into the kernel to have any effect. see themount(8)andchmod(2)pages for more information.MNT_SYNCHRONOUSβ all I/O to the file system should be done synchronously.MNT_ASYNCβ all I/O to the file system should be done asynchronously.MNT_FORCEβ force a read-write mount even if the file system appears to be unclean. Dangerous. together withMNT_UPDATEandMNT_RDONLY, specify that the file system is to be forcibly downgraded to a read-only mount even if some files are open for writing. β οΈMNT_NOCLUSTERRβ disable read clustering.MNT_NOCLUSTERWβ disable write clustering.
the flag MNT_UPDATE indicates that the mount command is being applied to an already mounted file system. this allows the mount flags to be changed without requiring that the file system be unmounted and remounted. some file systems may not allow all flags to be changed. for example, many file systems will not allow a change from read-write to read-only. rude but okay π
the flag MNT_RELOAD causes the vfs subsystem to update its data structures pertaining to the specified already mounted file system.
the type argument names the file system. the types of file systems known to the system can be obtained with lsvfs(1). go check, it's a whole menu π
the data argument is a pointer to a structure that contains the type specific arguments to mount. the format for these argument structures is described in the manual page for each file system. by convention, file system manual pages are named by prefixing mount_ to the name of the file system as returned by lsvfs(1). thus the NFS file system is described by the mount_nfs(8) manual page. it should be noted that a manual page for default file systems, known as UFS and UFS2, does not exist. yeah. it's just not there. no notes π
the unmount() system call disassociates the file system from the specified mount point dir.
the flags argument may include MNT_FORCE to specify that the file system should be forcibly unmounted even if files are still active. active special devices continue to work, but any further accesses to any other active files result in errors even if the file system is later remounted. so like, they keep working but everything else is a mess π
if the MNT_BYFSID flag is specified, dir should instead be a file system ID encoded as βFSID:val0:val1β, where val0 and val1 are the contents of the fsid_t val[] array in decimal. the file system that has the specified file system ID will be unmounted. very main character of it to be identified by number β¨
π RETURN VALUES π
upon successful completion, the value 0 is returned; otherwise the value -1 is returned and the global variable errno is set to indicate the error. so always check errno, bestie, she's the one with the tea π
π ERRORS π
the mount() and nmount() system calls will fail when one of the following occurs:
[EPERM]β the caller is neither the super-user nor the owner ofdir.[ENAMETOOLONG]β a component of a pathname exceeded 255 characters, or the entire length of a path name exceeded 1023 characters.[ELOOP]β too many symbolic links were encountered in translating a pathname.[ENOENT]β a component ofdirdoes not exist.[ENOTDIR]β a component of name is not a directory, or a path prefix of special is not a directory.[EBUSY]β another process currently holds a reference todir.[EFAULT]β thedirargument points outside the process's allocated address space.[EIO]β an I/O error occurred while reading data from special.[EINTEGRITY]β the backing store for special detected corrupted data while reading.
the following errors can occur for a ufs file system mount:
[ENODEV]β a component ofufs_argsfspec does not exist.[ENOTBLK]β the fspec argument is not a block device.[ENXIO]β the major device number of fspec is out of range (this indicates no device driver exists for the associated hardware).[EBUSY]β fspec is already mounted.[EMFILE]β no space remains in the mount table.[EINVAL]β the super block for the file system had a bad magic number or an out of range block size.[ENOMEM]β not enough memory was available to read the cylinder group information for the file system.[EIO]β an I/O error occurred while reading the super block or cylinder group information.[EFAULT]β the fspec argument points outside the process's allocated address space.
the following errors can occur for a nfs file system mount:
[ETIMEDOUT]β Nfs timed out trying to contact the server. server's not answering, bestie, we've all been there π[EFAULT]β some part of the information described bynfs_argspoints outside the process's allocated address space.
the unmount() system call may fail with one of the following errors:
[EPERM]β the caller is neither the super-user nor the user who issued the correspondingmount()call.[ENAMETOOLONG]β the length of the path name exceeded 1023 characters.[EINVAL]β the requested directory is not in the mount table.[ENOENT]β the file system ID specified usingMNT_BYFSIDwas not found in the mount table.[EINVAL]β the file system ID specified usingMNT_BYFSIDcould not be decoded.[EINVAL]β the specified file system is the root file system. you cannot unmount the root, absolutely not, that's the whole vibe π[EBUSY]β a process is holding a reference to a file located on the file system.[EIO]β an I/O error occurred while writing cached file system information.[EFAULT]β thedirargument points outside the process's allocated address space.
π SEE ALSO π
lsvfs(1), mksnap_ffs(8), mount(8), umount(8)
π HISTORY π
the mount() and unmount() functions appeared in Version 1 AT&T UNIX. the nmount() system call first appeared in FreeBSD 5.0. elders of the game fr fr π
π BUGS π
some of the error codes need translation to more obvious messages. yeah they're a little cryptic, we know π
allowing untrusted users to mount arbitrary media, e.g. by enabling vfs.usermount, should not be considered safe. most file systems in FreeBSD were not built to safeguard against malicious devices. so like, don't hand the aux to strangers, bestie, that's not the move π«
and that's the whole page!! this was the MOUNT(2) manual from Debian, dated March 30, 2020 β tysm for reading, go mount something responsibly, mwah πβ¨
π¦ where this page comes from
- debian bookworm: freebsd-manpages 12.2-1 Β· BSD-2-Clause-FreeBSD AND BSD-4-Clause
- debian trixie: freebsd-manpages 12.2-2 Β· BSD-2-Clause-FreeBSD AND BSD-4-Clause
- ubuntu jammy: freebsd-manpages 12.2-1 Β· BSD-2-Clause-FreeBSD AND BSD-4-Clause
- ubuntu noble: freebsd-manpages 12.2-1 Β· BSD-2-Clause-FreeBSD AND BSD-4-Clause
- ubuntu questing: freebsd-manpages 12.2-2
- ubuntu resolute: freebsd-manpages 12.2-2build1 Β· BSD-2-Clause-FreeBSD AND BSD-4-Clause
- ubuntu stonking: freebsd-manpages 12.2-2build1 Β· BSD-2-Clause-FreeBSD AND BSD-4-Clause
- Copyright (c) 1980, 1989, 1993 The Regents of the University of California. All rights reserved
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash on : a language model's rewrite of the original, under its terms