FS_MKMOUNT(1)

🎀 FS_MKMOUNT(1) — the ✨NAME✨ section 🎀

okay bestie, gather round, because fs_mkmount is the AFS command that creates a mount point for a volume and honestly it's kinda iconic. 💖

---

🦋 SYNOPSIS 🦋

fs mkmount -dir <directory> -vol <volume name>
    [-cell <cell name>] [-rw] [-fast] [-help]

fs mk -d <directory> -v <volume name>
    [-c <cell name>] [-r] [-f] [-h]

---

💅 DESCRIPTION 💅

so the way this works — fs mkmount makes a mount point for the volume you name in -vol, and it puts it at the spot in AFS file space you give it with -dir. no cap. 🫶

and this mount point? it looks like a totally normal directory element, and it straight up serves as the volume's root directory, but ngl it's actually a special file system object that points at an AFS volume. when the Cache Manager bumps into a mount point for the very first time while it's walking a pathname, it hits up the VL Server to find out which file server machines are holding that volume, then it pulls a copy of the volume's root directory from the right file server machine. main character behavior, fr fr. ✨

okay so you can technically make more than one mount point to a volume, but the manpage says that's not recommended, and lowkey the Cache Manager can get confused if a volume is mounted in two places along the same path through the filespace. so… don't. 🙈

the Cache Manager follows three basic rules when it's traversing the AFS filespace and runs into mount points:

👑 Rule 1: Access Backup and Read-only Volumes When Specified

if a mount point names a volume with either a .readonly or a .backup extension, the Cache Manager accesses only that type of volume. if the mount point has neither a .backup nor a .readonly extension, then the Cache Manager moves on to Rules 2 and 3.

for example: the Cache Manager never accesses the read/write version of a volume if the mount point names the backup version. and if the specified version is inaccessible, the Cache Manager reports an error. periodt. 💀

🌸 Rule 2: Follow the Read-only Path When Possible

if a mount point lives in a read-only volume and the volume it references is replicated, the Cache Manager tries to access a read-only copy of the volume. if the referenced volume is not replicated, then the Cache Manager accesses the read/write copy instead. so basically the Cache Manager is said to prefer a read-only path through the filespace, accessing read-only volumes whenever they're available. it's giving "read-only first, always." 📖

and why does it start on the read-only path in the first place? because it always accesses a read-only copy of the root.afs volume if one exists — that volume is mounted at the root of a cell's AFS filespace (named /afs by convention, bestie). so if the root.afs volume is replicated, the Cache Manager tries to access a read-only copy of it instead of the read/write copy. then this rule keeps the Cache Manager on a read-only path for as long as each successive volume is replicated.

the implication (iykyk): both the root.afs and root.cell volumes have to be replicated for the Cache Manager to access replicated volumes mounted below them in the AFS filespace. and those volumes are conventionally mounted at the /afs and /afs/cellname directories, respectively. 🗂️

🔥 Rule 3: Once on a Read/write Path, Stay There

if a mount point lives in a read/write volume and the volume name doesn't have a .readonly or a .backup extension, the Cache Manager tries to access only the read/write version of the volume. and if that read/write version is inaccessible, the access attempt fails with an error — even if a read-only version is accessible. 😭

so in this situation the Cache Manager is said to be on a read/write path, and it cannot switch back to the read-only path unless the mount point explicitly names a volume with a .readonly extension. (Cellular mount points are an important exception to this rule, as explained in the following discussion. 👀)

---

there are three types of mount points, and each one is right for a different purpose because of how the Cache Manager interprets them:

• when the Cache Manager crosses a regular mount point, it obeys all three of the mount point traversal rules we just talked about. to create a regular mount point, include only the required -dir and -vol arguments on the fs mkmount command. simple as. ✨
• when the Cache Manager crosses a read/write mount point, it tries to access only the volume version named in the mount point. if the volume name is the base (read/write) form, without a .readonly or .backup extension, the Cache Manager accesses the read/write version of the volume, even if it is replicated. in other words, the Cache Manager disregards the second mount point traversal rule when crossing a read/write mount point: it switches to the read/write path through the filespace. 🛤️

to create a read/write mount point, include the -rw flag on the fs mkmount command. and it's conventional to create only one read/write mount point in a cell's filespace, using it to mount the cell's root.cell volume just below the AFS filespace root (by convention, /afs/.cellname). see the OpenAFS Quick Start Guide for instructions, and the chapter about volume management in the OpenAFS Administration Guide for further discussion. 📚

