umount -f
can be used to force an unmount when the filesystem is busy.
umount [-hV]
umount
-a [-dflnrv] [-t
vfstype] [-O options]
umount [-dflnrv]
{dir|device}...
Step 2
umount -f
can be used to force an unmount when the filesystem is busy.
Because you're lazy - you want to unmount after the disk operations are done.
Here's a plausible scenario:
You're using rsync
to perform your backups and walk
away. You can umount -l
the drive and once it's
finished copying and synched, it unmounts, so that when you come
back after a break (that you know will take longer than the
backup) you can just unplug the drive instead of having to fiddle
with the keyboard again.
You should boot into a rescue session using a Linux CD, or you
can drop to a lower runlevel using init
. It is not a
good idea to unmount your $HOME while logged in.
You might also be able to do this if you log in as
root
(actually log in, not su
or
sudo
). That way the /home
partition is
not needed and you will be able to unmount it. You will still
have to make sure no one is accessing it (see next paragraph) and
unmount it manually.
Finally, a useful tool is lsof /dev/sda3
which will
list the processes currently accessing that partition. To kill
all processes listed by lsof
(careful, this may
crash your system, depending on the process, but if this happens
you should be OK after a reboot), do this:
kill `lsof /dev/sda3 | awk '{print $2}'`
in case of vfat we effectively don't see a full blown UUID. It's a Volume ID (serial number) instead. These of course are not subject to the RFC mentioned above.
The command is umount
.
umount /mnt/windowsabc
umount /windosabc1
You can specify the directory that has the mount:
umount /mnt/db2
The man page for umount
mentions unmounting from the
directory explicitly. It says it is the best way to do it, and
that it works if you've mounted the device more than once.
Giving the special device on which the file system lives may also work, but is obsolete, mainly because it will fail in case this device was mounted on more than one directory.
Windows and Linux do require an eject, even though they have certain protections. They're just not necessarily as conscientious about user education. (I.e. warning you about it). An unmount / "eject" lets the OS ensure it is not "transferring data" any more.
It may be that your copy application doesn't return until all data has been written to the device. (How much do you trust your understanding of the copy app?) However one example scenario is that your file manager shows image thumbnails, and starts writing a thumbnail cache on the device without you realizing it.
Removing the device during a write will corrupt the filesystem. I don't know how the other OS's handle uncleanly unmounted FAT filesystems on removable devices, but Linux doesn't detect them at all. So the next mount will not trigger a filesystem repair, and the filesystem will remain corrupt.
How likely a corrupt FAT is to lead to data loss over time, I'm not sure. There's likely reasonable attempts to protect against it on well-developed kernels like Windows and Linux, because of how often people do this. (In a similar vein, linux has a mount option which tries to match Windows removable FAT behaviour... it does fsync() on close(), or something like that).
However it's good hygiene not to let your filesystems become corrupted. If nothing else, it means that if you're forced to shutdown uncleanly (e.g. by power failure), then you can scan the filesystem for corruption afterwards, and you'll only be faced with whatever happened recently.
As for the worst case? Your USB device is a very cheap SSD. The expensive SSDs fail hilariously when they lose power, including the loss of all data on the device. Sleep well and tend your backups. https://www.usenix.org/conference/fast13/understanding-robustness-ssds-under-power-fault
Even if you're lucky, you could lose the data on a whole 2Mb erase-block - when you were only writing to a 512 byte file on that EB. With flash storage, the device has to erase that whole 2Mb EB before it can rewrite the data. And the device will remap sectors for a couple of reasons, so the 2Mb of lost data could be from several places anywhere in the filesystem. My reference here would be kernel devlepor Pavel Machek's distress, at realising the linux ext filesystems (even with journalling) wasn't protect his data against this known failure mode. (FAT isn't really any better).
[I'm not a good example here, because I have a laptop with an SD card, I let it run out of battery quite frequently, and it accumulates errors to the point where fsck.vfat is not always able to fix them. OTOH there's nothing on the card that I don't have a copy of elsewhere :). I've had 3 unexpected failures of SD card hardware in the past].
The specifics will depend on exactly which distribution you are running and how it is set up, but painting with a very broad brush, when a Linux system goes down it enters either runlevel 0 (shutdown) or 6 (reboot).
When switching runlevels, the init process will execute "kill" and "start" scripts for the entered runlevel.
You can add such scripts of your own to execute arbitrary
commands when entering a given runlevel. For example, to add a
script on Debian that runs as the system is preparing to reboot,
create a shell script
/etc/init.d/my-reboot-prepare-script
with whatever
commands you like (look at the other scripts in that directory
for some details on how to do it), and then add a symbolic link
to it from /etc/rc6.d/K00my-reboot-prepare-script
.
The K
at the beginning will cause the script to be
called to "stop" the process in question, with the parameter
stop
.
The umount command detaches the file system(s) mentioned from the file hierarchy. A file system is specified by giving the directory where it has been mounted. Giving the special device on which the file system lives may also work, but is obsolete, mainly because it will fail in case this device was mounted on more than one directory.
Note that a file system cannot be unmounted when it is ’busy’ - for example, when there are open files on it, or when some process has its working directory there, or when a swap file on it is in use. The offending process could even be umount itself - it opens libc, and libc in its turn may open for example locale files. A lazy unmount avoids this problem.
Options for the umount command:
-t vfstype
Indicate that the actions should only be taken on file systems of the specified type. More than one type may be specified in a comma separated list. The list of file system types can be prefixed with no to specify the file system types on which no action should be taken.
-O options
Indicate that the actions should only be taken on file systems with the specified options in /etc/fstab. More than one option type may be specified in a comma separated list. Each option can be prefixed with no to specify options for which no action should be taken.
--no-canonicalize
Don’t canonicalize paths. For more details about this option see the mount(8) man page.
The umount command is part of the util-linux package and is available from ftp://ftp.kernel.org/pub/linux/utils/util-linux/.
/etc/mtab table of mounted file systems
The syntax of external umount helpers is:
/sbin/umount.<suffix> {dir|device} [-nlfvr] [-t type.subtype]
where the <suffix> is filesystem type or a value from "uhelper=" or "helper=" mtab option. The -t option is used for filesystems with subtypes support (for example /sbin/mount.fuse -t fuse.sshfs).
The uhelper= (unprivileged umount helper) is possible to use when non-root user wants to umount a mountpoint which is not defined in the /etc/fstab file (e.g devices mounted by udisk).
The helper= mount option redirects all umount requests to the /sbin/umount.<helper> independently on UID.
The umount command will free the loop device (if any) associated with the mount, in case it finds the option ’loop=...’ in /etc/mtab, or when the -d option was given. Any pending loop devices can be freed using ’losetup -d’, see losetup(8).
A umount command appeared in Version 6 AT&T UNIX.