umount
unmount file systems
see also :
mount - losetup
Synopsis
umount
[-hV]
umount
-a [-dflnrv] [-t
vfstype] [-O options]
umount [-dflnrv]
{dir|device}...
add an example, a script, a trick and tips
examples
source
umount /datastores/1
umount /datastores/102
source
How to really force unmount a filesystem (without manual investigation why is it busy)
umount -f
can be used to force an unmount when the filesystem is busy.
source
Lazy umount or Unmounting a busy disk in Linux
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.
source
why can't I umount /home?
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}'`
source
Why Linux /etc/fstab UUIDs are case sensitive?
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.
source
Unmount unnecessary drives
The command is umount.
umount /mnt/windowsabc
umount /windosabc1
source
How do I umount device that has been mounted twice
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.
source
Why do macs require to eject usb, but windows and linux dont?
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].
source
How to automatically unmount encrypted loop device at shutdown?
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.
description
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:
-V
Print version and exit.
-h
Print help message and exit.
-v
Verbose mode.
-n
Unmount without writing in /etc/mtab.
-r
In case unmounting fails, try to remount read-only.
-d
In case the unmounted device was a loop device, also
free this loop device.
-i
Don’t call the /sbin/umount.<filesystem>
helper even if it exists. By default
/sbin/umount.<filesystem> helper is called if one
exists.
-a
All of the file systems described in /etc/mtab
are unmounted. (With umount version 2.7 and later:
the proc filesystem is not unmounted.)
-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.
-f
Force unmount (in case of an unreachable NFS system).
(Requires kernel 2.1.116 or later.)
-l
Lazy unmount. Detach the filesystem from the filesystem
hierarchy now, and cleanup all references to the filesystem
as soon as it is not busy anymore. (Requires kernel 2.4.11
or later.)
--no-canonicalize
Don’t canonicalize paths.
For more details about this option see the mount(8)
man page.
--fake
Causes everything to be done except for the actual
system call; this ’’fakes’’
unmounting the filesystem. It can be used to remove entries
from /etc/mtab that were unmounted earlier with the
-n option.
availability
The umount command is part of the util-linux package and is
available from ftp://ftp.kernel.org/pub/linux/utils/util-linux/.
files
/etc/mtab table of mounted file systems
notes
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 loop device
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).
history
A umount
command appeared in Version 6 AT&T UNIX.
see also
umount,
mount , losetup .