A NFS mount accident on Linux

Something that you can do on a modern Linux system by accident:

mount -t nfs -o hard,intr,rw localhost:/ /

(instead of mounting it on /mnt, as I had intended.)

It is surprisingly hard to recover from this. In fact, I don't think I succeeded, and I wound up having to reboot. At the same time, I don't think anything broke, so I theoretically could have kept on running the machine like that.

(Why you might want such a loopback mount is covered here.)

On Linux specifically, another way of achieving the same goal is to use a bind mount:

mount --bind / /mnt

This doesn't need NFS daemons, but I'm an old dog and sometimes we automatically reach for our old tricks, no matter how complicated they are.

Things I tried that don't work, so you can skip them

umount localhost:/

Did nothing.

umount / and umount -t nfs /

Either did nothing or complained that / was busy.

umount -l -t nfs /

Unmounted everything except for the rootfs mount of /, which leaves the system pretty much unrecoverable afterwards since udev's /dev is gone, so you don't have any devices to mount stuff from.

From this it looks like lazy unmounts detach subtrees of the mount that you're unmounting, as well as the mount itself, which I suppose is not too surprising.

Sidebar: how to keep access to /proc/mounts

When /proc becomes inaccessible, how do you find out what is and isn't mounted?

It's a fairly core principle of Linux that while you may get detached from the filesystem tree, your current directory doesn't actually go away. So I did:

; cd /proc
; python
>>> import os, sys
>>> def cat(fn):
...   fp = open(fn, "r")
...   fd = fp.read()
...   sys.stdout.write(fd)
>>> cat("mounts")

(The Python transcript has been slightly simplified.)

Using Python and importing stuff ahead of time meant that I wasn't counting on things like /bin/cat remaining accessible; everything I needed to monitor /proc/mounts was live in a running process. This turned out to be a good thing.