FIXMOUNT(8)

💖 FIXMOUNT — the fix remote mount entries glow-up 💖

okay bestie, so this is fixmount(8) from the System Manager's Manual section, and honestly? it's giving janitor energy in the best way possible. it cleans up mess. let's go ✨

---

🌸 NAME 🌸

fixmount — fix remote mount entries 🧹✨

---

🎀 SYNOPSIS 🎀

fixmount [ -adervq ] [ -h name ] host ...

---

🦋 DESCRIPTION 🦋

so like, fixmount is a variant of showmount(8) — you know her, you love her — except this one has ✨powers✨: it can delete bogus mount entries sitting in remote mountd(8) daemons. not just look at them. delete them. slay.

and the way it works is: the actions you ask for with the options get performed for each host in turn. one at a time, bestie. no cutting the line. 💅

---

✨ OPTIONS ✨

• -a, -d, -e — these three work exactly like they do in showmount(8), no cap, with one little twist: only the entries that pertain to the local host get printed. that's it. that's the twist. 🫶
• -r — removes those remote mount entries on host that don't correspond to current mounts. i.e. the leftovers from a crash, or the result of improper mount protocol. 💀 the way it checks what's actually real? it verifies the actuality of mounts using the entries in /etc/mtab. iconic forensic queen behavior.
• -v — verify remote mounts. it's like -r's chill cousin: instead of deleting anything, it just prints a notification message for each bogus entry it finds. the remote mount table is not changed. it's looking, not touching. 👀
• -A — issues a command to the remote mountd declaring that ALL of its filesystems have been unmounted. 🚨

use this with caution bestie, seriously — it removes all remote mount entries pertaining to the local system, whether or not any filesystems are still mounted locally. it does not care. it does not check. it is not asking. 💀

• -q — be quiet 🤫. suppresses error messages due to timeouts and "Program not registered" — i.e. the ones that happen because remote hosts aren't supporting RPC or aren't running mountd. no drama, no receipts.
• -h name — pretend the local hostname is name. 🎭 super useful after your local hostname has been changed and rmtab entries using the old name are still chillin' on a remote machine like they pay rent there.

unfortunately 😭 most mountd's won't be able to successfully handle removal of such entries, so this option is useful in combination with -v only.

bonus: this option also saves time, because comparisons of remotely recorded and local hostnames by address are avoided. efficiency queen. ⚡

---

🍓 FILES 🍓

• /etc/mtab — List of current mounts. 📋
• /etc/rmtab — Backup file for remote mount entries on NFS server. 💾

---

🌈 SEE ALSO 🌈

• showmount(8), mtab(5), rmtab(5), mountd(8C).
• the ``am-utils'' info(1) entry.
• Linux NFS and Automounter Administration by Erez Zadok, ISBN 0-7821-2739-8, (Sybex, 2001).
• http://www.am-utils.org
• Amd - The 4.4 BSD Automounter

---

💀 BUGS 💀 (aka the fine print, read it fr fr)

• no attempt is made to verify the information in /etc/mtab itself. it just trusts her. 🙈
• since swap file mounts are not recorded in /etc/mtab, a heuristic specific to SunOS is used to determine whether such a mount is actual — that means replacing the string "swap" with "root" and verifying the resulting path. yes really. 🧚
• symbolic links on the server will cause the path in the remote entry to differ from the one in /etc/mtab. to catch those cases, a filesystem is also deemed mounted if its local mount point is identical to the remote entry. i.e., on a SunOS diskless client, server:/export/share/sunos.4.1.1 is actually /usr/share. since the local mount point is /usr/share as well, this will be handled correctly. 🎯
• there is no way to clear a stale entry in a remote mountd after the local hostname (or whatever reverse name resolution returns for it) has been changed. to take care of these cases, the remote /etc/rmtab file has to be edited and mountd restarted. manually. with your hands. 😭
• the RPC timeouts for mountd calls can only be changed by recompiling. the defaults are 2 seconds for client handle creation and 5 seconds for RPC calls. yes, recompiling. in this economy. 💅

---

👑 AUTHORS 👑

• Andreas Stolcke <stolcke@icsi.berkeley.edu>.
• Erez Zadok <ezk@cs.sunysb.edu>, Computer Science Department, Stony Brook University, Stony Brook, New York, USA.
• Other authors and contributors to am-utils are listed in the AUTHORS file distributed with am-utils. 🫶

---

and that's the whole page bestie!! this one's dated back to 26 Feb 1993 and it lives in the System Manager's Manual — vintage, honestly. periodt. 💜✨