creating a read/write mount point for a read-only or backup volume is acceptable, but unnecessary — the first rule of mount point traversal already says the Cache Manager accesses them if the volume name in a regular mount point has a .readonly or .backup extension. so like… redundant, bestie. 💅

• when the Cache Manager crosses a cellular mount point, it accesses the indicated volume in the specified cell, which is normally a foreign cell. (and if the mount point doesn't name a cell along with the volume, the Cache Manager accesses the volume in the cell where the mount point resides.) the Cache Manager disregards the third mount point traversal rule when crossing a regular cellular mount point: it accesses a read-only version of the volume if it's replicated, even if the volume that houses the mount point is read/write. switching to the read-only path like this is designed to avoid imposing undue load on the file server machines in foreign cells. 🌍

to create a regular cellular mount point, include the -cell argument on the fs mkmount command. and it's conventional to create cellular mount points only at the second level in a cell's filespace, using them to mount foreign cells' root.cell volumes just below the AFS filespace root (by convention, at /afs/foreign_cellname). this mount point lets local users access the foreign cell's filespace — assuming they have the necessary permissions on the ACL of the volume's root directory, and that there's an entry for the foreign cell in each local client machine's /etc/openafs/CellServDB file. 🗒️

and in the output of the fs lsmount command, the cell name and a colon (:) appear between the initial number sign and the volume name in a regular cellular mount point name. cute detail, fr fr. 💖

---

🌈 OPTIONS 🌈

• -dir <directory>+ — names the directory to create as a mount point. the directory must not already exist (no overachieving, bestie). relative pathnames get interpreted with respect to the current working directory.

⚠️ specify the read/write path to the directory, so you don't get the failure that comes from trying to create a new mount point in a read-only volume. by convention, the read/write path is indicated by putting a period before the cell name at the pathname's second level (for example, /afs/.example.com). for further discussion of the whole read/write and read-only paths through the filespace thing, see "DESCRIPTION" up above. 👆

• -vol <volume name> — specifies the name or volume ID number of the volume to mount. if appropriate, add the .readonly or .backup extension to the name, or specify the appropriate volume ID number. 🧚
• -cell <cell name> — names the cell in which the volume resides (which creates a cellular mount point). provide the fully qualified domain name, or a shortened form that disambiguates it from the other cells listed in the local /etc/openafs/CellServDB file.

if this argument is omitted, no cell indicator appears in the mount point — and when the Cache Manager interprets it, it assumes that the volume named in the mount point resides in the same cell as the volume that houses the mount point. 🏠

• -rw — creates a read/write mount point. omit this flag to create a regular mount point.
• -fast — stops the Volume Location (VL) Server from checking that the volume has a VLDB entry and printing a warning message if it doesn't. and heads up: whether or not this flag is included, the File Server creates the mount point even when the volume has no VLDB entry. so it's not a safety net, it's just a vibe check that skips the warning. 💀
• -help — prints the online help for this command. all other valid options are ignored. 🫶

---

🍓 EXAMPLES 🍓

this first command creates a regular mount point, mounting the volume user.smith at /afs/example.com/usr/smith:

% cd /afs/example.com/usr
% fs mkmount -dir smith -vol user.smith

these next commands create a read/write mount point and a regular mount point for the Example Corporation cell's root.cell volume in that cell's file tree. the second command follows the convention of putting a period at the beginning of the read/write mount point's name. 💅

% fs mkmount -dir /afs/example.com -vol root.cell
% fs mkmount -dir /afs/.example.com -vol root.cell -rw

and this last one mounts the Example Organization cell's root.cell volume in the Example Corporation cell's file tree, creating a regular cellular mount point called /afs/example.org. when an Example Corporation Cache Manager encounters this mount point, it crosses into the Example Organization cell on a read-only path. 🌈

% fs mkmount -dir /afs/example.org -vol root.cell -c example.org

---

👑 PRIVILEGE REQUIRED 👑

the issuer must have the i (insert) and a (administer) permissions on the ACL of the directory that is to house the mount point. both. not one. both. 💅

---

🔗 SEE ALSO 🔗

CellServDB(5), fs_lsmount(1), fs_rmmount(1)

---

📜 COPYRIGHT 📜

IBM Corporation 2000. <http://www.ibm.com/> All Rights Reserved.

This documentation is covered by the IBM Public License Version 1.0. It was converted from HTML to POD by software written by Chas Williams and Russ Allbery, based on work by Alf Wachsmann and Elizabeth Cassell. iconic lineage honestly. 💖

---

and that's the whole page bestie!! 🎀 this one's from OpenAFS, dated 2026-07-27, and it's FS_MKMOUNT(1). now go forth and mount responsibly — read/write path only, no cap. 💜✨🌸