Mounting Flashdrive - mounted to home directory

Question

I wanted to mount my flashdrive, and made the mistake of setting the mount path as /home/my_name. Now all of my documents, downloads, pictures, etc. are unavailable since my flashdrive has replaced my previous home folder.

When I go to terminal and type sudo umount /home/my_name I get the error message:

umount: /home/my_name: device is busy.
        (In some cases useful info about processes that use
         the device is found by lsof(8) or fuser(1))

Is there a way to fix this, where I can restore my old /home/my_name folder and then mount the flashdrive to a proper location?

Answer 1

A mount on a non-empty directory hides the files contained within it, which is often called shadowing. This doesn't cause the files themselves to be in jeopardy. There are several easy steps you can take to troubleshoot, fix, or (when necessary) work around this problem.

Make sure your own shell isn't what's keeping the filesystem from unmounting.

For a filesystem mounted at sudo fuser -km /home/my_name, running sudo fuser -km /home/my_name to kill all processes accessing the filesystem, as you have done, is usually sufficient to let you unmount it. You reported that when you did this your terminal was closed as a result.

This will happen if your current directory, in the shell, is the mount point you're trying to unmount or one of its subdirectories. (Your shell is killed, and then the terminal program running it sees that the shell has closed and, under most setups, quits automatically as well, much as it does when you run the exit command.)

To fix this, simply navigate outside the mount and attempt to unmount it again. For example, you could change directory to / first:

cd /
sudo umount /home/my_name

Find and close or kill whatever processes are accessing files in the mount.

If you are ever in a situation where don't want to kill processes with fuser, or if you are unable to do so and need to find out what those processes are, you have several options for finding them, including some graphical utilities. I'll briefly illustrate one option here.

You can run lsof on a directory to see what processes are accessing files inside it:

lsof /home/my_name

This works well for mount points. Sometimes lsof is able to obtain better information if you run it as root, though this is often not necessary:

sudo lsof /home/my_name

Output from lsof usually looks something like this:

ek@Io:~$ sudo lsof ~/mnt/old
lsof: WARNING: can't stat() fuse.gvfsd-fuse file system /run/user/1000/gvfs
      Output information may be incomplete.
COMMAND   PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
flock   15529   ek  cwd    DIR    7,0     2048 1280 /home/ek/mnt/old
flock   15529   ek    3rW  REG    7,0    21114 1311 /home/ek/mnt/old/md5sum.txt
less    15530   ek  cwd    DIR    7,0     2048 1280 /home/ek/mnt/old
less    15530   ek    3r   REG    7,0    21114 1311 /home/ek/mnt/old/md5sum.txt
less    15530   ek    5r   REG    7,0      231 1325 /home/ek/mnt/old/README.diskdefines
bash    27465   ek  cwd    DIR    7,0     2048 1280 /home/ek/mnt/old

This tells you the files and processes that are being used. In particular, if you have a situation where your shell is what's keeping it from unmounting, and you haven't noticed that this is the case, then lsof will make it plain with output like:

ek@Io:~$ lsof ~/mnt/old
lsof: WARNING: can't stat() tracefs file system /sys/kernel/debug/tracing
      Output information may be incomplete.
COMMAND   PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
bash    27465   ek  cwd    DIR    7,0     2048 1472 /home/ek/mnt/old/boot

In the above example, the only thing keeping the filesystem from being unmounted is that I had navigated into a subdirectory of the mount point with my shell (bash), and was still there.

If you need more information on a process, one way is to run ps with its process ID, which given in the second column of lsof's output:

ek@Io:~$ ps 27465
  PID TTY      STAT   TIME COMMAND
27465 pts/3    Ss+    0:04 -bash

You can also kill the process by its PID (kill 27465, but with whatever the appropriate number is in your situation). It's usually best to try this before moving on to the stronger kill -KILL 27465. (The -9 flag works in place if -KILL, too.)

Of course, before using the kill command or similar facilities at all, it's usually better to try closing programs the normal way, especially if there might be important data at stake. For example, it's better to save a document and close a word processor than to quit the word processor with the kill command.

Access the shadowed files through a nonrecursive bind mount.

As Paul says in Is it possible to access files “shadowed” by a mount? on SuperUser, you can access files shadowed by mounts by creating a bind mount and navigating to them there:

sudo mkdir /mnt/root
sudo mount --bind / /mnt/root

Those commands are adapted slightly from Paul's excellent answer to that question. (I encourage you to consult that page for additional details.) You don't have to use /mnt/root, but it's as good a choice as any.

If you do it that way, your entire root filesystem is accessible through /mnt/root.

If you have a separate /home partition then you'll want to make the bind mount bind to that instead:

sudo mkdir /mnt/home
sudo mount --bind /home /mnt/home

This is the same as for /, just with /home.

Reboot.

oldfred's suggestion to reboot the system is a reasonable solution to this problem. You should be able to shut down and reboot the system, if you want. Your data are shadowed by a mount, but should not be at risk of being lost.

_{Rebooting should be safe but you shouldn't need to reboot to solve this, if you don't want to. If you have trouble with the methods given above and want to get them to work, please comment or (better) edit your post. (Other people reading this with similar problems should consider posting a new question.)}